regreSSHion: Neue OpenSSH-Schwachstelle bedroht Systeme – jetzt updaten!

23.07.2024 / Felix Gilleßen

Die Verwaltung und Fernwartung von IT-Systemen per Secure Shell (SSH) zählt zu den Best Practices in der IT-Welt, da das Netzwerkprotokoll eine verschlüsselte Kommunikation zwischen Client und Server aufbaut. Werden Empfehlungen zu Schlüssellänge und ggf. auch eine zertifikatsbasierte Authentifizierung eingehalten, ist ein sicherer Zugriff über potenziell unsichere Netzwerke möglich. Die meisten unserer Kunden nutzen ebenfalls SSH für Zugriffe auf Server, Netzwerkkomponenten oder zur Verwaltung von anderen an das Netz angebundenen Komponenten.

Umso größer ist die Verunsicherung durch die im Mai entdeckte und am 01.07.2024 veröffentlichte Sicherheitslücke im OpenSSH-Server (sshd), einer sehr weit verbreiteten SSH-Implementierung. Die Lücke erlaubt nicht authentifizierten Angreifern die Ausführung von beliebigem Code (Remote Code Execution, RCA) mit höchsten (root) Privilegien. Voraussetzung ist hier die Verwendung der GNU-C-Bibliothek glibc auf dem betroffenen System.

Die unter CVE-2024-6387 gelistete Schwachstelle wurde von der Qualis Threat Research Unit (TRU) entdeckt und durch einen aufwändigen Proof of Concept demonstriert. Links zur CVE und zum englischsprachigen Blog-Beitrag befinden sich im Anhang.[1] Der Name der Sicherheitslücke (RegreSSHion, dt. Rückschritt) weist darauf hin, dass diese eigentlich schon lange behoben wurde, jedoch durch Updates und Veränderungen am Code wieder aufgetreten ist. Ursprünglich wurde die Lücke CVE-2006-5051 bereits im Jahr 2006 behoben.

Gemäß dem Blog-Beitrag von Qualis sind folgende OpenSSH-Versionen betroffen:

Versionen vor Version 4.4p1, außer sie sind gegen CVE-2006-5051 und CVE-2008-4109 gepatcht
Versionen ab Version 4.4p1, außer Version 8.5p1
Versionen ab 8.5p1, außer Version 9.8p1

OpenBSD-Systeme sind nicht betroffen, da 2001 bereits ein Sicherheitsmechanismus implementiert wurde (glibc wird nicht genutzt).

Wie funktioniert der Exploit?

Bei jeder SSH-Anmeldung gibt es eine Dauer zur Eingabe der Login-Daten. Standardmäßig ist diese „LoginGraceTime“ auf 120 Sekunden konfiguriert. Durch Herbeiführen der Race Condition, die in einem Laborversuch bei etwa jedem zehntausendsten Ablaufen der LoginGraceTime erfolgreich war, konnte ein Angreifer an ein Root-Shell gelangen. Wenn die OpenSSH-Installtion etwa 100 gleichzeitige Verbindungen zuließ, dauerte es ca. 6-8 Stunden, bis ein erfolgreicher Angriff durchgeführt werden konnte. Aktuell gibt es den Exploit nur für 32-Bit-Systeme (i386). Die Erstellung einer 64-Bit-Version (amd64) des Exploits ist allerdings wahrscheinlich, wenngleich durch bessere Address Space Layout Randomization (ASLR) die Durchführung komplexer werden könnte.

Es wurden bereits Aktualisierungen durch die OpenSSH-Maintainer bereitgestellt [2], welche nun nach und nach in die Paket-Verwaltungen der gängigen Distributionen eingearbeitet werden. Doch Achtung: Während für aktuelle Linux-Server Updates zeitnah bereitstehen, verwenden viele Netzwerkgeräte wie Switches, Router, Firewalls sowie Embedded- und IoT-Geräte OpenSSH, auch wenn dies nicht immer direkt aus Dokumentation oder Konfiguration hervorgeht. Als Workaround wäre es möglich, die „LoginGraceTime“ mit 0 zu einem unbegrenzten Login-Timer zu konfigurieren. Obwohl dies wirksam gegen regreSSHion ist, könnte es jedoch weitere potenzielle DoS-Angriffe ermöglichen, indem alle verfügbaren parallelen SSH-Sessions dauerhaft belegt werden.

Wie groß ist der Impact?

Das ShadowServer-Projekt, ein freiwilliger Zusammenschluss von Sicherheitsspezialisten, hat hierzu Statistiken veröffentlicht [3]. Diese beinhalten nur über das Internet erreichbare Server. Am 02.07.2024 waren ca. 4,5 Millionen von 23,5 Millionen gescannten Servern potenziell von der Lücke betroffen und angreifbar. Das entspricht ca. 19 % der erfassten Hosts. Allein in Deutschland waren es am 04.07.24 fast 700.000, mit sinkender Tendenz, und am 03.07.24 noch ca. 475.000. Eine aktuelle Übersicht wird täglich in einer Grafik zusammengefasst [4].

Wie sollte man jetzt vorgehen?

Updates kurzfristig in das Patch-Management der Geräte einbeziehen.
- Eine Bestandsaufnahme der möglicherweise und konkret betroffenen Geräte ist durchzuführen. Hierzu existieren bereits einige Skript-Vorlagen bzw. Playbook-Vorlagen für automatisiertes Scanning.
- Sicherheitsupdates sollten sehr kurzfristig eingeplant und durchgeführt werden.
Angriffsvektor so klein wie möglich halten.
- Gibt es Geräte, die trotz Sicherheitsbedenken per SSH direkt aus dem Internet erreichbar sind? Falls ja, sollte hier SSH schnellstmöglich deaktiviert oder aktualisiert werden. Zudem ist das Sicherheitskonzept zukünftig dringend zu überarbeiten.
- Geräte im internen Netz sollten durch Firewalls abgesichert werden und nur Zugriffe durch bekannte Geräte bzw. Netzwerk-Segmente (z.B. Administrations-Stationen) zulassen.
- Wo dies nicht möglich ist, sollte zumindest durch andere Mechanismen, z.B. Access Lists, Firewalls oder DoS-Schutzmechanismen, wie Fail2Ban, direkt auf den Geräten der SSH-Zugriff eingeschränkt und abgesichert werden.
- Die Deaktivierung von OpenSSH-Servern wäre eine weitere Option, falls SSH nicht aktiv zur Verwaltung genutzt wird. Dies ist allerdings immer im Einzelfall zu entscheiden.
Wachsam bleiben und auf Auffälligkeiten achten.
- Angriffe aus dem internen Netz sind deutlich unwahrscheinlicher, jedoch nicht ganz auszuschließen.
- Soweit möglich und verfügbar, ist die Schwachstelle in das Monitoring der IDS/IPS-Systeme von vorgeschalteten Firewalls einzubeziehen.

Fazit

Die bekannt gewordene Sicherheitslücke im sicher geglaubten und weit verbreiteten OpenSSH-Protokoll zeigt, dass es keine hundertprozentige Sicherheit gibt. Worauf es ankommt, ist der professionelle Umgang mit Sicherheitslücken. Wie gut ist Ihr Unternehmen hierauf vorbereitet? In diesem Fall muss man auch den professionellen Umgang der Sicherheitsforscher unter Einbeziehung der Entwickler hervorheben. Sollten ähnliche Schwachstellen durch bösartige Akteure gefunden und unmittelbar ausgenutzt werden, müsste noch schneller gehandelt werden.