Het artikel beschrijft een grootschalige aanval waarbij 333 Tor exit nodes (ongeveer 10% van het netwerk) waren geïnfecteerd met de Ebury 1.8.3-payload. Het doel van de aanvallers was het verzamelen van onversleuteld e-mailverkeer en het uitvoeren van SSH Man-in-the-Middle (MITM) aanvallen om wachtwoorden te stelen en servers verder te infecteren.
De auteur ontdekte de aanval nadat hij een SSH-waarschuwing kreeg over een gewijzigde host-identificatie. Na melding bij het Tor Network Health team werden de getroffen relays gemarkeerd als BadExit en uiteindelijk uitgeschakeld. Technisch gezien heeft de auteur de geïnfecteerde nodes geïdentificeerd met een eigen script dat fingerprints controleerde en verkeersomleidingen naar interceptieservers detecteerde. Met een honeypot (sshesame) werd bovendien vastgesteld dat de aanvallers Python en Perl gebruikten voor de installatie van de malware.
De auteur concludeert dat het essentieel is om wachtwoordauthenticatie te vervangen door SSH-keys en hardware-beveiliging te implementeren om dergelijke aanvallen te voorkomen.
Hoe ik ervoor zorgde dat meer dan 300 Tor exit nodes werden verwijderd
Om een idee te geven van de schaal: het gehele Tor-netwerk heeft ongeveer 3000 exit relays, wat betekent dat ongeveer 10% onder controle van de aanvallers stond. De aanvallers hadden twee maanden eerder, in augustus, toegang gekregen tot de servers en hadden daar stilletjes hun Ebury 1.8.3-payload geïnstalleerd (een OpenSSH-backdoor en credential stealer voor Linux).
De aanval
De aanval leek twee hoofddoelen te hebben:
- Het verzamelen van zoveel mogelijk onversleuteld e-mailverkeer.
- Het onderscheppen van SSH-verbindingen (Man-in-the-Middle, MITM).
Door bepaalde poorten te blokkeren, zorgden de aanvallers ervoor dat hun exit nodes alleen onversleuteld e-mailverkeer afhandelden. Een interessante analyse van een van de slachtoffers (een ervaren Tor-operator) gaat hier uitgebreid op in: lists.torproject.org/mailman3.
In dit artikel focus ik op de tweede aanval: de SSH MITM.
Wanneer je toevallig een circuit krijgt dat via een van die 333 geïnfecteerde exit nodes loopt, merk je in eerste instantie niets. Versleuteld webverkeer wordt gewoon doorgestuurd, maar als je een SSH-verbinding probeert op te zetten via poort 22, word je onwetend omgeleid naar een van de 12 SSH-interceptieservers.
Dat is precies wat mij op vrijdagmorgen overkwam. Mijn SSH-verbinding werd omgeleid en ik kreeg de volgende waarschuwing te zien:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.
Please contact your system administrator.
Als je de waarschuwing negeert en toch inlogt, onderneemt de aanvaller drie acties:
- Hij steelt je wachtwoord.
- Hij opent een verbinding met je server en observeert elk commando dat je typt (MITM).
- Hij opent een tweede verbinding met je server en infecteert deze met Ebury.
De nodes laten verwijderen
Op vrijdagavond heb ik het netwerk-healthteam van het Tor Project gecontacteerd met mijn bevindingen. Zij bevestigden dat dit iets nieuws was en namen direct contact op met de getroffen relay-operators.
"We hebben nog nooit een aanval als deze gezien."
— Tor Network Health Team
Tijdlijn van de gebeurtenissen:
- Vr 2 okt: De interceptie start.
- Zo 4 okt: Het Tor network health team doet een aankondiging aan de operators, waarna zij hun exit nodes beginnen uit te schakelen.
- Zo 4 okt: De relays worden gemarkeerd als
BadExit, zodat cliënten ze niet langer gebruiken voor uitgaand verkeer.
- Ma 5 okt: De aanvallers herstarten veel van de relays, maar omdat ze al waren gemarkeerd, konden ze alleen nog dienen als middle relays.
- Ma 5 okt: Alle geïnfecteerde servers worden uitgeschakeld, deels door de operators en deels door de aanvallers.
In hun aankondiging beschreef het healthteam het patroon:
"Het lijkt erop dat de aanvaller toegang krijgt tot Linux-gebaseerde hosts en, wanneer deze machines geen exits draaien, het torrc-bestand bewerkt en ze omzet in exits om zo de SSH-aanval uit te kunnen voeren."
— Tor Network Health in de aankondiging
De impact van het uitschakelen van deze 333 exit nodes is duidelijk zichtbaar. Op metrics.torproject.org is op 4 oktober een duidelijke dip te zien die sindsdien niet is hersteld.
Overweeg om zelf een relay te draaien: community.torproject.org/relay/setup/
Het technische gedeelte: hoe ik ze vond
Hier ga ik in detail in op hoe ik alle geïnfecteerde exit nodes heb gevonden. Met behulp van exitmap heb ik een eenvoudig script gebouwd dat het volgende deed:
- Het pinde een exit node en opende vervolgens een SSH-verbinding van mijn server A naar mijn server B.
- Server A controleerde of de juiste SSH-fingerprint van server B werd ontvangen.
- Server B controleerde of de verbinding kwam van de gepinde exit node of van een van de 12 SSH-interceptieservers.
Ik heb het script gedraaid tegen elke individuele exit relay (ongeveer 3000 stuks). Ongeveer een dozijn servers gaven een valse fingerprint, en meer dan 300 onderschepten niets, maar leidden het verkeer door via diezelfde interceptieservers. Alleen de omleiding was al voldoende om te bevestigen dat de exit geïnfecteerd was.
In verdere analyses heb ik sshesame als honeypot gebruikt. Door de MITM te lokken om in te loggen op de honeypot, bleek dat zij paramiko (een Python SSH-bibliotheek) gebruikten en werd duidelijk hoe zij probeerden Ebury te installeren met behulp van Perl:
> echo "U=$(id -u) S=$(command -v sudo >/dev/null 2>&1 && (sudo -n true 2>/dev/null && echo nopass || echo maybe) || echo none)"
> sudo bash -c 'echo <base64> | base64 -d | perl'
Hierbij wordt eerst gecontroleerd op permissies, waarna een base64-gecodeerd commando wordt uitgevoerd.
Openstaande vragen
De grootste vraag is nog steeds hoe ze überhaupt toegang hebben gekregen tot al die servers. Eén theorie is dat het hostingbedrijf zelf is gehackt (besproken op lists.torproject.org), maar dat blijft vooralsnog een theorie. In werkelijkheid weet niemand het zeker.
Een andere vraag is wie hierachter zit. Het gebruik van Ebury en de brede verzameling van onversleuteld data wijzen op een financieel gedreven criminele groep, al is ook dit speculatie.
"Gezien hoeveel servers tussen 2009 en 2023 Ebury hadden (400.000!), is de kans groot dat er nog meer gecompromitteerde Tor relays zijn."
— Marc-Etienne M. Léveillé (lists.torproject.org)
Ik vermoed daarnaast dat ze hun aanval bewust op een vrijdag lanceerden, in de hoop dat niemand zijn weekend zou willen verpesten door direct te reageren. Desalniettemin complimenten aan het Tor Team voor hun snelle handelen.
Conclusie
De les is zoals altijd: extra beveiliging is een waardevolle investering. Schakel wachtwoordauthenticatie uit ten gunste van SSH-keys. Ik ga voor mezelf vandaag nog hardware keys aanschaffen.
"Uiteindelijk moeten relays/bridges worden behandeld als zeer doelgerichte productiemachines."
— George (lists.torproject.org)
Hoe ik ervoor zorgde dat meer dan 300 Tor exit nodes werden verwijderd
Om een idee te geven van de schaal: het gehele Tor-netwerk heeft ongeveer 3000 exit relays, wat betekent dat ongeveer 10% onder controle van de aanvallers stond. De aanvallers hadden twee maanden eerder, in augustus, toegang gekregen tot de servers en hadden daar stilletjes hun Ebury 1.8.3-payload geïnstalleerd (een OpenSSH-backdoor en credential stealer voor Linux).
De aanval
De aanval leek twee hoofddoelen te hebben:
- Het verzamelen van zoveel mogelijk onversleuteld e-mailverkeer.
- Het onderscheppen van SSH-verbindingen (Man-in-the-Middle, MITM).
Door bepaalde poorten te blokkeren, zorgden de aanvallers ervoor dat hun exit nodes alleen onversleuteld e-mailverkeer afhandelden. Een interessante analyse van een van de slachtoffers (een ervaren Tor-operator) gaat hier uitgebreid op in: lists.torproject.org/mailman3.
In dit artikel focus ik op de tweede aanval: de SSH MITM.
Wanneer je toevallig een circuit krijgt dat via een van die 333 geïnfecteerde exit nodes loopt, merk je in eerste instantie niets. Versleuteld webverkeer wordt gewoon doorgestuurd, maar als je een SSH-verbinding probeert op te zetten via poort 22, word je onwetend omgeleid naar een van de 12 SSH-interceptieservers.
Dat is precies wat mij op vrijdagmorgen overkwam. Mijn SSH-verbinding werd omgeleid en ik kreeg de volgende waarschuwing te zien:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.
Please contact your system administrator.
Als je de waarschuwing negeert en toch inlogt, onderneemt de aanvaller drie acties:
- Hij steelt je wachtwoord.
- Hij opent een verbinding met je server en observeert elk commando dat je typt (MITM).
- Hij opent een tweede verbinding met je server en infecteert deze met Ebury.
De nodes laten verwijderen
Op vrijdagavond heb ik het netwerk-healthteam van het Tor Project gecontacteerd met mijn bevindingen. Zij bevestigden dat dit iets nieuws was en namen direct contact op met de getroffen relay-operators.
"We hebben nog nooit een aanval als deze gezien."
— Tor Network Health Team
Tijdlijn van de gebeurtenissen:
- Vr 2 okt: De interceptie start.
- Zo 4 okt: Het Tor network health team doet een aankondiging aan de operators, waarna zij hun exit nodes beginnen uit te schakelen.
- Zo 4 okt: De relays worden gemarkeerd als
BadExit, zodat cliënten ze niet langer gebruiken voor uitgaand verkeer.
- Ma 5 okt: De aanvallers herstarten veel van de relays, maar omdat ze al waren gemarkeerd, konden ze alleen nog dienen als middle relays.
- Ma 5 okt: Alle geïnfecteerde servers worden uitgeschakeld, deels door de operators en deels door de aanvallers.
In hun aankondiging beschreef het healthteam het patroon:
"Het lijkt erop dat de aanvaller toegang krijgt tot Linux-gebaseerde hosts en, wanneer deze machines geen exits draaien, het torrc-bestand bewerkt en ze omzet in exits om zo de SSH-aanval uit te kunnen voeren."
— Tor Network Health in de aankondiging
De impact van het uitschakelen van deze 333 exit nodes is duidelijk zichtbaar. Op metrics.torproject.org is op 4 oktober een duidelijke dip te zien die sindsdien niet is hersteld.
Overweeg om zelf een relay te draaien: community.torproject.org/relay/setup/
Het technische gedeelte: hoe ik ze vond
Hier ga ik in detail in op hoe ik alle geïnfecteerde exit nodes heb gevonden. Met behulp van exitmap heb ik een eenvoudig script gebouwd dat het volgende deed:
- Het pinde een exit node en opende vervolgens een SSH-verbinding van mijn server A naar mijn server B.
- Server A controleerde of de juiste SSH-fingerprint van server B werd ontvangen.
- Server B controleerde of de verbinding kwam van de gepinde exit node of van een van de 12 SSH-interceptieservers.
Ik heb het script gedraaid tegen elke individuele exit relay (ongeveer 3000 stuks). Ongeveer een dozijn servers gaven een valse fingerprint, en meer dan 300 onderschepten niets, maar leidden het verkeer door via diezelfde interceptieservers. Alleen de omleiding was al voldoende om te bevestigen dat de exit geïnfecteerd was.
In verdere analyses heb ik sshesame als honeypot gebruikt. Door de MITM te lokken om in te loggen op de honeypot, bleek dat zij paramiko (een Python SSH-bibliotheek) gebruikten en werd duidelijk hoe zij probeerden Ebury te installeren met behulp van Perl:
> echo "U=$(id -u) S=$(command -v sudo >/dev/null 2>&1 && (sudo -n true 2>/dev/null && echo nopass || echo maybe) || echo none)"
> sudo bash -c 'echo <base64> | base64 -d | perl'
Hierbij wordt eerst gecontroleerd op permissies, waarna een base64-gecodeerd commando wordt uitgevoerd.
Openstaande vragen
De grootste vraag is nog steeds hoe ze überhaupt toegang hebben gekregen tot al die servers. Eén theorie is dat het hostingbedrijf zelf is gehackt (besproken op lists.torproject.org), maar dat blijft vooralsnog een theorie. In werkelijkheid weet niemand het zeker.
Een andere vraag is wie hierachter zit. Het gebruik van Ebury en de brede verzameling van onversleuteld data wijzen op een financieel gedreven criminele groep, al is ook dit speculatie.
"Gezien hoeveel servers tussen 2009 en 2023 Ebury hadden (400.000!), is de kans groot dat er nog meer gecompromitteerde Tor relays zijn."
— Marc-Etienne M. Léveillé (lists.torproject.org)
Ik vermoed daarnaast dat ze hun aanval bewust op een vrijdag lanceerden, in de hoop dat niemand zijn weekend zou willen verpesten door direct te reageren. Desalniettemin complimenten aan het Tor Team voor hun snelle handelen.
Conclusie
De les is zoals altijd: extra beveiliging is een waardevolle investering. Schakel wachtwoordauthenticatie uit ten gunste van SSH-keys. Ik ga voor mezelf vandaag nog hardware keys aanschaffen.
"Uiteindelijk moeten relays/bridges worden behandeld als zeer doelgerichte productiemachines."
— George (lists.torproject.org)
Groetjes,