Eine schwerwiegende Sicherheitslücke, die die Ausführung von nicht authentifiziertem Remote -Code (RCE) ermöglicht , wurde kürzlich im OpenSSH-Server (sshd) auf glibc-basierten Linux-Systemen entdeckt. Diese hochriskante Schwachstelle mit der Kennung CVE-2024-6387 stellt ein erhebliches Sicherheitsrisiko dar, da sie die Ausführung von nicht authentifiziertem Remote-Code mit Root-Rechten erlaubt.
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 innerhalb der LoginGraceTime- Periode nicht authentifizieren kann . Diese ist in neueren Versionen standardmäßig auf 120 Sekunden und in älteren Versionen auf 600 Sekunden eingestellt. Sobald dieses Timeout erreicht ist, wird der SIGALRM- Handler von sshd ausgelöst. Das Problem entsteht, weil dieser Handler verschiedene Funktionen aufruft, wie beispielsweise syslog() , deren Aufruf innerhalb eines Signalhandlers unsicher ist. Diese Race Condition stellt ein erhebliches Risiko für Systeme dar, die die Standardkonfiguration von sshd verwenden.
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.
Die Sicherheitslücke trat im Oktober 2020 mit der Veröffentlichung von OpenSSH 8.5p1 auf. Bei einem Update der Protokollierungsinfrastruktur wurde versehentlich eine wichtige Direktive ( #ifdef DO_LOG_SAFE_IN_SIGHAND ) aus der Funktion `sigdie()` entfernt . Diese Funktion, die direkt vom SIGALRM- Handler von sshd aufgerufen wird, war dadurch wieder unsicher. Im Folgenden finden Sie eine Übersicht über den zeitlichen Ablauf 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, da syslog() selbst andere unsichere Funktionen wie malloc() und free() aufrufen kann . Dadurch entsteht die Möglichkeit für einen Angreifer, beliebigen Code als Root auszuführen, ohne sich authentifizieren zu müssen. Dies liegt daran, dass der privilegierte Code von sshd mit vollen Systemrechten arbeitet und nicht in einer Sandbox ausgeführt wird.
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 das LoginGraceTime- Limit aus, ohne die Authentifizierung abzuschließen. Dies führt dazu, dass der Server das SIGALRM- Signal sendet.
Interrupt-Signal-Handler
Die Ausnutzung beruht darauf, den Signalhandler des Servers genau in dem Moment zu unterbrechen, in dem er nicht-asynchrone signalsichere Operationen ausführt, wie beispielsweise syslog() . Der Angreifer sendet speziell präparierte Eingaben, um das Speicherlayout des Servers zu manipulieren und so eine Beschädigung des Heaps zu verursachen.
Speicherlayout manipulieren
Durch Manipulation des Serverspeichers erzeugt der Angreifer einen inkonsistenten Zustand im Heap. Dies geschieht durch Auslösen des SIGALRM-Signals während Speicherbelegungs- oder -freigabefunktionen wie malloc() oder free() . Die Ausnutzung dieser Schwachstelle erfordert typischerweise etwa 10,000 Versuche. Jeder Versuch setzt den LoginGraceTime-Timer zurück und bietet dem Angreifer somit ein neues Zeitfenster, um die Schwachstelle auszunutzen.
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.
Seien Sie wachsam und stellen Sie sicher, dass Ihre Systeme auf dem neuesten Stand sind und vor dieser schwerwiegenden Sicherheitsbedrohung geschützt sind. Kontaktieren Sie unsere Sicherheitsexperten, um mehr über diese Schwachstelle zu erfahren.
Verwandte Blogs
