Technischer Support
Dokumentation
Anmeldung
Kontakt
TuxCare BlogEin Blick in die Vergangenheit: RegreSSHion
von Joao Correia
Juli 12, 2024 - Technischer Evangelist
Es ist Sommer, und das Jahr war bisher reich an hochkarätigen Hacks, die sich auf sehr bekannte Unternehmen wie Ticketmaster oder Change Healthcare auswirkten, sowie an ausgeklügelten bösartigen Operationen wie der, die auf das xz-Projekt abzielte. Mit der RegreSSHion-Schwachstelle (diese Namen...), die OpenSSH betrifft, können wir nun einen weiteren sehr bedeutenden Vorfall zu dieser Liste hinzufügen.
SSH ist das de facto SSH ist das bevorzugte Fernzugriffstool, das von Servern bis hin zu Ihrem Fernseher überall zu finden ist, und jedes Mal, wenn Schwachstellen entdeckt werden, die es beeinträchtigen, gerät die Welt der Cybersicherheit in Aufruhr.
Die Verwundbarkeit
RegreSSHion, oder CVE-2024-6387 wenn Sie es nicht beim Vornamen nennen, ist eine Sicherheitslücke, die am 1. Juli 2024 bekannt wurde. Sicherheitsforscher fanden heraus, dass der Anmeldeprozess bei der Verbindung mit dem OpenSSH-Server (üblicherweise sshd) ein ausnutzbares Verhalten aufweist. Aus der Ferne ausnutzbar, das heißt.
Wenn eine Verbindung initiiert wird und der Client den Anmeldevorgang nicht abschließen kann, gibt es eine eingebaute Timeout-Periode (gesteuert durch die LoginGraceTimeout-Einstellung, die in den meisten Installationen auf 120s voreingestellt ist), nach der die Verbindung beendet wird. Wenn sshd die Verbindung beendet, löst es asynchron ein Signal namens SIGALRM aus - was bedeutet, dass sshd sich nicht aufhängt, während es die Verbindung verarbeitet - und mehrere Event-Handler nehmen es auf. Diese Event-Handler kann man sich als spezifische Funktionen vorstellen, die die Ressourcen aufräumen, die durch die nun nicht mehr bestehende Verbindung gebunden sind, oder die in die Protokolle schreiben, dass ein Verbindungsversuch durchgeführt wurde, aber nicht abgeschlossen werden konnte. Die eigentliche Schwachstelle ergibt sich aus der Tatsache, dass diese Event-Handler selbst nicht so kodiert sind, dass sie asynchron sind, und in sehr spezifischen (und schwer auszulösenden) Szenarien ein unerwartetes Verhalten zeigen können.
Die Ausbeutung
Um die Schwachstelle auszunutzen, muss eine Reihe von Bedingungen auf dem Server gegeben sein. Leider sind diese für viele Systemadministratoren und Unternehmen ziemlich häufig.
Erstens muss OpenSSH in einer verwundbaren Version laufen - aber mehr zu den betroffenen Versionen weiter vorne. Zweitens muss auf dem System die glibc laufen, da die unsicheren asynchronen Funktionen von dort kommen. Drittens darf es keine Form der Abschwächung geben; in dieser Hinsicht fühlen sich die *BSD-Leute im Moment ziemlich gut mit ihrer Distributionswahl, da sie seit ein paar Jahrzehnten async-sichere Versionen der Funktionen enthalten.
Um die Schwachstelle auszulösen, muss ein Angreifer versuchen, sich anzumelden, eine Zeitüberschreitung in Kauf nehmen und diesen Vorgang wiederholen (möglicherweise mehrere Versuche). Die richtigen Funktionen müssen zum richtigen Zeitpunkt ausgeführt werden, und in einer asynchronen Umgebung, die von anderen Prozessen im System beeinflusst wird, geschieht dies nicht oft. Das Auslösen der Schwachstelle ist also eher ein probabilistischer als ein deterministischer Prozess. Die Sicherheitsforscher, die diese Entdeckung machten, schätzten, dass dies bei 32-Bit-Systemen im Durchschnitt zwischen 8 Stunden und einem Tag dauern könnte. Bei 64-Bit-Systemen könnte dies angesichts des viel größeren Adressraums möglicherweise Wochen dauern.
Wenn jedoch die richtigen Funktionen zum richtigen Zeitpunkt ausgeführt werden, kann ein Angreifer das System dazu bringen, vom Angreifer kontrollierten Code auszuführen, z. B. eine Shell zu öffnen - mit Root-Rechten.
Die sehr lange Zeitspanne, die der Exploit in Anspruch nehmen kann, macht eine weit verbreitete Ausnutzung dieser Schwachstelle unwahrscheinlich, aber gezielte Angriffe sind definitiv eine Option für böswillige Akteure. Es ist wichtig, darauf hinzuweisen, dass dieselben Sicherheitsforscher, die diesen Exploit demonstriert haben, sich die Mühe gemacht haben, zu erwähnen, dass sie lediglich zeigen wollten, dass die Schwachstelle ausgenutzt werden kann, und dass ihr Code in keiner Weise optimiert wurde - es ist gut möglich, dass ausreichend motivierte Bedrohungsakteure genau das tun und die Exploit-Zeit verkürzen können.
Meine SSHD ist nicht dem Internet ausgesetzt
Und das ist eine gute Wahl! Leider wurden bei einer schnellen Internet-Überprüfung mehr als 14 Millionen ungeschützte SSH-Dienste gefunden. Zwar haben nicht alle die richtigen Voraussetzungen für einen erfolgreichen Angriff, aber selbst ein kleiner Teil ist immer noch eine beträchtliche Anzahl von Systemen, die für böswillige Geschäfte offen sein könnten.
Es ist eine gute Option, Ihre kritischen Dienste vom Internet fernzuhalten, indem Sie sie nur an interne, nicht weitergeleitete Adressen binden oder sie auf der Firewall-Ebene blockieren. Eigentlich sollte eine Schwachstelle wie diese nicht nötig sein, um diese Option zu rechtfertigen, aber je mehr Dienste dadurch von potenziellen Angriffen wie RegreSSHion oder dem einfachen Ausspähen von Passwörtern abgehalten werden können, desto besser.
Ich habe einen grauen Bart und ich erinnere mich an etwas Ähnliches...
Und Sie haben auch ein gutes Gedächtnis. Es stellt sich heraus, dass RegreSSHion sich auf Versionen von OpenSSH zwischen 8.5p1 und 9.8p1 (nicht mehr angreifbar) auswirkt, da der für den Fehler verantwortliche Code im Jahr 2020 veröffentlicht wurde.
ABER... er betrifft auch OpenSSH-Versionen vor 4.4p1, aus dem Jahr 2006 (CVE-2006-5051). Es stellte sich heraus, dass 2006 derselbe Fehler gefunden und behoben worden war. Und dann 2008 erneut behoben wurde, weil der erste Fix offenbar nicht korrekt war (CVE-2008-4109).
Wie kam es also dazu, dass es wieder in die Codebasis aufgenommen wurde? Nun, Gedächtnis und Zeit sind keine guten Partner. Als der Code im Jahr 2020 eingereicht wurde, bemerkte niemand, dass derselbe Code-Commit OpenSSH wieder anfällig für ein bereits behobenes Problem machen würde. Eine "ifdef" wurde aus dem Code entfernt, die den Code vor dem früheren Fehler schützte, und so konnte er erneut ausgenutzt werden.
Den Kugeln ausweichen
Aus der Ferne ausnutzbare Schwachstellen, die zu einem privilegierten Zugriff führen, gehören zu den gefährlichsten, die es gibt. Wenn sie Software betreffen, die so weit verbreitet ist wie OpenSSH, ist das ein Alptraumszenario. Der Silberstreif an RegreSSHion ist, dass es sehr langsam auslöst. Das hat ihn deutlich weniger gefährlich gemacht, als er sonst hätte sein können.
Genau wie bei xz, wo die Hintertür genau im richtigen Moment abgefangen wurde, bevor sie sich ausbreiten konnte, sind wir mit RegreSSHion aufgrund der langsamen Ausnutzungszeit möglicherweise einer weiteren Kugel ausgewichen.
Ein weiterer wichtiger Punkt ist, dass die mit CentOS 7 ausgelieferte Version nach Angaben von Redhat nicht anfällig war. Da diese Schwachstelle kurz nach dem End-of-Life-Datum von CentOS 7 bekannt gegeben wurde, hätte es, wäre es anfällig gewesen, keine vom Hersteller bereitgestellten Patches erhalten, was wiederum die Tausenden von CentOS 7-Systemen, die noch im Umlauf sind, sehr anfällig gemacht hätte.
Es ist eine Binsenweisheit, dass man nicht immer Glück haben kann. Irgendwann, wie Neo, der mit den Armen wedelt, um den Kugeln der Matrix auszuweichen, wird eine davon einschlagen. Nehmen Sie sich einen Moment Zeit, um eine Bestandsaufnahme Ihrer Infrastruktur zu machen, und zwar nicht nur für ssh. Beginnen Sie damit, unnötige Dienste vor dem Internet zu sperren und VPN-Verbindungen zu erzwingen. Es sind die grundlegenden Dinge, die am einfachsten zu handhaben sind, wie z. B. rechtzeitiges Patchen und Firewalling, und die für Bedrohungsakteure leichter angreifbar sind.
Und das ist besser heute als morgen.
[Ein besonderer Hinweis an das AlmaLinux-Team. Sie veröffentlichten aktualisierte OpenSSH-Pakete, um diesen Fehler innerhalb weniger Stunden nach der Enthüllung zu beheben, und viel früher als Upstream und andere große Namen in diesem Bereich. Hut ab!]
[Eine zweite Anmerkung: Wie bei diesen hochkarätigen Sicherheitslücken üblich, werden, je mehr Leute sich damit befassen, weitere Schwachstellen entdeckt. Eine verwandte Schwachstelle wurde bereits identifiziert und veröffentlicht als CVE-2024-6409]
