regreSSHion-Lücke: Neues SSH-Feature bietet Schutz, Proof of Concept ist keiner

Inhaltsverzeichnis

Ein Sicherheitsproblem namens "regreSSHion" in OpenSSH kann zur Ausführung beliebigen (Schad-)Codes führen, ist aber schwierig auszunutzen. Dennoch tauchten wenige Tage nach Veröffentlichung erste "Proof-of-Concept"-vorgebliche Exploits im Netz auf, auch ein Schwachstellenscanner ist im Umlauf. Derweil hat das OpenSSH-Entwicklerteam in der aktuellen Version nicht nur den Programmierfehler behoben, sondern auch Sperren gegen zukünftige Angriffe eingebaut.

Fake-Exploits auf GitHub

Einige Tage sind seit der Veröffentlichung einer "Remote Code Execution"-Lücke in OpenSSH vergangen und Exploitcode ist bereits im Umlauf. Eine Suche nach der CVE-ID CVE-2024-6387 auf GitHub fördert gleich mehrere angebliche PoCs (Proof of Concept) zutage, zumeist Kopien eines Programms eines Sicherheitsforschers mit dem Pseudonym "7etsuo". Bei der Nutzung solcher PoC-Exploits ist Vorsicht geboten: Unerwünschte Nebenwirkungen und von Trittbrettfahrern eingeschleuste Hintertüren können Neugierigen einiges Ungemach bescheren.

Der 7etsuo-Exploit ist den Entdeckern der Lücke zufolge nicht echt: "Er sieht toll aus, macht aber nichts. Ein funktionierender Proof of Concept für diese Sicherheitslücke wäre viel umfangreicher und komplexer und wird sehr viel mehr Entwicklungszeit benötigen als dieser", so die Einschätzung der Qualys-Forscher auf der Mailingliste oss-security.

Die Linux-Distributionen Ubuntu und Debian haben mittlerweile reagiert und aktualisierte OpenSSH-Pakete zur Verfügung gestellt – Nutzer von Red Hat 9 müssen sich jedoch weiter gedulden. Sie sollten zu einer der Behelfslösungen greifen (siehe Abschnitt "Notbehelf für Patchmuffel").

Möchten IT-Administratoren ihren Serverzoo schnell auf Angreifbarkeit testen, steht ihnen ein handliches Werkzeug von Alexander "xaitax" Hagenah zur Verfügung: Das in Python geschriebene Skript kann ganze Netzbereiche auf regreSSHion-anfällige SSH-Dienste überprüfen. Es vergleicht dazu die beim Verbindungsaufbau übermittelte Versionskennung à la SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.3 mit einer Liste angreifbarer Versionen.

Jeder sechste SSH-Server weltweit angreifbar

Auch das Shadowserver-Projekt greift die Sicherheitslücke CVE-2024-6387 nun in seiner Statistik auf. Von etwa 24 Millionen weltweit über das Internet ansprechbaren SSH-Servern sind 4 Millionen angreifbar, mithin jeder sechste. Die meisten verwundbaren SSH-Server finden sich in den Vereinigten Staaten, auf Platz 2 ist Deutschland mit knapp 700.000 Servern. Diese Zahl dürfte in den nächsten Wochen deutlich sinken, nachdem Patches eingespielt wurden.

Über 1000 Arbeitsstunden bis zum Exploit

Der für "regreSSHion" zuständige Projektleiter bei Qualys, Saeed Abbasi, erläuterte im Gespräch mit heise security einige Details zur Arbeit seines Teams. Zunächst schränkte er die Schwere des Fehlers etwas ein – anders als zunächst durch die Redaktion angenommen, ist der CVSS-Punktwert lediglich 8.1 und der Fehler hat somit keine kritische, sondern nur eine hohe Priorität. Dennoch seien ungepatchte Server in wenigen Stunden erfolgreich angreifbar, so Saeed: In Versuchen seiner Teams habe man mit Leichtigkeit 98–99 parallele Verbindungen aufbauen können. Der SSH-Server beginnt in der Standardkonfiguration ab 10 parallelen Verbindungsversuchen zufällig damit, weitere Verbindungen abzulehnen, um einen Überlastungsangriff zu vermeiden (MaxStartups 10:30:100).

Von der Entdeckung der Lücke bis zur koordinierten Veröffentlichung des ausführlichen Artikels über regreSSHion seien über eintausend Arbeitsstunden in das Projekt geflossen, so Abbasi weiter. Obgleich ein großer Teil der Arbeit von einem kleinen Kernteam geleistet worden sei, habe die gesamte Mannschaft der Abteilung "Vulnerability Research" ihr Scherflein beigetragen.

OpenSSH 9.8 mit eingebautem Bruteforce-Schutz

Die aktuelle Version 9.8 des OpenSSH-Servers enthält neben dem Bugfix für regreSSHion neue Konfigurationsdirektiven zur Bestrafung ungebührlicher Clients. Häufige Fehlanmeldungen oder gar Server-Crashes dienen dem Server als Hinweis auf Angriffsversuche und sorgen für Log-in-Sperren. Das hilft gegen Exploits wie regreSSHion, aber auch gegen gewöhnliche Passwort-Ratespielchen, wie sie auf jedem ans Internet angeschlossenen Server zu Tausenden vorkommen.

