333 Tor-Exit-Relays leiteten SSH um und begünstigten Klartext-Mail

Rund jedes zehnte Tor-Exit-Relay wurde Anfang Oktober unbemerkt in eine SSH-Passwortfalle verwandelt. Ein unter dem Namen kaba publizierender Forscher scannte am 2. Oktober sämtliche rund 3.000 Exits von Tor und fand 333, die SSH auf dieselben 12 Abfangserver umleiteten. An der Kryptografie von Tor ist nichts gescheitert. Die Angreifer übernahmen die Linux-Hosts unter den Relays und schrieben eine Textdatei um.

01So wurden die Relays umfunktioniert

Ein Exit-Relay leitet Verkehr nur an Ports weiter, die seine Exit-Policy erlaubt, und diese Policy steht in der Konfigurationsdatei torrc des Relays. Ab dem 1. Oktober schrieben die Angreifer diese Policies um und öffneten Port 22. Damit wurde SSH auf 342 Relays aktiviert, die es zuvor blockiert hatten, und 24 Nicht-Exit-Relays wurden zu Exits.

Der einzige vollständig dokumentierte Einfallsweg ist die eigene Infrastruktur eines Relay-Betreibers, nicht die Systeme des Tor Project. Die Zusammenfassung von Ars Technica spricht von einem „Tor-Management-Server“, die Post-Mortem-Analyse beschreibt es jedoch anders: Es war der Contabo-VPS des Betreibers, der als WireGuard-Gateway, SSH-Jump-Host und obfs4-Bridge diente. Ein zweiter Rechner, Switzerland2, war ein FranTech-VPS, auf dem zwei Exit-Relays des Betreibers liefen. Der Angreifer nutzte das Passwort des Betreibers, das auf Anhieb funktionierte, und hatte fünf Minuten später Root-Rechte. Das deckt sich mit der Darstellung von Ars, wonach ein Passwort wiederverwendet wurde.

Auf diesem Server wurde Ebury 1.8.3 installiert. Etwa eine Stunde später akzeptierte Switzerland2 eine Anmeldung mit einem RSA-Schlüssel, der in keiner der authorized_keys-Dateien stand; eine Sekunde danach wurde dort Ebury installiert. Wie dieser Schlüssel akzeptiert wurde, ist laut Betreiber weiterhin offen. Marc-Etienne Léveillé, der Ebury seit 13 Jahren verfolgt, regte auf der Mailingliste an, Ebury könnte schon früher vorhanden und am 30. September aktualisiert worden sein. Zudem brachte er einen kompromittierten Hosting-Anbieter als Möglichkeit ins Spiel.

Wie der Angreifer die Policy auf Switzerland2 umschrieb, zeigt die Post-Mortem-Analyse des Betreibers. Die mit Ansible erzeugte Accept-Liste mit 60 Portbereichen wurde entfernt. Fünf Reject-Zeilen für die Ports 25, 465, 587, 993 und 995 wurden hinter „# end of torrc“ angehängt. Beide Switzerland2-Relays veröffentlichten das Ergebnis am 2. Oktober um 09:34:04 Uhr.

Wie die übrigen Relays fielen, ist ungeklärt. Ars merkt an, die Ermittler hätten nicht feststellen können, wie alle 333 betroffenen Server übernommen wurden. Ein Muster deutet allerdings auf das Hosting hin: 71 der 101 Fremd-Relays bei FranTech Solutions wurden umgestellt, aber nur 13 der 9.054 Relays, die anderswo gehostet werden. Das ist eine Korrelation, kein Beweis für eine Kompromittierung des Anbieters.

02Die zwei Nutzlasten: SSH und Mail

SSH. Verkehr zu Port 22 verließ die kompromittierten Exits in Richtung eines von 12 Abfangservern. Der Abfangserver präsentierte seinen eigenen Host-Key, zeichnete jedes eingetippte Passwort auf und meldete sich dann am echten Server an, sodass die Sitzung normal aussah. Wer die Warnung von OpenSSH vor einem geänderten Host-Key ignorierte, gab damit seine Zugangsdaten preis und ermöglichte dem Angreifer einen Live-Blick auf die Sitzung. Ars berichtet zudem von einem dritten Schritt: Der Angreifer öffnete eine weitere Verbindung, um Ebury auf dem Zielsystem zu platzieren. In kabas Honeypot gab sich der Client des Angreifers als paramiko zu erkennen, prüfte die User-ID und passwortloses sudo und führte dann einen base64-kodierten Perl-Befehl aus, um Ebury zu installieren.

