regreSSHion: Sicherheitslücke bei Remote Unauthenticated Code Execution im OpenSSH-Server

Eine strenge Fernbedienung Nicht authentifizierte Codeausführung (RCE) Eine Sicherheitslücke wurde kürzlich im OpenSSH-Server (sshd) auf glibc-basierten Linux-Systemen entdeckt. Dieser schwerwiegende Fehler, der CVE-2024-6387, stellt ein erhebliches Sicherheitsrisiko dar, da es die nicht authentifizierte Remotecodeausführung als Root ermöglicht.

Diese Entdeckung folgt auf eine weitere bedeutende Schwachstelle, die erst vor wenigen Monaten in der XZ Utils-Bibliothek entdeckt wurde und die anhaltenden Herausforderungen der Cybersicherheit verdeutlicht. Obwohl CVE-2024-6387 ein schwerwiegender Fehler ist, ist er in der Praxis recht schwer auszunutzen. Dennoch ist es wichtig, das Risiko zu verstehen und Maßnahmen zum Schutz Ihrer Systeme zu ergreifen. SSH wird auf Linux-Servern auf verschiedenen Plattformen häufig verwendet, weshalb seine Sicherheit von entscheidender Bedeutung ist.

Technische Details

Dieses Problem tritt auf, wenn sich ein Client nicht innerhalb des AnmeldenGraceTime Zeitraum, der auf 120 Sekunden standardmäßig in den letzten Versionen und 600 Sekunden in älteren Versionen. Wenn dieses Timeout erreicht ist, SIGALRM Handler ausgelöst wird. Das Problem tritt auf, weil dieser Handler verschiedene Funktionen aufruft, wie z. B. syslog(), die nicht sicher aus einem Signalhandler aufgerufen werden können. Dieser Race Condition stellt ein erhebliches Risiko für Systeme dar, auf denen der Standard sshd Konfiguration.

Interessanterweise ist diese Sicherheitslücke nicht ganz neu. Es handelt sich um eine Regression eines zuvor identifizierten Problems, CVE-2006-5051, das 2006 von Mark Dowd gemeldet wurde. Diese frühere Sicherheitslücke betraf auch einen Signal-Handler-Race-Condition in OpenSSH-Versionen vor 4.4, der zu einem Denial-of-Service-Angriff oder potenziell zur Remote-Code-Ausführung führen konnte.

