[English]In OpenSSH-Server wurde eine kritische Schwachstelle CVE-2024-6387 offen gelegt. Die als regreSSHion bezeichnete Sicherheitslücke ermöglicht eine Remote Unauthenticated Code Execution – und Sicherheitsfirmen haben über 14 Millionen potentiell angreifbare OpenSSH-Server im Internet gefunden. Allerdings sollte sich das Risiko trotzdem in Grenzen halten.
Anzeige
Was ist OpenSSH
OpenSSH (Open Secure Shell) ist eine Reihe von sicheren Netzwerkdienstprogrammen, die auf dem Secure Shell (SSH)-Protokoll basieren, das für die sichere Kommunikation über ungesicherte Netzwerke unerlässlich ist. Die Open Secure Shell bietet eine robuste Verschlüsselung, um den Datenschutz und sichere Dateiübertragungen zu gewährleisten. Daher ist OpenSSH als Werkzeug für die Remote-Verwaltung breit im Einsatz.
Schwachstelle CVE-2024-6387
Die Qualys Threat Research Unit (TRU) hat eine Sicherheitslücke in OpenSSHs Server (sshd) entdeckt, der der CVE-Code CVE-2024-6387 zugewiesen wurde. Qualsys hat das Ganze mit dem Namen regresSSHion belegt und das Ganze zum 1. Juli 2024 im Blog-Beitrag regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server offen gelegt.
Die Schwachstelle findet sich in glibc-basierten Linux-Systemen und ermöglicht eine Remote-Code-Ausführung, was sich erst einmal gefährlich anhört – daher wird die Schwachstelle auch als "kritisch" eingestuft. Qualys schreibt, dass auf Basis von Recherchen über Censys und Shodan 14 Millionen potenziell verwundbare OpenSSH-Serverinstanzen identifiziert wurden, die per Internet erreichbar sind. Anonymisierte Daten aus Qualys CSAM 3.0 mit External Attack Surface Management-Daten zeigen, dass etwa 700.000 per Internet erreichbare Instanzen angreifbar sind. Dies entspricht 31 % aller per Internet erreichbaren OpenSSH-Server-Instanzen. Interessanterweise haben mehr als 0,14 % der angreifbaren Internet-Instanzen mit OpenSSH-Dienst eine End-Of-Life/End-Of-Support-Version von OpenSSH laufen, schreibt Qualy.
Anzeige
Alte Schwachstelle aus 2006
Den Erläuterungen von Qualys nach handelt es sich bei obiger Schwachstelle um eine Regression der im Jahr 2006 gemeldeten und längst gepatchten Sicherheitslücke CVE-2006-5051. Eine Regression bedeutet in diesem Zusammenhang, dass die bereits behobene Schwachstelle in einer späteren Softwareversion wieder auftaucht. Das kann aufgrund von Änderungen oder Aktualisierungen passieren, so dass eine Schwachstelle erneut vorhanden ist. Diese Regression wurde im Oktober 2020 (mit OpenSSH 8.5p1) eingeführt. Betroffen (oder nicht betroffen) sind folgende OpenSSH Server-Versionen unter Linux:
- OpenSSH-Versionen vor 4.4p1 sind für diese Signalhandler-Race-Condition anfällig, wenn sie nicht für CVE-2006-5051 und CVE-2008-4109 gepatcht sind.
- OpenSSH-Versionen von 4.4p1 bis, aber nicht einschließlich, 8.5p1 sind aufgrund eines transformativen Patches für CVE-2006-5051 nicht verwundbar.
- Die Schwachstelle taucht in den OpenSSH-Versionen von 8.5p1 bis einschließlich 9.7p1 wieder auf, da versehentlich eine kritische Komponente in einer Funktion entfernt wurde.
OpenBSD-Systeme sind von diesem Fehler nicht betroffen, da OpenBSD im Jahr 2001 einen Sicherheitsmechanismus entwickelt hat, der diese Schwachstelle verhindert.
Qualys hat einen funktionierenden Exploit für die regreSSHion-Schwachstelle entwickelt, mit dem die Sicherheitsforscher Root-Rechte erlangen konnten. Im Rahmen der Offenlegung wurde das OpenSSH-Team informiert und diesem der Exploit erfolgreich demonstriert. Der Exploit wird nicht veröffentlicht, um Zeit zum Patchen zu geben.
Ist das Internet am Brennen?
Die Qualys-Sicherheitsforscher schreiben selbst: Diese Schwachstelle lässt sich nur schwer ausnutzen, da es sich um eine Remote Race Condition handelt. Die Sicherheitsforscher haben mehrere Versuche für einen erfolgreichen Angriff benötigt. Die Ausnutzung kann zu einer Beschädigung des Speichers führen und erfordert die Überwindung der Address Space Layout Randomization (ASLR).
Und nun wird es interessant: Ich bin bei Jacob Williams auf diesen LinkedIn-Beitrag zum Thema gestoßen. Williams sortiert das Ganze etwas genauer und schreibt, dass die Qualys-Sicherheitsforscher ca. eine Woche benötigten, um eine Root-Shell zu erhalten. Weiterhin ist der Exploit nur für x86-Architekturen als funktionsfähig nachgewiesen. Viele OpenSSH-Server dürften aber mit der x64-Version laufen, wo die Schwachstelle nochmals schwieriger auszunutzen sein dürfte.
Die Qualys-Experten schreiben zwar: "Fortschritte im Bereich des Deep Learning können die Ausnutzungsrate deutlich erhöhen, was Angreifern einen erheblichen Vorteil bei der Ausnutzung solcher Sicherheitslücken verschaffen könnte." Aber aktuell heißt es: Abwarten, bis die Linux-Distributionen diesen Code wieder gepatcht haben. Jacob Williams schreibt in seinem LinkedIn-Beitrag zudem, dass die meisten Organisationen kein SSH benötigen, das per Internet erreichbar ist. Er schreibt weiterhin, dass die Änderung des Standard-Port für SSH bei Tests die Zahl der die Anzahl der fehlgeschlagenen Anmeldeversuche um mehr als 95 % gesenkt habe. Zudem könnte man den Zugriff sperren, wenn plötzlich von einer IP-Adresse 10.000 Anmeldeversuche registriert werden.
OpenSSH 9.8 verfügbar
Zum 1. Juli 2024 wurden zudem OpenSSH 9.8 veröffentlicht, und es heißt "This release contains fixes for two security problems including a critical one." Mit einem Sicherheitsproblem ist die oben beschriebene Race Condition gemeint. Details sind in den Release Notes nachzulesen.
Anzeige
@Günter Born:
Zitat OP:
"Die Schwachstelle taucht in den OpenSSH-Versionen von 8.5p1 bis einschließlich 9.8p1"
Gemeint dürfte aber 9.7p1 sein, da ja 9.8, wie weiter unten im Text angegeben, den Bug repariert – siehe auch die schon verlinkte Release-Ankündigung:
"A critical vulnerability in sshd(8) was present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges."
Du dürftest Recht haben – der Ausriss war aus dem Qualys-Artikel, wo noch nichts zur 9.8 zu sehen war. Beim Veröffentlichen des Artikels habe ich den Hinweis auf die OpenSSH-Version 9.8 gesehen, den Text aber nicht mehr angepasst.
Es sind offensichtlich nur Systeme betroffen, die auf glibc basieren, das kann man leicht selbst überprüfen:
dpkg -l glibc*
Das ist so leider nicht right.
dpkg -l glibc* sagt, mir dass ich es nicht hätte.
Jedoch /lib/x86_64-linux-gnu/libc.so.6 (also Befehl) zeigt, dass glibc auf dem system verwendet wird.
dpkg läuft doch nur auf Debian basiertenen Systemen. Debian basierte Systeme nutzen durchgehend die glibc(?)
hier würde ich eher schauen, gegen was die bash o.v. gelinkt ist, wenn ich schon nicht weiß auf was mein OS basiert?
ldd $(whereis -b bash)
Eine Sicherheitslücke in so einem sensiblen Stück Software, wo jeder den Quellcode lesen kann, wo geschlossene Lücken bestens in menschlicher Sprache im Quellcode kommentiert sind, die schonmal geschlossen war, ist wieder offen. Das muss doch mal die ganzen OSS-Verfechter zum Nachdenken bringen, oder? Das ist doch geradezu zum Fremdschämen?!
Achja, Herr Born, ich könnte die Moderation meiner Beiträge durch Verwendung eines anderen Namens und Mailadresse durchaus umgehen, ich sehe ja, dass mancher kritischer Beitrag von mir nicht freigeschaltet wird.
Nur zur Moderation: Ich habe mir inzwischen angewöhnt, Troll-Futter rigoros zu löschen – und eine Menge Kommentare von 1ST1 fallen leider in diese Kategorie. Ich könnte natürlich auch den Filter so einstellen, dass der Benutzer für die Kommentierung gesperrt und alle Kommentare sofort gelöscht werden.
Ist im Moment ein großes Entgegenkommen von mir, weil ich die Kommentare von 1ST1 seit Jahren verfolge und viele Beiträge imho auch sinnvoll sind. Aber Hand auf's Herz: Ich habe in der Moderation immer weniger Lust auf bestimmte Kommentare, die dann zum Verkämpfen auf Nebenkriegsschauplätzen führen. Dazu ist mir die Zeit schlicht zu schade! Einfach drüber nachdenken.
gefunden, gefixt
nebenbei schwer ausnutzbar.
Genau das Gegenteil von dem, was man so aus der Windowswekt kennt.
Also wo genau ist dein Problem, dass du hier so angehst? Hat man füral wieder die Rassel geklaut oder was?
Bei Windows und Windows Server wird auch ein win32 Port von Microsoft für openssh eingesetzt. Der openssh Server ist aber nicht vorinstalliert. Ab Windows Server 2025 wird openssh Server bei der Installation mit installiert, muss aber noch aktiviert werden.
Neben dem Windows Feature openssh Server gibt es noch ein Github Projekt mit einer vermeintlich neueren Version. Ob die Versionen auch betroffen sind ist mir bisher nicht bekannt. Der letzte Build ist noch aus 2023. Auf github.com gibt es dazu einen bisher unbeantworteten issue. Nächste Woche ist ja Pathday.
iisue auf github
https://github.com/PowerShell/Win32-OpenSSH/issues/2249
noch mehr Links zu dem Thema openssh auf Windows:
Get started with OpenSSH for Windows
https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse?tabs=gui
PowerShell and OpenSSH team investments for 2024
https://devblogs.microsoft.com/powershell/powershell-and-openssh-team-investments-for-2024/
Announcing Windows Server Preview Build 26063
https://techcommunity.microsoft.com/t5/windows-server-insiders/announcing-windows-server-preview-build-26063/m-p/4064942
Zum Fremdschämen sind eher deine Kommentare hier.
Die Frage wurde schon mehrfach gestellt, aber bisher nicht beantwortet: wie alt bist du, 1ST1?
Du hast aber schon gelesen, das man OpenBSD so gehärtet hat, dass dieser Fehler keine Auswirkung mehr haben kann.
Denn bekannt ist:
Alle machen Fehler.
Warum haben Autos 2 ja früher sogar 3 unabhängige Bremssysteme?
Wenn man nichts tut, nichts offen dokumentiert?
… so sind viele Menschen im Krankenhaus verstorben, weil ein traniger Pfleger den Unterschied zwischen einer Na und einer Ka Trägerlösung ohne Brille nicht erkannte.
Inzwischen hat man unterschiedliche Anschlüsse…
Aber erst, nach dem Einrichten eines anonymen Meldesystems und einem Gerichtsverfahren um Pfleger, die Patienten mit Ka Lösung ganz unauffällig halb oder ganz umgebracht haben um sie retten zu können. .
Also den Ssh port zu ändern geht, ja.
Hilft gegen zufällige Angriffe und entlastet das Logfile von directory Angriffen.
ich ziehe allerdings so etwas wie http-knocking vor, wenn ich denn mal ohne VPN eine (ja ggf. extrerm mächtige) ssh Verbindung brauche.
(http knocking bedeutet, das der Client ein Seiten meiner Webseite in einer bestimmten Reihenfolge anrufen muss.
Ganz normales https.
Schaft der Abfrager dies so wird für genau die IP-adresse von der er angeklopft hat, der spezifizierte Port auf dem vereinbarten Server für einen Connect frei gegeben.
Der Server sieht für alle anderen aus, als wäre da nichts zu holen.
Und der Webserver erzeugt nur einen Token um der Firewall zu sagen, für wen sie den Port freigegeben soll.
Ist ganz trivial, natürlich nicht unknackbar, aber besser als einen Port offen im Netz zu zeigen.
Wer so richtig paranoid ist, hängt einen Honigkorb daneben, damit shanon und ok die verwendete Software kostenlos scannen.
Das ist kein KISS, aber was willste machen?