Das Tor Project begann am 4. Oktober, betroffene Relays zu markieren; am 5. Oktober war keines mehr im Consensus, also in der Relay-Liste, die Tor-Clients verwenden. Diese Zahlen stammen aus einer Auswertung öffentlicher Tor-Verzeichnisdaten, die auf der Mailingliste tor-relays veröffentlicht wurde.

Der Forscher, der unter dem Namen kaba publiziert, scannte am 2. Oktober alle rund 3.000 Exits des Netzes und fand 333, die SSH auf dieselben zwölf Abfangserver umleiteten. Die Verzeichnisdaten-Analyse zählt 377 Relays von 59 Betreibern, die zwischen dem 1. und 4. Oktober auf die Exit-Policy des Angreifers umgestellt wurden — das sei “eine Übereinstimmung der Policy, kein Beweis für eine Kompromittierung”.

Wie die gekaperten Exits SSH abfingen

Ein Exit-Relay transportiert nur Verkehr zu den Ports, die seine Exit-Policy erlaubt. Die Angreifer schrieben diese Policy in den torrc-Konfigurationsdateien um und gaben Port 22 frei — auf 342 Relays, die SSH zuvor blockiert hatten. Weitere 24 Relays waren vorher gar keine Exits und wurden erst dazu gemacht. “Es sieht so aus, als verschaffe sich der Angreifer Zugang zu Linux-Hosts und ändere, wenn diese Maschinen als Nicht-Exits laufen, die torrc-Datei, um sie in Exits zu verwandeln und so den SSH-Angriff durchführen zu können”, schrieb das Network-Health-Team des Tor Project in seiner Mitteilung vom 5. Oktober an die Relay-Betreiber. Laut Verzeichnisdaten waren die meisten betroffenen Relays allerdings bereits Exits.

Dieselbe Änderung schloss die verschlüsselten Mail-Ports IMAPS und POP3S und öffnete auf den meisten Relays die unverschlüsselt nutzbaren Pendants POP3 und IMAP. Da ein Tor-Client nur einen Exit wählt, der den Zielport erlaubt, transportierten diese Relays fortan keine verschlüsselte Mail mehr, dafür SSH, Telnet und meist Klartext-Mail. Warum die verschlüsselten Mail-Ports geschlossen wurden, geht aus den Daten nicht hervor.

Mit offenem Port 22 landete eine SSH-Verbindung über einen dieser Exits auf einem der zwölf Abfangserver statt beim eigentlichen Ziel. Der Abfangserver präsentierte seinen eigenen Host-Schlüssel: Wer den echten Schlüssel bereits kannte, sah die OpenSSH-Warnung, dass sich die Identifikation des entfernten Hosts geändert habe; wer sich erstmals verband, bekam die übliche Abfrage zur Annahme eines neuen Schlüssels. Im Scan vom 2. Oktober lieferten etwa ein Dutzend Exits einen gefälschten Host-Schlüssel aus, die rund 300 übrigen leiteten über dieselben Server um, ohne den Schlüssel zu verändern.

Wer den Schlüssel akzeptierte und ein Passwort eintippte, übergab es dem Abfangenden. Dieser baute die Verbindung zum echten Server auf, sodass die Sitzung funktionierte; jeder Befehl konnte mitgelesen werden, und mit dem gestohlenen Passwort erfolgte eine separate Anmeldung, um sudo zu prüfen und einen base64-kodierten Perl-Installer auszuführen. In kabas Honeypot hatte dieser Installer dieselbe Form wie der Befehl, der auf dem Server eines Relay-Betreibers die OpenSSH-Backdoor Ebury installierte.

Eine schlüsselbasierte SSH-Anmeldung ließ sich auf diesem Weg nicht weiterreichen: Nach dem SSH-Authentifizierungsprotokoll enthält die Signatur des Clients eine für jede Sitzung eindeutige Kennung, sodass eine für die Sitzung des Abfangservers erzeugte Signatur gegenüber dem echten Server wertlos ist. Der Abfangserver könnte eine Schlüsselanmeldung zwar selbst annehmen und eine gefälschte Shell zeigen, den echten Server damit aber nicht erreichen. Ein Passwort dagegen reist innerhalb der verschlüsselten Sitzung und ist für die Gegenstelle lesbar — hier also für den Abfangserver.