Administratoren können sehr genau kontrollieren, in welchen Situationen der SSH-Server welche Strafen verteilt. heise security hat einen Blick auf die neuen Einstellmöglichkeiten geworfen. Vorab: Ein frisch installierter OpenSSH-Server in Version 9.8(p1) bringt vernünftig anmutende Standardeinstellungen mit, die wir in der untenstehenden Liste jeweils nach einem Doppelpunkt aufführen. Die neuen Blockier-Funktionen sind zudem standardmäßig aktiviert, müssen also nicht separat in der Konfiguration eingetragen werden.

Möchte der Systemverwalter jedoch an den Einstellungen Änderungen vornehmen, stehen ihm verschiedene Optionen zur Verfügung, die durch Leerzeichen getrennt an die Direktive PerSourcePenalties angehängt werden:

• crash:90: Bringt ein Client den OpenSSH-Prozess mit seiner Verbindung zum Absturz, wird er 90 Sekunden auf die Wartebank geschickt,
• authfail:5: Wartezeit nach fehlerhafter Anmeldung (falscher Benutzername/Passwort),
• noauth:1: Wartezeit, falls ein SSH-Client keinen Anmeldeversuch unternommen hat, wie es etwa ssh-keyscan tun,
• grace-exceeded:20: Hält ein Client die SSH-Verbindung offen, ohne einen Authentifizierungsversuch zu unternehmen, wird er 20 Sekunden bestraft – diese Einstellung bietet erhöhten Schutz vor regreSSHion,
• max:600: So lange (in Sekunden) wird eine IP-Adresse maximal gesperrt, bevor Anmeldeversuche wieder möglich sind,
• min:15 – und so viel "Strafzeit" muss sie minimal angesammelt haben, bevor sie erstmalig gesperrt wird,
• max-sources4:65536 und max-sources6:65536: Maximale Anzahl der IP(v4 und v6)-Adressen oder Netzbereiche, die verfolgt werden und
• overflow:permissive bzw. overflow6:permissive: Wird die oben stehende Maximalzahl überschritten, werden entweder alle IPv4- und IPv6-Verbindungen abgelehnt (deny-all) oder Listeneinträge gelöscht und neue Verbindungen zugelassen (permissive).

Nicht nur die auffällige IP-Adresse, sondern auch andere aus demselben Netzblock kann der OpenSSH-Server in die Sperre einbeziehen, um Angriffe aus kompromittierten Netzwerken zu blockieren. Mit der Konfigurationsdirektive "PerSourceNetBlockSize" kontrolliert der Systemverwalter, welche CIDR-Netzmaske für IPv4- und IPv6-Adressen angewendet wird. In der Standardeinstellung 32:128 werden einzelne IP-Adressen betrachtet, eine Einstellung wie 24:48 würde das jeweilige /24- bzw. /48-Subnetz umfassen.

Um die eigenen Management-Netze nicht versehentlich auszusperren, können Admins auch eine Positivliste namens "PerSourcePenaltyExemptList" definieren. Diese enthält eine kommaseparierte Liste von IP-Adressen in CIDR-Notation, also mit der Netzmaske. Um das typische Fritz!Box-Subnetz auf die Positivliste zu setzen, genügt also die Konfigurationszeile PerSourcePenaltyExemptList 192.168.178.0/24.

Notbehelf für Patchmuffel

Derzeit bietet jedoch bis auf Slackware keine der bekannteren Linux-Distributionen OpenSSH 9.8 als Paket an – es dürfte also noch eine Weile dauern, bis jeder Administrator in den Genuss der neuen Konfigurationsoptionen kommt. Bis dahin behilft man sich besser mit anderen Maßnahmen, sofern man nicht direkt ein Update einspielen kann oder will.

So können Admins die "Race Condition", die dem Angriff zugrunde liegt, beseitigen, indem sie SSH-Clients mittels "LoginGraceTime 0" in der SSH-Konfigurationsdatei (meist /etc/ssh/sshd_config) unbegrenzt viel Zeit bis zum erfolgreichen Log-in einräumen. Das Risiko dieser Einstellung ist jedoch, dass Angreifer alle verfügbaren SSH-Verbindungsmöglichkeiten des Servers belegen, die dann mangels Zeitlimit nie mehr freigegeben werden. Legitime Nutzer wären somit ausgesperrt.

Auch mit Werkzeugen wie fail2ban können Systemverwalter dem regreSSHion-Exploit zu Leibe rücken. Da Angriffsversuche ähnlich aussehen wie gewöhnliches Bruteforcing, dürfte ein zur SSH-Überwachung konfiguriertes fail2ban (etwa wie in dieser Anleitung beschrieben) bereits einigen Schutz bieten.

Bei allen Blockier-Maßnahmen sollten Admins jedoch beachten: Durch den Einsatz von Botnets oder "Residential Proxies" können Kriminelle auf Hunderttausende verschiedene IP-Adressen zurückgreifen, um ihre Einbruchsversuche zu starten. Nur ein Update des OpenSSH-Servers bietet hundertprozentigen Schutz gegen regreSSHion.

(cku)