OpenSSH SSHole. Die Schwachstelle umgeht die Authentifizierung auf Linux-Systemen mit musl, wie Alpine, wenn PAM nicht verwendet wird. GreyNoise hat 16 erfolgreiche Ausnutzungsversuche und die Installation des TAC Agent protokolliert, einem Command-and-Control-Agenten, der in Python geschrieben ist.

SSHole, die OpenSSH-Schwachstelle mit der Kennung CVE-2026-123158, wird in realen Angriffen ausgenutzt. Am 9. November hat die CISA sie dem Katalog für aktiv ausgenutzte Schwachstellen (KEV) hinzugefügt und fordert US-Behörden auf, die Patches bis zum 12. November zu installieren.
OpenSSH SSHole: Warum das wichtig ist
Die als CVSS 8,1 bewertete Schwachstelle ermöglicht es, die Authentifizierung auf Linux-Systemen zu umgehen, die auf musl basieren – einer alternativen C-Bibliothek zur weitverbreiteten libc –, darunter auch Alpine, eine in Cloud- und Virtualisierungsumgebungen häufig eingesetzte Distribution. Das Problem wurde am 5. November vom Forscher Ozgun Kultekin öffentlich gemacht. Am selben Tag veröffentlichten die OpenSSH-Wartungsverantwortlichen Version 10.6p2 mit dem Fix, und etwa vier Stunden später kursierte bereits ein Proof-of-Concept-Exploit.
Die ersten Ausnutzungsversuche wurden zwischen dem 5. und 6. November festgestellt. Der erste von GreyNoise protokollierte erfolgreiche Angriff erfolgte am 7. November (UTC), rund 40 Stunden nach der Patch-Veröffentlichung. Defused, ein finnisches Sicherheitsunternehmen, beobachtete eine kleine Anzahl an Akteuren, die versuchen, SSHole auszunutzen, und stellte klar, dass die Aktivität noch nicht weit verbreitet ist.
WatchTowr meldete am 6. November Ausnutzungen, die auf Botnets und Cryptomining zurückzuführen sind. Die Sensoren von Previdian registrierten 20 Versuche von 13 IP-Adressen in neun Ländern; andere Berichte bestätigen diese Daten mit 22 Versuchen von 14 Adressen.
Die von GreyNoise einsehbare Liste der Quelladressen beginnt am 5. November und füllt sich ab dem 6. November weitgehend mit Amazon-Adressen, die Paramiko als Client angeben – eine SSH-Bibliothek für Python. Die Liste klassifiziert diese als schädlich oder verdächtig, ohne jedoch anzugeben, welche Ereignisse erfolgreich waren.
Der Angriff trifft Konten, deren Passwortfeld in /etc/shadow einen Stern (*) enthält – die Konvention, um den Zugriff per Passwort zu verhindern, was für bestimmte Kontotypen Standard ist. Wenn der OpenSSH-Server für eines dieser Kontos ein Passwort mit mehr als 256 Zeichen erhält, schlägt die Hash-Funktion von musl fehl und gibt genau * zurück. OpenSSH interpretiert diesen Wert fälschlicherweise als Übereinstimmung mit dem im Konto gespeicherten Wert und gewährt den Zugriff.
Red Hat beschreibt die Ursache als „falsche Interpretation der Tatsache, dass eine Zeichenkette als Passwort-Hash bestimmt ist“. OpenSSH muss auf musl laufen und ohne PAM (die anbindbaren Authentifizierungsmodule). Die Konfiguration muss zudem mindestens ein Konto vorsehen, das mit einem als SHA256- oder SHA512-Hash gespeicherten Passwort erreichbar ist, zusätzlich zu den Konten ohne Passwort.
Laut Kultekin sind Konten mit gültigem Hash nicht betroffen, und der Zugriff kann bis zum root-Konto reichen, wenn das kompromittierte Konto administrative Privilegien ohne Passwort besitzt. Der Pool exponierter Maschinen bleibt dennoch groß, insbesondere unter Alpine-Systemen, und das Identifizieren verwundbarer Server scheint nur Sekunden zu dauern.
GreyNoise hat 16 erfolgreiche Ausnutzungsversuche gegen die von ihm geschützten Netzwerke protokolliert; andere Berichte bestätigen diese Zahl mit 18. Sechs Quelladressen waren mit Aktivitäten nach der Kompromittierung verbunden. Das Unternehmen stellt klar, dass diese Angriffe nicht die gesamte SSHole-bezogene Aktivität darstellen.
Was ändert sich und welche Auswirkungen hat das?
Die Angreifer führten eine Aufklärung des Systems und der Container durch, befragten die Metadatendienste der Cloud-Provider, versuchten, Passwort-Hashes und SSH-Schlüssel von root zu lesen, und modifizierten die Datei authorized_keys, um sich einen persistenten Zugriff zu sichern. Laut GreyNoise beliefen sich die Scans auf Port 22 auf 27,5 Millionen und die SSH-Session-Versuche auf 20,1 Millionen; dies sind keine bestätigten SSHole-Angriffe.
In einem Fall erlangte der Angreifer root-Privilegien und installierte TAC Agent, einen in Python geschriebenen Command-and-Control-(C2)-Agenten. Die Installation konnte ihren Server unter tac.vpnla[.]org nicht erreichen und erhielt nie Anweisungen. Die Analyse der Payload zeigt, dass er Shell-Befehle ausführen, eine erweiterte Systemaufklärung durchführen, Verzeichnisse auflisten, Dateien in beide Richtungen übertragen und sich selbst aktualisieren kann. Er verfügt über keine eigenen Persistenzmechanismen, weshalb die Angreifer versuchen, einen Dienst beim Start zu konfigurieren.
GreyNoise beobachtete auch die Installation von Python3 auf Maschinen, denen es fehlte, da der Agent dies zum Laufen benötigt. Die Honeypots, die GreyNoise in Südostasien betreibt, wurden von einer Gruppe angegriffen, die das Unternehmen als GT10 einstuft und für „reife Intrusionen“ verantwortlich macht. GreyNoise erlangte anschließend Zugriff auf einen Server der Gruppe, wo weitere potenzielle Opfer und Teile des Kampagnen-Werkzeugs gefunden wurden.
Kommentare, Logs und Fehlermeldungen der Backdoor sind auf Chinesisch; dies könnte zusammen mit anderen Elementen helfen, den Ursprung der Angriffe zu ermitteln. Der Code scheint mit Hilfe von künstlicher Intelligenz generiert worden zu sein. Es fehlt zudem eine Überprüfung der Anwesenheit von Werkzeugen, die ein nützliches Feedback für einen automatischen Planer zur Korrektur von Befehlen liefert; dies deutet auf eine zumindest teilweise automatisierte Operation hin.
Administratoren sollten OpenSSH so schnell wie möglich aktualisieren oder die SSH-Authentifizierung per Passwort auf den betroffenen Systemen deaktivieren. Wer musl verwendet, sollte seine Exposition überprüfen. Gesucht werden erfolgreiche Zugriffe mit Passwort auf Konten, deren Feld in /etc/shadow * ist, unbefugte SSH-Schlüssel, TAC-Agent-Dateien und Startdienste, die erstellt wurden, um ihn aktiv zu halten.
Quelle und weiterführende Informationen zu OpenSSH SSHole: Originalartikel.
* Inhalt mit Unterstützung von Systemen künstlicher Intelligenz erstellt.
Hardware Ready Ready to Bench?