Alpine Linux SSH-Schwachstelle ermöglicht passwortlose Anmeldung durch lange Strings

Alpine Linux hat eine dringende Sicherheitsempfehlung für eine schwerwiegende Schwachstelle in seiner OpenSSH-Server-Implementierung herausgegeben. Der Fehler ermöglicht es Remote-Angreifern, die Passwortauthentifizierung vollständig zu umgehen und Shell-Zugriff auf betroffene Systeme zu erhalten, ohne dass Anmeldedaten erforderlich sind. Administratoren, die Alpine-Versionen 3.16 bis 3.24 verwenden, müssen ihre openssh-Pakete aktualisieren und den SSH-Daemon sofort neu starten, um diese Sicherheitslücke zu schließen.

Was passiert ist

Die Schwachstelle betrifft den sshd-Daemon, wenn er ohne Pluggable Authentication Modules (PAM) kompiliert wurde. Dies ist die Standardkonfiguration des regulären Alpine-Pakets openssh-server. Ein Angreifer, der den SSH-Port erreichen kann, kann sich als jeder Benutzerkonto anmelden, für das kein Passwort gesetzt ist, sofern das System mindestens ein anderes lokales Konto mit einem Standard-Passwort-Hash besitzt. Der Angriff erfordert nur einen einzigen Verbindungsversuch und gelingt zuverlässig ohne Wiederholungen oder Brute-Force-Techniken.

Dieses Problem betrifft eine breite Palette von Alpine-Releases, einschließlich der unterstützten Versionen 3.21 bis 3.24 sowie älterer, nicht mehr unterstützter Versionen ab 3.16. Es zielt speziell auf Systeme ab, bei denen PasswordAuthentication aktiviert ist, was der OpenSSH-Standard bleibt, es sei denn, es wird explizit deaktiviert. Häufige Szenarien sind Root-Konten, die mit PermitRootLogin yes konfiguriert sind, benutzerdefinierte Schlüsselkonten ohne Passwörter sowie Benutzer, die über Verzeichnisdienste wie SSSD oder Winbind verwaltet werden und keine lokalen Shadow-Einträge besitzen.

Offizielle tiny-cloud-Images sind besonders gefährdet, wenn sie nach dem ersten Start modifiziert wurden. Obwohl diese Images mit sicheren Standardeinstellungen ausgeliefert werden, führt das Hinzufügen eines Benutzers mit Passwort-Hash oder das Setzen eines Konsolenpassworts zu den Voraussetzungen für den Exploit. Sobald der Angriff ausgelöst wird, kann sich ein Angreifer als Standardbenutzer alpine anmelden und seine Rechte mit doas auf Root-Ebene erweitern, da dies in diesen Umgebungen für die passwortlose Nutzung konfiguriert ist.

Funktionsweise

Die Ursache liegt darin, wie OpenSSH die Passwortüberprüfung handhabt, wenn es ohne PAM-Unterstützung kompiliert wurde. In diesem Modus verwendet sshd die C-Bibliotheksfunktion crypt(), um das eingegebene Passwort zu hashen und es mit dem gespeicherten Hash in /etc/shadow zu vergleichen. Für Konten ohne Passwort enthält das gespeicherte Feld ein einzelnes Sternchen (*). Normalerweise benötigt crypt() einen Salt aus dem gespeicherten Hash, um die Eingabe zu verarbeiten, aber Konten mit * haben keinen Salt.

Wenn sshd auf ein solches Konto trifft, entlehnt es den Salt von einem anderen Konto auf dem System, das über einen gültigen $5$- oder $6$-Hash verfügt. Die Schwachstelle wird ausgelöst, wenn der Angreifer ein Passwortstring sendet, dessen Länge zwischen 257 und 1024 Bytes liegt. Die musl-C-Bibliothek, die von Alpine verwendet wird, gibt * als Fehlerindikator zurück, wenn Schlüssel verarbeitet werden, die länger als 256 Bytes sind. Da das gespeicherte Feld für das Zielkonto ebenfalls * ist, stimmt der Vergleich überein, und die Authentifizierung schlägt fehl bzw. wird erfolgreich abgeschlossen.

Wichtige Details

• Betroffene Versionen: Alpine 3.16 bis 3.24, einschließlich Edge- und nicht unterstützter Releases.
• Voraussetzungen: sshd ohne PAM gebaut (oder UsePAM no), PasswordAuthentication yes und mindestens ein Konto mit einem $5$- oder $6$-Hash.
• Zielkonten: Benutzer mit * im Passwortfeld, wie z. B. reine Schlüsselbenutzer oder der Standardbenutzer alpine.
• Behobene Pakete: Verfügbar für alle Zweige, einschließlich 9.9_p2-r1 für 3.21 und 10.6_p2-r0 für Edge.
• Erkennung: Prüfen Sie /var/log/messages auf Einträge Accepted password for, die mit Konten ohne Passwort verknüpft sind.
• Cloud-Risiko: Tiny-cloud-Images werden ausnutzbar, wenn nach dem Booten ein Passwort-Hash hinzugefügt wird.

Warum das wichtig ist

Für Infrastruktur-Ingenieure und DevOps-Teams untergräbt diese Schwachstelle die grundlegende Annahme, dass SSH-Konto-Authentifizierung ausschließlich über Schlüssel sicher gegen passwortbasierte Angriffe ist. Viele Organisationen verlassen sich auf Alpine für Container und leichte VMs und gehen oft davon aus, dass das Deaktivieren des Root-Passwort-Logins ausreicht. Dieser Bug umgeht jedoch diese Schutzmaßnahmen, indem er die Interaktion zwischen leeren Passwortfeldern und der Anwesenheit anderer gehashter Passwörter auf dem System ausnutzt. Er verdeutlicht die Risiken von Standardkonfigurationen in minimalen Distributionen, in denen PAM nicht verwendet wird.

Die einfache Ausnutzbarkeit macht dies besonders gefährlich. Im Gegensatz zu Brute-Force-Angriffen, die Lärm erzeugen und von fail2ban blockiert werden können, erfordert diese Methode nur ein einziges Paket und hinterlässt keine unmittelbaren Spuren fehlgeschlagener Versuche. Wenn ein Angreifer Zugriff auf eine Cloud-Instanz erhält, kann er schnell Rechte eskalieren und sich innerhalb des Netzwerks bewegen. Teams müssen nicht nur überprüfen, ob sie die Pakete aktualisiert haben, sondern auch, ob der laufende Daemon tatsächlich neu gestartet wurde, da Paketmanager Dienste nicht immer automatisch neu starten.

Was Sie tun können

• Aktualisieren Sie Ihr System sofort mit apk upgrade -U -a und stellen Sie sicher, dass Sie die behobene Version für Ihren Branch installieren.
• Starten Sie den SSH-Daemon explizit mit rc-service sshd restart nach dem Upgrade neu, da das Update allein den laufenden Prozess nicht neu lädt.
• Wenn Sie nicht sofort aktualisieren können, deaktivieren Sie die Passwortauthentifizierung, indem Sie PasswordAuthentication no in Ihrer SSH-Konfiguration setzen und den Dienst neu starten.
• Überprüfen Sie Ihre Konfiguration mit sshd -T | grep -i passwordauthentication, um sicherzustellen, dass die Änderung aktiv ist.
• Auditiere Sie Ihre Protokolle auf unerwartete Accepted password-Einträge für Konten, die keine Passwörter haben sollten.
• Überprüfen Sie Cloud-Instanzen auf hinzugefügte Benutzer-Passwort-Hashes, die versehentlich die Schwachstelle aktiviert haben könnten.