Entdeckt wurde das Problem vom Sicherheitsforscher Ozgun Kultekin; behoben ist es in OpenSSH 10.6p2. Die Ursache reicht bis zu einem Patch aus dem Jahr 2016 zurück, der die Username-Enumeration-Schwachstelle CVE-2016-6210 beheben sollte. Unter bestimmten Bedingungen deutet die Passwortverarbeitung in OpenSSH einen fehlgeschlagenen Hashing-Vorgang fälschlich als erfolgreiche Authentifizierung, weil sie denselben Wert („*“) erzeugt, mit dem auf Systemebene ein deaktiviertes Passwort gekennzeichnet wird.

Konkret genügt ein beliebiges Passwort mit einer Länge zwischen 257 und 1.024 Byte: Der Hash-Versuch scheitert, zurückgegeben wird ein Sternchen, und sshd vergleicht dieses mit dem im Passwortfeld des Kontos hinterlegten Sternchen — die Anmeldung gelingt. Voraussetzung ist mindestens ein Konto, dessen Passwort-Hash aus einem Sternchen besteht. Konten mit gültigem Passwort-Hash lassen sich auf diesem Weg nicht umgehen.

Nicht betroffen sind Dropbear, glibc-basierte Linux-Distributionen, Nicht-Linux-Systeme sowie Systeme, die Passwörter über PAM prüfen.

„Ein erfolgreicher SSHole-Angriff gewährt Zugriff mit den bestehenden Berechtigungen des kompromittierten Kontos“, erklärte Safe Security. „Für Unternehmen hängen die Folgen von SSHole von den Privilegien des kompromittierten Kontos ab.“ Unmittelbare Auswirkung sei der unbefugte SSH-Zugang; Angreifer könnten darüber hinaus an Deployment-Zugangsdaten, Anwendungsgeheimnisse und angebundene Infrastruktur gelangen, was seitliche Bewegung im Netz oder Dienststörungen ermöglichen könne.

Das Threat-Intelligence-Unternehmen Previdian beobachtete den ersten Ausnutzungsversuch weniger als neun Stunden nach Veröffentlichung der CVE. Auf einem Honeypot mit Alpine Linux und OpenSSH bestätigte das Unternehmen erfolgreichen Root-Zugriff. Die Telemetriedaten zeigen insgesamt acht Ausnutzungsversuche von einer IP-Adresse, die nach Japan verortet wird.

„Die beobachtete Quell-IP, 89.116.89[.]18, nutzte übergroße Passwörter, um die Authentifizierung zu umgehen, und führte über nicht-interaktive SSH-Sitzungen Erkundungsbefehle wie id, uname und hostname aus“, erklärte Ryan Dewhurst, Gründer und CEO von Previdian.

Betroffenen Nutzern wird empfohlen, OpenSSH 10.6p2 oder das gepatchte Paket ihrer Distribution zu installieren und anschließend sshd neu zu starten. Alpine rät zusätzlich, Protokolleinträge vom Typ „Accepted password for“ zu prüfen, die Konten betreffen, die keine Passwortanmeldung akzeptieren dürften:

  • In /var/log/messages nach sshd-Zeilen mit „Accepted password for“ für ein Konto ohne Passwort suchen (alpine, root oder beliebige Nur-Schlüssel-Nutzer).
  • Die Nutzung von doas sowie kürzlich angelegte Benutzer, Dateien und authorized keys auf exponierten Maschinen überprüfen.
  • Lässt sich eine Anmeldung nicht ausschließen, ist die Maschine als kompromittiert zu behandeln.