23. Oktober 2026kaba.cx · SicherheitKuratiert

Tor-Exits als SSH-Falle: Was 333 kompromittierte Relays über Ebury lehren

Zusammenfassung

Auf kaba.cx beschreibt eine betroffene Person, wie ab dem 2. Oktober 2026 rund 333 Tor-Exit-Relays SSH-Verbindungen auf Abfangserver umleiteten und wie diese Relays aufgespürt und aus dem Netz genommen wurden. Hinter dem Angriff steckte die seit Jahren bekannte OpenSSH-Hintertür Ebury in Version 1.8.3, die schon im August auf den Servern der Relay-Betreiber installiert worden war. Der Beitrag ergänzt das um den Vorfallsbericht eines betroffenen Betreibers und zeigt, woran man Ebury erkennt und warum Schlüssel statt Passwörter hier den Unterschied machen.

Was passiert ist

Am Freitag, dem 2. Oktober 2026, begannen laut kaba.cx 333 infizierte Exit-Relays um 09:35 Uhr mit einer abgestimmten Kampagne. Das Tor-Netz hat rund 3000 Exits, die Angreifer kontrollierten also etwa ein Zehntel. Ziele waren unverschlüsselter Mailverkehr und das Abfangen von SSH-Verbindungen: Wer über einen dieser Exits eine Verbindung zu Port 22 aufbaute, landete unbemerkt bei einem von zwölf Abfangservern, während verschlüsselter Webverkehr normal durchlief.

Bemerkbar machte sich das nur durch die Warnung „REMOTE HOST IDENTIFICATION HAS CHANGED“. Wer sie übergeht, verliert laut kaba.cx dreierlei: Das Passwort wird gestohlen, die Sitzung zum echten Server wird mitgelesen, und über eine zweite Verbindung wird auch dieser Server mit Ebury infiziert.

Am 4. Oktober informierte das Network-Health-Team von Tor die Betreiber und markierte die Relays als BadExit, Clients nutzten sie danach nicht mehr als Ausgang. Am 5. Oktober starteten die Angreifer viele Relays neu, die aber nur noch als Middle-Relays arbeiten konnten; noch am selben Tag waren alle infizierten Server abgeschaltet. In seiner Ankündigung schrieb das Tor-Team, die Angreifer verwandelten übernommene Middle-Relays durch Änderungen an der torrc in Exits.

Wie die Abfangserver gefunden wurden

Mit dem Werkzeug exitmap des Tor Projects wurde jeder der rund 3000 Exits einzeln festgelegt und darüber eine SSH-Verbindung zwischen zwei eigenen Servern aufgebaut. Server A prüfte den Fingerabdruck von Server B, Server B prüfte, ob die Verbindung vom festgelegten Exit oder von einem der zwölf Abfangserver kam. Etwa ein Dutzend Exits lieferte einen falschen Fingerabdruck, über 300 leiteten nur über dieselben Abfangserver um; schon das genügte als Nachweis.

Ein SSH-Honeypot (sshesame) zeigte, dass die Abfangserver die Python-Bibliothek paramiko nutzten und Ebury über ein base64-kodiertes Perl-Skript per sudo nachluden, nachdem sie geprüft hatten, ob sudo ohne Passwort möglich ist.

Was ein betroffener Betreiber fand

Die Betreiber der Relay-Familie Quetzalcoatl haben ihren Vorfall auf der Mailingliste tor-relays ausführlich dokumentiert. Die Ursache war hausgemacht: Ein Passwort diente gleichzeitig für die SSH-Anmeldung, für sudo und als Passphrase eines Backups, stand im Klartext in einem Hilfsskript, und auf dem öffentlich erreichbaren Verwaltungsserver war die Passwort-Anmeldung aktiv. Am 28. August meldeten sich die Angreifer damit im ersten Versuch an und hatten fünf Minuten später root.

Ebury 1.8.3 bestand dort aus einer einzigen Datei, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 mit gesetztem setuid-Bit, auf die der Symlink libkeyutils.so.1 umgebogen war. Das echte Paket blieb unverändert, deshalb fand die Paketprüfung mit dpkg -V oder debsums nichts. Unter Debian 13 lädt sshd-session die Bibliothek über libkrb5, und weil sie im SSH-Dienst sitzt, sieht sie jedes Passwort im Klartext, auch fehlgeschlagene Versuche und die Passwörter der Ermittler.

Die Angreifer schalteten die Protokollierung von sshd herunter, und Anmeldungen über die Hintertür hinterlassen weder Login-Einträge noch Shell-History. Auffällig waren nur root-Aktionen, die kein angemeldeter Benutzer ausgelöst haben konnte. Auf zwei Exit-Relays änderten sie die Exit-Policy so, dass unverschlüsseltes POP3, IMAP, Telnet und SSH offen, die TLS-Mailports aber gesperrt waren; das lief etwa 52 Stunden bei rund 3,4 TiB Verkehr pro Tag. Die angeblich offline gelagerten Relay-Schlüssel lagen als Kopie im Backup auf dem kompromittierten Server.

