Ing. Calogero Bono
Die SSHole-Schwachstelle bei OpenSSH, erfasst als CVE-2026-123158, wird in echten Angriffen ausgenutzt. Laut BleepingComputer begannen die ersten Versuche am 5. November, dem Tag, an dem ein Demonstrationsexploit auftauchte, und am Tag darauf gab es den ersten Erfolg. Die Lücke erlaubt es in bestimmten Konfigurationen, sich ohne Kenntnis des Passworts in Linux-Konten einzuloggen. Wenn du Server mit Alpine Linux oder schlanke Container betreibst, betrifft dich das direkt.
Ein paar Begriffe, bevor wir zu den Fakten kommen OpenSSH ist die Software, mit der du dich aus der Ferne mit Servern verbindest. musl ist eine alternative C-Bibliothek zu der gebräuchlicheren, etwa in Alpine Linux verwendet. PAM ist das modulare System, das die Authentifizierung unter Linux verwaltet. Passwort-Hash ist der Wert, mit dem das System das Passwort in nicht lesbarer Form speichert. C2 ist der Command-and-Control-Server, über den Angreifer die Malware steuern.
Was ist SSHole und wie funktioniert es?
Laut BleepingComputer hat der Forscher Ozgun Kultekin die Lücke öffentlich gemacht. Sie betrifft OpenSSH auf Linux-Systemen mit musl, darunter Alpine, das in Cloud- und virtuellen Umgebungen stark verbreitet ist.
Der Mechanismus funktioniert so. Manche Konten haben im Passwortfeld ein Sternchen, um den Passwort-Login zu verhindern. Wird ein zu langes Passwort gesendet, gibt die Hash-Funktion von musl ein Sternchen als Fehler zurück. OpenSSH hält das für eine Übereinstimmung mit dem gespeicherten Wert und lässt den Zugriff zu.
Darüber haben wir bereits in unserem Artikel zum *sshole-Bug bei Alpine-Linux-Konten berichtet.
Welche Systeme sind wirklich gefährdet?
The Hacker News nennt einen CVSS-Wert von 8,1 und beschreibt die Bedingungen. Nötig sind Linux mit OpenSSH auf musl und deaktiviertem PAM, was auch die Standardkonfiguration des OpenSSH-Servers unter Alpine umfasst.
Kultekin erklärt, dass bestimmte Authentifizierungseinstellungen nötig sind und dass Konten mit gültigem Hash nicht betroffen sind. Root-Zugriff ist dort möglich, wo das kompromittierte Konto administrative Rechte ohne Passwort hat.
Was tun die Angreifer?
Laut GreyNoise erfolgte die erste erfolgreiche Ausnutzung am 7. November um 00:46 UTC, rund 40 Stunden nach der Korrektur. Das Unternehmen registrierte 16 erfolgreiche Angriffsketten gegen Netzwerke, die es schützt, von sechs IP-Adressen aus. Es betont jedoch, dass diese nicht die Gesamtaktivität widerspiegeln.
Die Angreifer erkundeten System und Container, fragten Cloud-Metadatendienste ab, versuchten Hashes und SSH-Schlüssel von root auszulesen und die Datei authorized_keys zu verändern, um im System zu bleiben. Previdian berichtet von 20 Versuchen von 13 IP-Adressen in neun Ländern. watchTower beobachtete Nutzungen im Zusammenhang mit Botnetzen und Cryptomining.
Was ist TAC Agent?
Es handelt sich um einen Python-basierten Command-and-Control-Agenten, der bei einem Angriff auf ein System installiert wird, auf dem die Angreifer Root-Rechte erlangt haben. Laut BleepingComputer führt er Befehle aus, betreibt umfangreiche Erkundung, lädt und überträgt Dateien und kann sich selbst aktualisieren. Eine eingebaute Persistenz hat er nicht, deshalb richten die Angreifer einen Startdienst ein.
In dem beobachteten Fall konnte er den C2-Server nicht erreichen und erhielt nie Aufgaben. Ars Technica führt die Aktivität unter Berufung auf GreyNoise auf eine Gruppe namens GT10 zurück und weist darauf hin, dass die Backdoor chinesische Kommentare enthält und offenbar mit KI erzeugt wurde. Dieselbe Gruppe installiert Python3, wo es fehlt.
Grenzen, die du kennen solltest
Wir wissen nicht, wie viele Systeme kompromittiert wurden. GreyNoise selbst sagt, dass ihre 27,5 Millionen Scans auf Port 22 und 20,1 Millionen SSH-Sitzungen nicht bestätigte SSHole-Angriffe sind. Chinesische Kommentare reichen für die Zuordnung nicht aus, und die Quellen sind sich nicht einig, wer dahintersteckt. Ars Technica spricht von einer Gruppe namens GT10, BleepingComputer erwähnt sie nicht.
Was sich für alle ändert, die mit digitaler Technik arbeiten
Wenn du Linux-Server verwaltest, aktualisiere OpenSSH auf Version 10.6p2, die am 5. November veröffentlicht wurde. Alternativ deaktivierst du die Passwort-Authentifizierung per SSH, wie BleepingComputer empfiehlt. Prüfe danach erfolgreiche Passwort-Logins bei Konten mit Sternchen in /etc/shadow, nicht autorisierte SSH-Schlüssel sowie Dateien und Startdienste von TAC Agent. Wer Alpine in Containern nutzt, sollte die Images neu bauen. Hast du Server bei Dritten, frag nach, ob sie aktualisiert wurden, zum Beispiel bei einem Hosting mit verwalteten Sicherheitsupdates.
Unsere Einschätzung
Der Fall zeigt, wie zerbrechlich das Vertrauen in einen Fehlerwert ist. Ein von einer Bibliothek zurückgegebenes Sternchen wird zu einem gültigen Schlüssel für eine andere Komponente. Das ist keine exotische Lücke, sondern ein Fehler an der Schnittstelle zweier Komponenten. Am aufschlussreichsten ist das Tempo. Der Angriffscode tauchte rund vier Stunden nach der Korrektur auf. Der Abstand zwischen Patch und Ausnutzung misst sich inzwischen in Stunden, und wer erst Ende des Monats aktualisiert, ist schon zu spät dran.
Häufig gestellte Fragen
Betrifft SSHole alle Linux-Server?
Nein. Betroffen ist OpenSSH auf Systemen mit musl und deaktiviertem PAM, wie der Standardkonfiguration von Alpine. Zusätzlich braucht es bestimmte Authentifizierungseinstellungen.
Welche Version von OpenSSH ist korrekt?
Version 10.6p2, veröffentlicht am 5. November laut BleepingComputer. Das Aktualisieren ist die wichtigste Maßnahme.
Was tue ich, wenn ich nicht sofort aktualisieren kann?
Deaktiviere die Passwort-Authentifizierung per SSH, wie BleepingComputer vorschlägt. Prüfe danach verdächtige Zugriffe.
Wonach suchen die Angreifer?
Laut GreyNoise nach Passwort-Hashes, SSH-Schlüsseln von root und Cloud-Metadaten. Sie versuchen auch, authorized_keys zu verändern, um im System zu bleiben.
Woran erkenne ich TAC Agent?
Suche nach seinen Dateien und den dafür angelegten Startdiensten. BleepingComputer rät außerdem, nach nicht autorisierten SSH-Schlüsseln zu suchen.
Worauf du in den nächsten Wochen bei SSH und musl achten solltest
Die Lage ist noch in Bewegung, neue Daten werden von denen erwartet, die die Angriffe beobachten. Am besten konzentrierst du dich auf wenige konkrete Punkte.
- Verfolge die Updates von GreyNoise und Previdian zur Zahl der kompromittierten Systeme.
- Prüfe, wann deine Distribution korrigierte Alpine-Images mit OpenSSH bereitstellt.
- Überprüfe, welche Konten in /etc/shadow ein Sternchen haben und ob du sie noch brauchst.
