Ein für den Zugriff per SSH-Schlüssel vorgesehenes Konto konnte einen Angreifer dennoch über seine Passwortanmeldung ins System lassen.
Dieser Widerspruch steht im Zentrum von SSHole, einer neu entdeckten OpenSSH-Sicherheitslücke, durch die Angreifer die Authentifizierung auf bestimmten Linux-Systemen umgehen können, ohne das Passwort des Opfers zu kennen oder dessen privaten SSH-Schlüssel zu besitzen.
Die Lücke nutzt eine unerwartete Wechselwirkung zwischen OpenSSH und musl aus, einer schlanken C-Standardbibliothek, die von Alpine Linux verwendet wird, und verwandelt einen fehlgeschlagenen Vorgang zur Passwort-Hash-Berechnung in einen erfolgreichen Login.
Ars Technica berichtet, dass das Alpine-Basis-Image auf Docker Hub mehr als eine Milliarde Downloads verzeichnet. Diese Zahl sagt nicht aus, wie viele Systeme verwundbar sind; für eine Ausnutzung ist eine bestimmte Kombination aus Software, Einstellungen und Kontokonfigurationen erforderlich.
OpenSSH hat einen Fehlerbehebung veröffentlicht, Administratoren müssen ihn jedoch installieren und den SSH-Dienst neu starten. Systeme mit begrenzten Wartungsfenstern benötigen möglicherweise sofortige Gegenmaßnahmen, während die Teams ein Update vorbereiten.
Was für eine erfolgreiche SSHole-Ausnutzung erforderlich ist
Eine erfolgreiche Ausnutzung erfordert eine bestimmte Kombination aus Software, Authentifizierungseinstellungen und Kontokonfigurationen.
Erstens muss auf dem Zielsystem OpenSSH mit musl libc laufen, ohne dass Pluggable Authentication Modules (PAM) die Authentifizierung übernehmen. Außerdem muss die SSH-Authentifizierung per Passwort aktiviert sein, damit Angreifer Passwörter über den betroffenen Authentifizierungsmechanismus übermitteln können.
Für die Ausnutzung müssen außerdem zwei Bedingungen für Konten erfüllt sein:
- Das Zielkonto muss im Passwortfeld von /etc/shadow ein Sternchen (*) enthalten, was bedeutet, dass die normale Passwortauthentifizierung nicht verfügbar sein sollte.
- Ein anderes lokales Konto muss über einen nutzbaren SHA-256- oder SHA-512-Passwort-Hash verfügen, aus dem OpenSSH bei der Überprüfung einen Salt übernehmen kann.
Laut Alpinekann ein Angreifer, der den Benutzernamen des betroffenen Kontos kennt und den SSH-Dienst erreichen kann, ein System ausnutzen, das diese Bedingungen erfüllt. Anschließend kann er ein zwischen 257 und 1.024 Byte langes Passwort übermitteln.
Die Funktion crypt() von musl würde die Eingabe normalerweise ablehnen, weil sie das 256-Byte-Limit der Bibliothek überschreitet. Statt einen gültigen Passwort-Hash zurückzugeben, liefert die Funktion jedoch ein Sternchen (*), um anzuzeigen, dass die Hash-Berechnung fehlgeschlagen ist.
OpenSSH vergleicht dieses Ergebnis anschließend mit dem im Zielkonto gespeicherten Passwortfeld, das ebenfalls ein Sternchen enthält. Die beiden Werte stimmen überein, und OpenSSH interpretiert den fehlgeschlagenen Hash-Vorgang fälschlicherweise als erfolgreiche Authentifizierung. Dadurch erhält der Angreifer ohne das Passwort oder den privaten SSH-Schlüssel des Kontos Zugriff.
Wie lang bestehende Softwareverhalten eine Login-Umgehung ermöglichten
Das vielleicht Beunruhigendste an SSHole ist nicht nur, dass die Lücke Angreifern die Umgehung der Authentifizierung ermöglicht, sondern auch, wie lange die dafür nötigen Bedingungen unbemerkt blieben.
Die Sicherheitslücke entstand durch Softwareverhalten, das Jahre zurückreicht. Mit anderen Worten: Die einzelnen Komponenten verhielten sich wie vorgesehen, doch ihr Zusammenspiel führte zu einem Sicherheitsproblem, das jahrelang unentdeckt blieb.
Die PHP2Shell-Reaktion unterstreicht ebenfalls, warum Sicherheitsteams die tatsächlich ausgeführten Fehlerbehebungen überprüfen und frühere Zugriffe untersuchen müssen. Gleichzeitig weiten Dienste, die KI-gestützte Schwachstellenscans anbieten, ihre Bemühungen aus, übersehene Schwachstellen zu finden.
Für Sicherheitsteams besteht die praktische Lehre darin, zu testen, wie Authentifizierungskomponenten zusammenspielen – einschließlich der Fehlerpfade, die routinemäßige Login-Prüfungen möglicherweise nicht erfassen.
Seit Jahren helfen Sicherheitsbewertungen, Code-Reviews und Penetrationstests Unternehmen dabei, Schwachstellen zu erkennen. Sie können jedoch nicht garantieren, dass jeder mögliche Fehler gefunden wurde. Die jüngsten Fortschritte bei der KI-gestützten Schwachstellenforschung machen diese Einschränkung zunehmend deutlich, da Schwachstellen, die jahrelanger Prüfung standgehalten haben, nun auf eine Weise untersucht werden, die zuvor übersehene Angriffspfade aufdecken kann.
SSH-Dienste mit Internetzugriff verdienen besondere Aufmerksamkeit, da Angreifer sie aus der Ferne erreichen können.
Wie Jake Knott, Leiter der Bedrohungsanalyse bei watchTowr, erklärt, ist „SSH praktisch überall im Einsatz und für die Serververwaltung häufig öffentlich erreichbar, aber aufgrund der Voraussetzungen sind viele Systeme nicht betroffen.“
Dennoch geben diese Anforderungen Angreifern erkennbare Konfigurationen vor, nach denen sie suchen können. Knott verweist auf „die AWS- und Azure-Images von Alpine“ als das, „was wir wahrscheinlich zuerst als Ziel sehen werden“. Alpine stellt klar, dass betroffene Tiny-Cloud-Images beim ersten Start sicher sind, aber ausnutzbar werden, sobald ein geeigneter Passwort-Hash hinzugefügt wird.
Die aktive Ausnutzung separater SSH-Sicherheitslücken in MikroTikveranschaulicht die Risiken, denen exponierte Verwaltungsdienste ausgesetzt sind. Knott warnte, dass bestehende Aktivitäten zum Erraten von Passwörtern ebenfalls SSHole-Versuche aufnehmen könnten. Wie Knott es formuliert: „Die Ausnutzung dieser Sicherheitslücke bedeutet schlicht, dass dieselben Angreifer einen Versuch mit einem sehr langen Passwort in diese Brute-Force-Liste aufnehmen.“
„Wir wären äußerst überrascht, wenn wir nicht bis zum Wochenende sehen würden, dass Brute-Force-Angreifer gegen SSH dies versuchen. Der Versuch ist praktisch kostenlos, und wenn er funktioniert, ist es ein leichter Erfolg“, fügte er hinzu.
Dienst patchen und frühere Zugriffe untersuchen
OpenSSH hat Version 10.6p2am 5. November veröffentlicht, um die Umgehung zu beheben. Alpine stellt außerdem gepatchte Pakete für ältere Zweige bereit. Administratoren sollten daher den Sicherheitshinweis ihrer Distribution prüfen und sich nicht ausschließlich auf die Versionsnummer des Upstream-Projekts verlassen.
Sicherheitsteams sollten drei Schritte priorisieren:
- Betroffenheit prüfen: Überprüfen Sie, ob das System musl verwendet, die Passwortauthentifizierung aktiviert ist, PAM die Authentifizierung nicht übernimmt und die erforderlichen Kontobedingungen erfüllt sind.
- Fehlerbehebung anwenden: Installieren Sie das passende gepatchte Paket und starten Sie sshd neu. Durch die Aktualisierung des Pakets allein wird der laufende Daemon nicht ersetzt.
- Falls nötig Gegenmaßnahmen ergreifen: Stellen Sie zunächst sicher, dass der Zugriff per SSH-Schlüssel funktioniert. Setzen Sie dann PasswordAuthentication no, überprüfen Sie die Konfiguration und starten Sie sshd neu. Lassen Sie die bestehende Administrationssitzung geöffnet, bis eine neue schlüsselbasierte Anmeldung erfolgreich ist.
Überprüfen Sie außerdem frühere Aktivitäten. Alpine empfiehlt, /var/log/messages auf erfolgreiche Passwortanmeldungen bei Konten zu prüfen, die kein Passwort haben. Untersuchen Sie unerwartete Rechteausweitungen, neu angelegte Benutzer und Änderungen an autorisierten Schlüsseln.
Ein erfolgreiches Update schließt diese Authentifizierungsumgehung; es zeigt jedoch nicht, ob Angreifer zuvor auf das System zugegriffen haben. Verdächtige Anmeldungen sollten eine Untersuchung des Sicherheitsvorfalls auslösen.
Die übergeordnete Lehre besteht darin, die tatsächlich geltende Authentifizierungsrichtlinie des Servers zu überprüfen. Die Verwendung von SSH-Schlüsseln deaktiviert die Passwortanmeldung nicht automatisch, und ein für den schlüsselbasierten Zugriff vorgesehenes Konto kann über eine aktivierte alternative Anmeldemethode weiterhin angreifbar sein.
Mehr lesen: Erfahren Sie, wie Sie CWPdoor-Malware erkennen und entfernen, einschließlich der Warnzeichen und Wiederherstellungsschritte, die Administratoren von Linux-Servern prüfen sollten.