Warum Schlüssel hier schützen

Bei der Anmeldung mit einem SSH-Schlüssel signiert der Client einen Wert, der an die jeweilige Verbindung gebunden ist. Ein Abfangserver kann diese Signatur deshalb nicht an den echten Server weiterreichen, anders als ein Passwort. Den Schutz hebt man aber wieder auf, wenn man über eine verdächtige Verbindung den SSH-Agenten weiterreicht (ForwardAgent) oder die Warnung zum Host-Schlüssel wegklickt und dann ein Passwort eingibt.

Ideen

Eine Host-Key-Warnung ist ein Alarm, kein Hinweis zum Wegklicken.
Exit-Relays sehen jeden Verkehr, der nicht Ende zu Ende verschlüsselt ist.
Ein Passwort für SSH, sudo und Backup öffnet alle Türen gleichzeitig.
Paketprüfungen finden keine zusätzliche Datei, auf die ein Symlink zeigt.
Eine Hintertür im SSH-Dienst sieht Passwörter, bevor sie geprüft werden.
Externe Überwachung der veröffentlichten Konfiguration erkennt Manipulationen, die Logs verschweigen.
Offline gedachte Schlüssel sind nur offline, wenn keine Kopie online liegt.

Einsichten

Der Angriff nutzte keine neue Lücke, sondern alte Bequemlichkeit: wiederverwendete Passwörter, Passwort-Anmeldung im Internet und ein zentraler Verwaltungsserver ohne Abschottung. Von dort aus reichte eine bekannte Hintertür, um eine ganze Relay-Familie zu übernehmen.
Tor schützt die Anonymität, nicht den Inhalt. Wer über Tor ein unverschlüsseltes oder schlecht geprüftes Protokoll nutzt, vertraut einem unbekannten Exit; für SSH über Tor sind Onion-Dienste der sichere Weg, weil die Verbindung das Tor-Netz nie verlässt.
Auf einem kompromittierten Server lügen Logs, Prozesslisten und Paketprüfungen. Belastbar sind nur Prüfungen von außen, etwa die öffentlich veröffentlichten Relay-Daten, oder von einem sauberen Rettungssystem aus.

Zitate

„We've not seen an attack like that before.“ (Tor Network Health Team, zitiert auf kaba.cx; sinngemäß: Einen solchen Angriff haben wir bisher nicht gesehen.)
„At the end of the day, relays/bridges need to be treated as highly targeted production machines.“ (George auf der Liste tor-relays, zitiert auf kaba.cx; sinngemäß: Relays und Bridges müssen als stark angegriffene Produktivsysteme behandelt werden.)

Fakten

Ab dem 2. Oktober 2026 fingen 333 von rund 3000 Tor-Exits SSH-Verbindungen über zwölf Abfangserver ab.
Am 4. Oktober markierte das Tor-Team die Relays als BadExit, am 5. Oktober waren alle infizierten Server abgeschaltet.
Ebury 1.8.3 ist laut Marc-Etienne M. Léveillé seit mindestens Juni 2026 im Umlauf und neuer als die zuletzt im Mai 2024 veröffentlichten Erkennungsmerkmale von ESET.
Laut Léveillé waren zwischen 2009 und 2023 rund 400.000 Server mit Ebury infiziert.
Unter Debian 13 wird die präparierte libkeyutils über libkrb5 in sshd-session geladen; dpkg -V und debsums melden nichts.

Referenzen

Bemerkungen

kaba.cx schildert den Fund als eigene Entdeckung; laut Betreiberbericht war das Network-Health-Team von Tor parallel auf die geänderten Exit-Policies gestoßen. Beide Wege führten am selben Wochenende zur Sperre.
Wie die Angreifer an die ersten Server kamen, ist offen. Léveillé hält eine Anmeldung von einem bereits mit Ebury infizierten Rechner oder einen kompromittierten Hoster für möglich.

Empfehlungen

Passwort-Anmeldung abschalten und die wirksame Einstellung mit sshd -T | grep -i passwordauthentication prüfen, denn sshd übernimmt den ersten gefundenen Wert, auch aus einem vergessenen Eintrag des Server-Images.
Host-Schlüssel neuer Server über einen zweiten Weg bestätigen, etwa per Konsole des Hosters oder SSHFP-Einträgen mit DNSSEC und VerifyHostKeyDNS yes; ForwardAgent nur für vertrauenswürdige Ziele aktivieren.
Auf Linux-Servern nach Ebury suchen, am besten von einem Rettungssystem aus: find / -xdev -name 'libkeyutils*' -perm -4000, dpkg -S "$(readlink -f /usr/lib/x86_64-linux-gnu/libkeyutils.so.1)" und grep @event- /proc/net/unix.
Keine Passwörter in Skripte schreiben und Logs auf einen getrennten Server ausleiten, damit ein Angreifer sie nicht nachträglich kürzen kann.

Originalbeitrag lesen

Im Webarchiv suchen