Hinweise zur kritischen OpenSSH-Schwachstelle regreSSHion
Zusammenfassung
CVE-2024-6387 ist eine kritische RCE-Schwachstelle (Remote Code Execution) in OpenSSH, die auf die Regression einer CVE im Jahr 2006 zurückzuführen ist.
Die Ausnutzung erfordert die Überwindung einer Race-Bedingung, und es kann Stunden oder sogar Wochen dauern, bis der Exploit gelingt.
Die empfohlene Vorgehensweise ist das Patching auf eine nicht betroffene Version des OpenSSH-Servers auf glibc-basierten Linux-Systemen. Für Umstände, unter denen dies nicht möglich ist, haben wir weitere Abwehroptionen zur Minimierung potenzieller Auswirkungen hinzugefügt.
Wir stellen auch eine OSQuery zur Erkennung anfälliger Versionen von OpenSSH bereit.
Hintergründe und technische Analysen zur OpenSSH-Schwachstelle
Kürzlich entdeckte die Qualys Threat Research Unit eine neue kritische Schwachstelle (CVE-2024-6387), die nicht authentifizierte RCE zur Folge haben könnte. Am 1. Juli 2024 veröffentlichte Qualys seine Ergebnisse zur Regression der Schwachstelle CVE-2006-5051, die 2006 gepatcht wurde und im Jahr 2021 erneut auftrat.
Die Hauptursache der CVE ist eine Race-Bedingung, die durch eine unsichere Verarbeitung von Signalen bei der Zeitüberschreitung von Nutzerauthentifizierungen verursacht wird. Bei einem Timeout wird ein SIGALRM-Signal erzeugt, das eine Unterbrechung eines Threads verursacht, der eine Heap-Verwaltungsroutine ausführt. Wenn der Signal-Handler selbst die Heap-Verwaltungsroutine aufruft, kann dies zu unerwartetem Verhalten führen und in dem Fall die Ausführung von beliebigem Code zur Folge haben.
Derzeit gibt es einen öffentlichen PoC (Proof of Concept), der diese Schwachstelle verwendet und sie zu einer bekannten, ausgenutzten Sicherheitslücke macht. (Dieser PoC wird von einem Drittanbieter angeboten, der nicht mit Akamai verbunden ist. Führen Sie daher Ihre eigene Due-Diligence-Prüfung durch, bevor Sie mit dem Code interagieren). Trotz seiner Schwere lässt der PoC einige Einschränkungen für eine erfolgreiche Ausnutzung erkennen. Eine der Haupteinschränkungen ist die Zeit, die für einen Exploit benötigt wird. Bei einigen Systemen kann es mehrere Stunden dauern, bei anderen bis zu einer Woche. Weitere Einschränkungen sind die Abhängigkeit von der Verteilung des Betriebssystems oder die Version und Konfiguration des OpenSSH-Servers.
Wer ist gefährdet?
Die Schwachstelle betrifft viele Versionen von OpenSSH, einschließlich der meisten Linux-Distributionen, da sie standardmäßig mit OpenSSH geliefert werden.
Da die Ursache für die Schwachstelle eine Regression im OpenSSH-Code ist, sind sehr alte Versionen des OpenSSH-Servers von der ursprünglichen CVE betroffen. Neuere Versionen (vor der Regression) sind nicht betroffen.
Zum Zeitpunkt der Veröffentlichung dieses Artikels sind die folgenden OpenSSH-Versionen von dieser Schwachstelle betroffen:
Die alte Version der Schwachstelle (CVE-2006-5051) wirkt sich auf OpenSSH-Versionen vor OpenSSH 4.4/4.4p1 (27.09.2006) aus [es sei denn, sie sind für CVE-2006-5051 und CVE-2008-4109 gepatcht]
Die Regression der Schwachstelle wurde in Version OpenSSH 8.5/8.5p1 (03.03.2021) eingeführt
Die Hauptentwickler von OpenSSH haben die Sicherheitslücke in der Version OpenSSH 9.8/9.8p (01.07.2024) behoben
Eine Möglichkeit, nach betroffenen Servern zu suchen, ist die folgende Insight-Abfrage:
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
Unseren Beobachtungen zufolge waren in 75 % der Netzwerke Computer mit einer anfälligen Version von OpenSSH vorhanden, und im Durchschnitt waren etwa 35 % der Rechner eines Netzwerks gefährdet. Positiv ist, dass wir in unseren überwachten Umgebungen bisher noch keine Geräte mit einem SSH-Port gefunden, der beliebig über das Internet zugänglich ist. Eine schnelle Suche auf Shodan zeigt jedoch mehr als 6 Millionen zugängliche Rechner mit einer anfälligen Version (Abbildung).
Shodan-Bericht vom 2. Juli 2024 zu anfälligen, über das Internet zugänglichen Rechnern
Potenzielle Auswirkungen
Da OpenSSH standardmäßig von der Sicherheitslücke betroffen ist, sind die potenziellen Auswirkungen enorm. Sie betreffen die meisten Linux-Distributionen und hier aufgrund der Regression insbesondere neuere Versionen.
Es gibt jedoch drei einschränkende Gründe, warum man nicht unbedingt gleich in Panik verfallen muss:
Der aktuelle PoC gilt nur für x86-Computer, da die Ausnutzung auf amd64-Rechnern (die heute Standard sind) aufgrund des stärkeren Speicherschutzes exponentiell komplexer ist.
Derzeit ist davon auszugehen, dass eine erfolgreiche Ausnutzung viel Zeit erfordert und dass mehrere Verbindungen ausgelöst werden müssen. Insofern dürfte ein entsprechender Exploit-Versuch die meisten Brute-Force-Angriffsdetektoren auslösen.
Aufgrund der beiden oben genannten Einschränkungen scheint ein solcher Angriff sich eher als ein erster Zugriffsvektor aus dem Internet zu eignen. Ein Teil der Auswirkungen kann durch eine ordnungsgemäße Segmentierung für Internet-SSH-Verbindungen und für Traffic von Computern, die internetfähige SSH-Schnittstellen benötigen (zum Beispiel Jump Boxes), abgeschwächt werden.
Abwehr
Patching
Die naheliegendste Vorgehensweise ist das Patchen von OpenSSH auf die aktualisierte, nicht anfällige Version. Da OpenSSH jedoch in der Regel mit Linux-Distributionen geliefert wird, hängt das Patching davon ab, dass der Anbieter einen Patch veröffentlicht. Das kann zusätzliche Zeit und Tests erfordern.
Netzwerkadministratoren können die in diesem Blogbeitrag bereitgestellte OSQuery verwenden, um ihre anfälligen Assets zu ermitteln und diese im Zeitverlauf zu verfolgen. Akamai Guardicore Segmentation-Kunden können zu diesem Zweck auch geplante Abfragen verwenden und ihr Asset dann auf der Grundlage der Abfrageergebnisse kennzeichnen.
Segmentierung
Wie oben bereits angemerkt, ist diese CVE-Ausnutzung wahrscheinlich am besten für das erste Eindringen in Netzwerke geeignet, da ein erfolgreicher Exploit Stunden oder sogar Tage dauern kann. Daher ist es von entscheidender Bedeutung, alle Instanzen von internetfähigen OpenSSH-Schnittstellen zu erfassen und den Zugriff darauf zu beenden oder einzuschränken.
In Fällen, in denen beliebiger SSH-Zugriff aus dem Internet erforderlich ist, empfehlen wir, die Netzwerksegmentierung auf diese Computer anzuwenden, um deren Zugriff auf das interne Netzwerk zu beschränken und den Wirkungsradius im Falle eines erfolgreichen Exploits und einer Sicherheitsverletzung zu begrenzen.
Sensibilität für Bedrohungswarnungen
Da Patches unter Umständen noch nicht verfügbar sind,kann es sinnvoll sein, die Alarmsensibilität für die potenziell anfälligen und ungepatchten Workloads zu erhöhen. Auf diese Weise haben Sie immer noch ein gewisses Bewusstsein für die Auswirkungen, selbst wenn die Schwachstelle unbemerkt ausgenutzt wird. Wir empfehlen, insbesondere auf Brute-Force-Angriffe zu achten, da sie die wahrscheinlichste Exploit-Variante darstellen.
Eine Erhöhung der Alarmsensibilität kann jedoch auch eine gewisse Abstumpfung gegenüber Warnungen fördern. Daher empfehlen wir außerdem, die Alarmsensibilität entsprechend der Bedeutung der betroffenen Workload für das Netzwerk oder je nach den zu erwartenden Auswirkungen anzupassen.
Zusammenfassung
In diesem Blogbeitrag haben wir uns mit den verfügbaren Informationen zur regreSSHionskritischen Schwachstelle in OpenSSH beschäftigt, die kürzlich gepatcht und veröffentlicht wurde.
Für Verteidiger besteht der entscheidende Schritt darin, die Schwachstelle der Workloads in ihrem Netzwerk zu finden. Unterstützend haben wir eine OSQuery zur Erkennung anfälliger Versionen von OpenSSH bereitgestellt. Wir haben auch besprochen, wie Sie einige Risiken verringern können (d. h. die Warnsensibilität für Bedrohungen anpassen), wenn kein Patching verfügbar ist.
Dieser Blogbeitrag gibt einen Überblick über unser aktuelles Verständnis der verfügbaren Informationen und über unsere Empfehlungen. Unsere Überprüfung läuft und alle hierin enthaltenen Informationen können sich jederzeit ändern. Besuchen Sie auch unser X -Konto für Updates in Echtzeit.