Die Erkennung war schwieriger, als die Warnung vermuten lässt. Nur rund ein Dutzend Exits lieferte einen gefälschten Host-Key aus. Die übrigen etwa 300 leiteten den Verkehr über dieselben Server um, ohne den Schlüssel zu verändern. Wer über einen dieser Exits einen Server erreichte, bemerkte nichts Ungewöhnliches, der Server sah aber eine Verbindung von der Adresse eines Abfangservers statt der des Exits.

Mail. Die Mail-Änderung ist subtiler, als Ars’ Kurzfassung nahelegt, denn nicht jeder blockierte Port ist ein reiner Verschlüsselungsport. Die Analyse des Betreibers führt 25, 587 und das Paar 110/143 als „TLS optional“ auf. Nur 465, 993 und 995 sind Ports mit implizitem TLS. Die endgültige Policy blockierte den Mailversand und das verschlüsselte Mail-Lesen, ließ aber Klartext-POP3 (110) und -IMAP (143) offen. Der Betreiber weist außerdem darauf hin, dass die erste Policy, die der Angreifer ausprobierte, das Gegenteil bewirkte: Sie blockierte Klartext-POP3 und -IMAP und wurde durch die später aktive Variante ersetzt.

Daraus lässt sich schließen, dass Clients, die TLS versuchen und bei Misserfolg zurückfallen, in den Klartext gedrängt würden. Ein Exit-Relay liest alles mit, was im Klartext hinausgeht, und kann auch die STARTTLS-Aushandlung entfernen. Auf den meisten Relays öffnete die Änderung zudem Klartext-POP3 und -IMAP. Ob ein Mail-Client tatsächlich auf Klartext herabgestuft wurde, ist unbekannt, wie Ars anmerkt.

03Umfang, Dauer und Aufräumarbeiten

Ars datiert die Übernahme auf den 2. bis 5. Oktober. Andere Darstellungen bemessen das Policy-Fenster anders. Die Switzerland2-Policy lief rund 52 Stunden auf zwei Guard+Exit-Relays, die etwa 3,4 TiB pro Tag bewegten. Ebury selbst existiert schon deutlich länger als die Kampagne. ESET schätzte 2024, die Malware habe seit 2009 rund 400.000 Linux-Server infiziert.

• Anteil am Netzwerk: Auf dem Höhepunkt, am 4. Oktober um 01:00 UTC, trugen die gekaperten Relays 7,46 % des nutzbaren Exit-Gewichts von Tor.
• Breiterer Policy-Abgleich: Eine Analyse der Verzeichnisdaten zählte 377 Relays von 59 Betreibern, die zwischen dem 1. und 4. Oktober die Exit-Policy des Angreifers übernahmen. Die Analyse selbst bezeichnet das als Policy-Übereinstimmung, nicht als Beweis für eine Kompromittierung.
• Reaktion: Kaba meldete den Vorfall am Abend des 2. Oktober. Die Directory Authorities begannen am Abend des 4. Oktober, BadExit zu setzen, und bis 17:00 UTC am 5. Oktober war kein Relay mit der Policy des Angreifers mehr im Consensus. Als die Angreifer am 5. Oktober viele Relays neu starteten, beschränkten die Flags sie auf den Betrieb als Middle-Relay.

Kaba zufolge teilte ihm das Network-Health-Team von Tor mit, einen solchen Angriff noch nicht gesehen zu haben.

04Was das über das Vertrauensmodell von Tor aussagt

Tor trennt, wer man ist, von dem, was man sendet. Den Inhalt schützt es nicht, sobald er den Exit verlässt. Der langjährige Rat des Tor Project lautet, Ende-zu-Ende-Verschlüsselung wie HTTPS zu verwenden, weil der Exit unverschlüsselten Verkehr sieht. Missbrauch an Exits ist nicht neu. Eine Studie der Karlstad University aus dem Jahr 2014 fand 19 Exit-Relays, die selbstsignierte Zertifikate für Man-in-the-Middle-Angriffe auf HTTPS und SSH einsetzten. 2020 berichtete der Forscher nusenu, Angreifer hätten auf dem Höhepunkt 380 Exit-Relays betrieben, womit Nutzer eine Chance von etwa eins zu vier hatten, auf einen bösartigen Exit zu treffen.