Wer betroffen ist

Betroffen ist nur, wer sich zwischen dem 1. Oktober und dem Nachmittag des 5. Oktober über Tor mit einem SSH-Server verband, dabei auf einem der gekaperten Exits landete, dessen Verbindung tatsächlich abgefangen statt durchgereicht wurde, den Host-Schlüssel des Abfangservers akzeptierte und sich mit Passwort anmeldete. Eine Opferzahl existiert nicht.

Wer in diesem Zeitraum über Tor einen unbekannten oder geänderten Host-Schlüssel akzeptiert hat, sollte das eingegebene Passwort als gestohlen behandeln, es ändern und den betreffenden Server auf Ebury-Spuren prüfen. Ein OpenSSH-Client, der den Schlüssel akzeptiert hat, speicherte ihn in known_hosts. Der Server, der kabas Verbindung abfing, nutzte einen ED25519-Schlüssel mit dem Fingerabdruck SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E; die übrigen Abfangserver können andere Schlüssel verwendet haben.

Entdeckung und Gegenmaßnahmen

Kaba stieß am Morgen des 2. Oktober auf den Angriff, als eine SSH-Verbindung über Tor eine Warnung über einen geänderten Schlüssel lieferte. Er nutzte anschließend exitmap — ein Scan-Werkzeug, das auch das Network-Health-Team des Tor Project einsetzt — und baute von einem seiner Server über jeden Exit nacheinander eine SSH-Verbindung zu einem anderen auf. Eine Seite prüfte, ob der Host-Schlüssel korrekt war, die andere, ob die Verbindung vom Exit oder von einem Abfangserver stammte. Am Abend meldete er die Ergebnisse dem Health-Team.

Das Team hatte die Policy-Änderung über eigenes Monitoring ebenfalls bemerkt. Am 4. Oktober kontaktierte es Zimmer, den Betreiber der Relay-Familie Quetzalcoatl, der größten betroffenen Gruppe. Zimmer bestätigte, dass die Änderung nicht von ihm stammte, bat darum, die Relays als bad zu markieren, und stoppte Tor auf dem betreffenden Server. Die Directory Authorities begannen um 18:00 UTC, die Flags BadExit und MiddleOnly für betroffene Relays zu vergeben; um 21:00 Uhr standen sie im Consensus. BadExit weist Tor-Clients an, ein Relay niemals als Exit zu nutzen.

Am Morgen des 5. Oktober lief ein skriptgesteuerter Neustart über 55 Hosts von Quetzalcoatl — mit weiterhin gesetzter Policy. Wer ihn ausführte, ist unbekannt. Laut der Mitteilung des Tor Project wiesen die Directory Authorities betroffene Relays zu diesem Zeitpunkt bereits ab; die beiden von Zimmer gestoppten Relays wurden beim Versuch zurückzukehren abgelehnt, wie er schrieb. Um 17:00 UTC am 5. Oktober befand sich kein Relay mit der Angreifer-Policy mehr im Consensus, und bis zum 9. Oktober kehrte keines zurück. 41 Relays, neun davon aus der Quetzalcoatl-Familie, veröffentlichten die Policy zu diesem Zeitpunkt noch, waren aber nicht gelistet. Die von Tor Metrics gezählte Zahl der Relays mit Exit-Flag fiel zwischen dem 3. und 5. Oktober um rund 370 — passend zur Zahl der betroffenen Relays — und hatte sich bis zum 18. Oktober nicht erholt.

Ebury und der Einbruchsweg

Zimmer schilderte seine Seite am 7. Oktober in einer Nachbetrachtung auf der Mailingliste. Zwei seiner Server liefen mit Ebury in Version 1.8.3: ein Management-Server bei Contabo, der als VPN-Gateway und SSH-Jump-Host der Familie diente, sowie ein FranTech-VPS namens Switzerland2, auf dem zwei der Exits liefen. Ebury ist eine Backdoor und ein Zugangsdatendieb für OpenSSH, die laut ESET seit 2009 aktiv ist; ESET schätzte 2024, dass sie 400.000 Server infiziert hatte, davon Ende 2023 noch mehr als 100.000 aktiv infiziert.