Der Rückschritt erfolgte im Oktober 2020 mit der Veröffentlichung von OpenSSH 8.5p1. Bei einem Update der Protokollierungsinfrastruktur wurde eine wichtige Anweisung (#ifdef DO_LOG_SAFE_IN_SIGHAND) wurde versehentlich aus dem sigdie() Funktion. Diese Funktion, die direkt von sshds SIGALRM Handler, wurde wieder unsicher gemacht. Hier ist eine Aufschlüsselung der Zeitleiste der Sicherheitslücke:

• OpenSSH < 4.4p1: Anfällig für den Race Condition, sofern kein Patch für CVE-2006-5051 oder CVE-2008-4109 vorliegt.
• 4.4p1 ≤ OpenSSH < 8.5p1: Sicher aufgrund des Vorhandenseins von #ifdef DO_LOG_SAFE_IN_SIGHAND, wodurch sigdie() _exit(1) sicher aufrief.
• 8.5p1 ≤ OpenSSH < 9.8p1: Aufgrund der Entfernung der Direktive #ifdef DO_LOG_SAFE_IN_SIGHAND erneut anfällig.

Die Auswirkungen dieser Sicherheitslücke sind besonders gravierend auf glibc-basierten Linux-Systemen, wo syslog() selbst kann andere unsichere Funktionen aufrufen wie malloc () und kostenlos(). Dadurch entsteht ein Szenario, in dem ein Angreifer potenziell beliebigen Code als Root ausführen kann, ohne sich authentifizieren zu müssen. Dies liegt daran, dass der privilegierte Code von sshd mit vollen Systemberechtigungen arbeitet und keine Sandboxing-Funktion besitzt.

Sicherheitslücken Details

Diese Sicherheitslücke wird durch einen Signalhandler-Race-Condition im OpenSSH-Server (sshd) verursacht, der sich auf Systeme in ihrer Standardkonfiguration auswirkt. Suchvorgänge mit Censys und Shodan ergaben über 14 Millionen potenziell anfällige OpenSSH-Serverinstanzen, die dem Internet ausgesetzt sind. Anonymisierte Daten von Qualys zeigen, dass etwa 700,000 externe, mit dem Internet verbundene Instanzen anfällig sind, was 31 % aller mit dem Internet verbundenen Instanzen mit OpenSSH im weltweiten Kundenstamm entspricht. Bemerkenswerterweise laufen auf über 0.14 % dieser anfälligen Instanzen End-Of-Life/End-Of-Support-Versionen von OpenSSH.

Exploit-Entwicklung und Offenlegung

Durch das Verständnis des detaillierten Ausnutzungsprozesses können Systemadministratoren und Sicherheitsexperten die Schwere dieser Sicherheitsanfälligkeit und die Bedeutung der Implementierung zeitnaher Patches und robuster Sicherheitsmaßnahmen besser einschätzen.

Um die Race Condition-Schwachstelle im Signalhandler in OpenSSH auszunutzen, sind fundierte Kenntnisse über Timing-Angriffe und Speichermanipulation erforderlich. Im Folgenden beschreiben wir die Schritte, die ein Angreifer unternehmen würde, um diese Schwachstelle auszunutzen.

Mehrere Verbindungen initiieren

Der Angreifer initiiert zahlreiche Verbindungen zum Ziel-OpenSSH-Server und löst dabei wiederholt den AnmeldenGraceTime Limit, ohne die Authentifizierung abzuschließen. Diese Aktion bewirkt, dass der Server das SIGALRM Signal.

Interrupt-Signal-Handler

Die Ausnutzung beruht auf der Unterbrechung des Signalhandlers des Servers genau in dem Moment, in dem er nicht asynchrone signalsichere Operationen ausführt, wie zum Beispiel syslog(). Der Angreifer sendet speziell gestaltete Eingaben, um das Speicherlayout des Servers zu manipulieren, was zu einer Beschädigung des Heaps führt.

Speicherlayout manipulieren

Durch Manipulation des Serverspeichers erzeugt der Angreifer einen inkonsistenten Zustand im Heap. Dies wird erreicht, indem das SIGALRM-Signal während der Speicherzuweisung oder -freigabe ausgelöst wird, wie z. B. malloc () or kostenlos(). Um diese Schwachstelle auszunutzen, sind normalerweise etwa 10,000 Versuche erforderlich. Jeder Versuch setzt den LoginGraceTime-Timer zurück und gibt dem Angreifer ein neues Zeitfenster, um die Schwachstelle auszulösen.

Optimieren Sie das Timing

Während des Angriffs passt der Angreifer das Timing seiner Eingaben anhand des Feedbacks aus früheren Versuchen an. Diese Feinabstimmung ist entscheidend, um den Signalhandler im entscheidenden Moment erfolgreich zu unterbrechen. Trotz moderner Abwehrmaßnahmen wie Address Space Layout Randomization (ASLR) und No-eXecute (NX) verwendet der Angreifer vorhersehbare Speichermuster und fortschrittliche Timing-Techniken, um diese Schutzmaßnahmen zu umgehen.

Beliebigen Code ausführen

Bei erfolgreicher Ausnutzung kann der Angreifer kritische Speicherstrukturen überschreiben, was zur Ausführung beliebigen Codes und zur Fernsteuerung des Servers mit Root-Rechten führt.

Erkenntnisse aus Forschung und Entwicklung

Die Forscher haben sich in erster Linie auf virtuelle Maschinen mit weitgehend stabilen Netzwerkbedingungen konzentriert. Obwohl bereits erhebliche Fortschritte erzielt wurden, werden weitere Verbesserungen erwartet, insbesondere für die Nutzung neuerer amd64-Systeme, bei denen ASLR stärker ist. Die Entdeckung eines entsprechenden Fehlerberichts führte zu einer sofortigen Kommunikation mit den OpenSSH-Entwicklern, was die Bedeutung schnellen Handelns bei der Behebung solcher Schwachstellen unterstreicht.

OpenSSH: Sichere Unternehmenskommunikation gewährleisten

OpenSSH (Open Secure Shell) ist eine grundlegende Suite sicherer Netzwerkdienstprogramme, die auf dem Secure Shell (SSH)-Protokoll basieren. Es gewährleistet eine robuste Verschlüsselung für Datenschutz und sichere Dateiübertragungen und ist daher für die Remote-Serververwaltung und sichere Datenkommunikation unverzichtbar. Trotz der jüngsten Sicherheitslücke bleibt OpenSSH aufgrund seiner umfassenden Sicherheits- und Authentifizierungsfunktionen, seiner Skalierbarkeit und der Möglichkeit, robuste Zugriffskontrollen durchzusetzen, ein Maßstab in Sachen Softwaresicherheit.

Betroffene OpenSSH-Versionen

• Verwundbar: Versionen vor 4.4p1 (sofern nicht für CVE-2006-5051 und CVE-2008-4109 gepatcht) und Versionen von 8.5p1 bis einschließlich 9.8p1.
• Nicht anfällig: Versionen von 4.4p1 bis (ausschließlich) 8.5p1 aufgrund eines transformativen Patches für CVE-2006-5051.

OpenBSD-Systeme sind von diesem Fehler dank eines 2001 entwickelten sicheren Mechanismus nicht betroffen, der diese Sicherheitsanfälligkeit verhindert.

Mögliche Auswirkungen der Regression

Wird diese Schwachstelle ausgenutzt, kann sie das gesamte System kompromittieren und Angreifern ermöglichen, beliebigen Code mit den höchsten Berechtigungen auszuführen. Dies kann zu einer vollständigen Systemübernahme, der Installation von Malware, Datenmanipulation und der Erstellung von Hintertüren für dauerhaften Zugriff führen. Außerdem kann sie die Netzwerkausbreitung erleichtern und Angreifern ermöglichen, andere anfällige Systeme innerhalb der Organisation zu durchdringen und auszunutzen. Die Remote-Race-Condition-Natur dieser Schwachstelle macht ihre Ausnutzung schwierig, aber Fortschritte im Bereich Deep Learning könnten die Erfolgsquote erhöhen.

Sofortige Maßnahmen zur Risikominderung

• Patchverwaltung: Wenden Sie verfügbare Patches für OpenSSH schnell an und priorisieren Sie laufende Aktualisierungsprozesse.
• Erweiterte Zugangskontrolle: Beschränken Sie den SSH-Zugriff durch netzwerkbasierte Kontrollen, um Angriffsrisiken zu minimieren.
• Netzwerksegmentierung und Angriffserkennung: Teilen Sie Netzwerke auf, um unbefugten Zugriff und laterale Bewegungen innerhalb kritischer Umgebungen einzuschränken, und setzen Sie Systeme ein, um ungewöhnliche Aktivitäten zu überwachen, die auf Missbrauchsversuche hinweisen, und davor zu warnen.
• Implementieren einer vorübergehenden Problemumgehung: Wenn ein Upgrade nicht sofort möglich ist, setzen Sie die AnmeldenGraceTime Parameter 0 in der OpenSSH-Konfigurationsdatei. Dadurch wird verhindert, dass nicht authentifizierte Sitzungen geöffnet bleiben und ausgenutzt werden. Beachten Sie jedoch, dass dies zu einer Dienstverweigerung führen kann, wenn alle Verbindungssteckplätze belegt sind.
• Mehr Sicherheit mit Seccomp: Durch die Einschränkung der Systemaufrufe von SSHD wird die Angriffsfläche verringert und die Ausnutzung unsicherer Funktionen wie Syslog verhindert, wodurch die Ausführung willkürlichen Codes im Falle von Schwachstellen eingeschränkt wird.

RELIANOID Load Balancer: Verpflichtung zur Sicherheit

Alle Versionen der RELIANOID Load Balancer verfügt bereits über die aktualisierten Pakete im Repository. Dies spiegelt unser Engagement wider, den sichersten und zuverlässigsten Load Balancer bereitzustellen. Stellen Sie sicher, dass die neuesten Updates auf Ihren Load Balancern und Servern angewendet werden.

Bleiben Sie wachsam und stellen Sie sicher, dass Ihre Systeme gepatcht und vor dieser erheblichen Sicherheitsbedrohung geschützt sind. Kontakt zu unseren Sicherheitsexperten um mehr über diese Sicherheitslücke zu erfahren.