Neu ist hier der Mechanismus. Es handelte sich um Relays ehrlicher Betreiber, die durch gewöhnliche Kompromittierung der Hosts umgedreht wurden, und die Exit-Policy war der Hebel. Das Network-Health-Team beschrieb den Angreifer so, dass er torrc-Dateien bearbeitete, um Nicht-Exit-Relays in Exits zu verwandeln. Wirksam war die Beobachtung von außen: exitmap-Scans, Verzeichnisdaten und ein Forscher, der eine Warnung nicht einfach wegklickte. Auch die Betrachtung auf Family-Ebene hilft. Die Onionoo-Abfrage des Betreibers zeigte 168 Relays auf 57 IPs, die dieselbe nahezu offene Policy ankündigten. Das Tor-Netzwerk vertraut darauf, dass die Hosts der Freiwilligen unkompromittiert bleiben, und ein einziges durchgesickertes Passwort kann sich zu einem Ereignis auf Netzwerkebene auswachsen.

05Erkennung und Gegenmaßnahmen

Für Nutzer und SSH-Administratoren:

1. Eine Warnung vor einem geänderten Host-Key ist als Sicherheitsvorfall zu behandeln. Wer nach dem Akzeptieren eines neuen Schlüssels ein Passwort eingegeben hat, sollte es als gestohlen betrachten, ändern und das Zielsystem auf Ebury prüfen.
2. Passwortauthentifizierung zugunsten von Schlüsseln deaktivieren, wie Ars empfiehlt. Ein Man-in-the-Middle erbeutet dann nichts Wiederverwendbares. Host-Keys mit striktem Checking fest hinterlegen oder SSH-Zertifikate verwenden.
3. Administrative Dienste nach Möglichkeit über einen Onion-Service erreichen, damit kein Exit beteiligt ist. Das ist allgemeine Praxis und wird in den Quellen nicht behandelt.
4. Implizites TLS (465, 993, 995) verwenden und Clients so konfigurieren, dass sie Klartext verweigern, statt darauf zurückzufallen.

Für Relay-Betreiber und Netzwerkteams:

• Alarm bei jeder Änderung der Exit-Policy auslösen, die nicht von Ihrem Configuration Management stammt. Den veröffentlichten Deskriptor mit dem beabsichtigten vergleichen.
• Wie kaba Canary-Probes über Exits laufen lassen und dabei sowohl den präsentierten Schlüssel als auch die vom Ziel gesehene Quelladresse prüfen.
• Betreiberpasswörter nicht wiederverwenden und für Jump-Hosts ausschließlich Schlüsselzugang verlangen.
• Davon ausgehen, dass ein sauber wirkender Host nicht sauber sein muss. Ebury 1.8.3 ist neuer als die öffentlichen Indikatoren von ESET, und der Betreiber fand weder eine NAT-Umleitung noch neue Benutzer oder ein verändertes tor-Binary. Backdoor-Anmeldungen hinterlassen weder Login-Einträge noch Shell-Historie. Experten raten, Relays vom Netz zu nehmen, ein Snapshot der Platte zu erstellen und sie von Grund auf neu aufzusetzen, statt sie an Ort und Stelle zu bereinigen.

06Was unbewiesen bleibt

Mehrere Fragen sind offen. Dazu gehören, wie auf die anderen Relays zugegriffen wurde, warum Switzerland2 den nicht aufgeführten Schlüssel akzeptierte und wer dahintersteckt. Kaba sagt, der Einsatz von Ebury und das Abgreifen unverschlüsselter Daten deuteten auf eine finanziell motivierte Gruppe hin, er kennzeichnet das aber als Spekulation. Léveillé ist der Ansicht, angesichts der Reichweite von Ebury gebe es höchstwahrscheinlich weitere kompromittierte Tor-Relays. Niemand hat gezeigt, wie viele Passwörter abgegriffen wurden oder ob Mails herabgestuft wurden.