Der Angreifer meldete sich am 28. August beim ersten Versuch mit dem Passwort des Betreiberkontos am Management-Server an, erlangte binnen fünf Minuten Root-Rechte, installierte Ebury und erreichte gut eine Stunde später Switzerland2, wo er es ebenfalls installierte. “Die Ursache lag bei uns: ein Passwort, wiederverwendet für SSH-Login, sudo und die Backup-Passphrase, im Klartext auf beiden Servern gespeichert, dazu die auf dem zum Internet hin offenen Management-Server aktiv gelassene SSH-Passwortauthentifizierung”, schrieb Zimmer. Woher der Angreifer das Passwort hatte, ist unbekannt.

Eburys Backdoor-Logins hinterlassen keine Spuren. Am 2. Oktober wurden die Konfigurationsdateien der Exits umgeschrieben, ohne dass ein Login, ein sudo-Befehl oder ein Cronjob in den Logs auftauchte; um 09:34 UTC veröffentlichten die beiden Relays die Policy des Angreifers. Sie blieb rund 52 Stunden auf zwei Relays aktiv, die täglich etwa 3,4 TiB bewegten. Ein routinemäßiger Neustart am 4. Oktober beendete die versteckten Werkzeuge des Angreifers, doch Ebury kam umgehend zurück. Die “offline” verwahrten Master-Keys der Familie “waren nicht offline: Kopien lagen im Workstation-Backup auf dem Management-Server, verschlüsselt mit dem Passwort, das der Angreifer bereits hatte”, so Zimmer. Er stellte alle Relays und die Bridge der Familie außer Betrieb und löschte beide Server.

Diese Ebury-Variante besteht aus einer einzelnen setuid-Bibliotheksdatei, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, auf die der Symlink libkeyutils.so.1 zeigt. Die Paketbibliothek bleibt unangetastet, weshalb dpkg -V und debsums nichts finden; sshd, sudo und PAM bestehen ihre Paketprüfungen. Version 1.8.3 ist neuer als ESETs öffentliche Indikatoren, die bei 1.8.2 enden, und das veröffentlichte Erkennungsskript von ESET führte am 21. Oktober keinen Socket-Namen dafür. Marc-Etienne M. Léveillé, Mitautor von ESETs Ebury-Papier aus 2014 und Autor des Berichts von 2024, inzwischen nicht mehr bei ESET, antwortete, Version 1.8.3 existiere mindestens seit Juni 2026, und stellte eine aktualisierte Fassung des Skripts bereit, die sie abdeckt. “Angesichts dessen, wie viele Server zwischen 2009 und 2023 Ebury hatten (400.000!), gibt es da draußen höchstwahrscheinlich weitere kompromittierte Tor-Relays”, schrieb er.

Wie die Hosts der übrigen 58 Betreiber übernommen wurden, ist die zentrale offene Frage. Von deren am 1. Oktober gelisteten Relays wechselten 71 der 101 bei FranTech Solutions gehosteten — dem Netz hinter der Hosting-Marke BuyVM — auf die Policy des Angreifers, gegenüber 13 von 9.054 anderswo gehosteten. 40 Relays von 21 Betreibern änderten sich am 1. Oktober innerhalb von fünfeinhalb Minuten, überwiegend per Konfigurations-Reload, was die Analyse als Hinweis auf einen einzelnen Akteur liest, der bereits Zugang zu allen 40 hatte. Léveillés beste Vermutung zur Herkunft des Passworts ist eine Anmeldung von einem bereits mit Ebury infizierten Host; eine kompromittierte Hosting-Infrastruktur sei eine weitere Möglichkeit — ESET habe Provider gesehen, deren Management-Server Ebury ausführten und deren Kunden-VMs anschließend infiziert waren. Kaba zählte 26 der 27 kompromittierten Server außerhalb der Quetzalcoatl-Familie bei FranTech/BuyVM und fragte auf der Liste: “Könnten sie diese Server auf Ebene des Hosters kompromittiert haben?” Quetzalcoatls eigene Kompromittierung lief dagegen über den Contabo-Management-Server, und 225 der 273 betroffenen Relays der Familie standen in anderen Netzen.

Wer hinter der Kampagne steckt, ist unbekannt, ebenso, wie viele der betroffenen Hosts tatsächlich Ebury ausführten: Zimmer untersuchte zwei seiner Server, die Verzeichnisdaten zeigen nur die Policy. Andere Betreiber meldeten dem Tor Project unter anderem einen gefälschten, großgeschriebenen CRON-Daemon und NAT-Regeln, die Port 22 umleiteten. Zimmers Server zeigten beides nicht; ob es sich um denselben Akteur handelt, ist offen. Auf seinen Relays führten die Port-Änderungen dazu, dass Mailabruf nur noch im Klartext möglich war, und auf Switzerland2 lief während des größten Teils des Zeitfensters ein versteckter Prozess namens snf — mit unbekannter Funktion.

Was Relay-Betreiber prüfen sollten

Das Tor Project bittet Linux-Relay-Betreiber, in der Relay Search nach einem nicht selbst gesetzten Exit-Flag oder einer fremden Exit-Policy zu sehen und torrc samt eingebundener Dateien auf veränderte Zeilen bei ExitRelay, ExitPolicy, ContactInfo, MyFamily oder Nickname zu prüfen. Ebenso genannt werden NAT-Regeln auf Port 22, unbekannte lauschende Prozesse oder ausgehende Verbindungen, neue Benutzer, authorized_keys-Einträge, Cronjobs und systemd-Units sowie ein tor-Binary, das die Paketprüfung nicht besteht. Zimmers Server wiesen keines dieser Host-Merkmale auf, nur die geänderte Exit-Policy — ein sauberer Host-Check schließt diese Ebury-Variante also nicht aus.

Die Indikatoren des Implants aus Zimmers Beitrag:

  • Datei: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, setuid und zu keinem Paket gehörend (auf seinen Servern 63.368 Byte, mit auf jedem Server abweichendem Hash)
  • Symlink: libkeyutils.so.1, der auf diese Datei zeigt
  • Socket: abstrakter UNIX-Socket @event-0YsOG9WSOE
  • Prozess: ein gefälschter /sbin/rsyslogd (früher systemd-udevd oder arpd), laufend in der cgroup von ssh.service
  • IP: 185.225.226[.]62, Quelle der Anmeldung vom 28. August
  • SSH-Schlüssel: RSA SHA256:dvACokMYcXJ2om4wuS+TvdtjrAgPK7rC7ZQHDgvBHzk, genutzt für die Anmeldung an Switzerland2
  • Im Implant eingebettete SSH-Schlüssel: RSA SHA256:KlICz/B59619CpuQdGzgmmvzWBfTMUJ77EwihTYobuo und ED25519 SHA256:OfLY0uF9SwOW9xVjiMXZGDfk6Atmz6CbHy4epknLm8Y
  • Host-Schlüssel des Abfangservers: ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, gesehen bei kabas Verbindung

Die Prüfung sollte nach Möglichkeit aus einem Rescue-System oder von einem Offline-Abbild der Festplatte erfolgen; auf einem laufenden Server ist die Anmeldung per Schlüssel angeraten. “Tippe niemals ein Passwort in einen Server, den du verdächtigst, denn Ebury wird es abgreifen”, schrieb Zimmer. Um am Userland-Rootkit vorbeizukommen, empfiehlt er, vor dem Ausführen von Léveillés aktualisiertem Skript oder der Befehle aus seinem Beitrag eine Shell mit H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash zu starten.

Findet man das Implant, sieht das Tor Project folgende Schritte vor: das Relay offline nehmen, Datenträger und Logs vor dem Löschen sichern, neu installieren statt zu bereinigen, eine neue Relay-Identität erzeugen und die alten Schlüssel als gestohlen behandeln sowie sämtliche auf dem Host vorhandenen Zugangsdaten wechseln. Die Neuinstallation ist nötig, weil das Implant auf Zimmers Server einen Neustart überlebte. Meldungen gehen an bad-relays@lists.torproject.org; wurde die eigene IP-Adresse während des Vorfalls gesperrt, kann man sich nach der Bereinigung an dieselbe Adresse wenden, um die Sperre aufheben zu lassen, erklärte Georg Koppen vom Tor Project in einer Folgenachricht.