CVE-2022-3602 und CVE-2022-3768
Am 1. November 2022 veröffentlichte OpenSSL nach der Ankündigung in der Woche zuvor ein Advisory, das zwei Risiken für OpenSSL 3.0.0 - 3.0.6 beschreibt. Ursprünglich war die Warnung als kritisch angekündigt worden, was die erste kritische Warnung seit 2015 gewesen wäre, doch wurde sie aufgrund von "mildernden Faktoren", wie OpenSSL sie beschreibt, auf "hoch" herabgestuft.
Die beiden Schwachstellen beruhen auf Pufferüberläufen im Feld "E-Mail-Adresse" in einem X509-Zertifikat. Durch eine spezielle Gestaltung der E-Mail-Adresse könnte ein Angreifer einen Pufferüberlauf verursachen und 4 Bytes auf dem Stapel des Zielsystems kontrollieren (CVE-2022-3602), oder durch Auffüllen der E-Mail-Adresse mit einem bestimmten Zeichen könnte der Angreifer den Puffer überlaufen lassen und das System zum Absturz bringen (CVE-2022-3768). Diese beiden Schwachstellen könnten für sich genommen den Anschein erwecken, als würden sie alles auf einmal zum Einsturz bringen, jedoch sind diese abschwächenden Faktoren ziemlich wichtig.
Der erste mildernde Faktor ist, dass diese beiden Schwachstellen ein gewisses Maß an Interaktion seitens des Clients bzw. des angegriffenen Servers erfordern. Bei beiden Schwachstellen müsste ein mit OpenSSL3.0 arbeitender Client einen bösartigen Server besuchen, auf dem ein bösartiges x509-Zertifikat liegt. Auch wenn dies im täglichen Betrieb durchaus möglich ist, müsste ein Benutzer auf einen Link klicken oder ein Dokument öffnen, um kompromittiert zu werden. Dies ist zwar durchaus üblich, doch gibt es einfachere Möglichkeiten als die Ausnutzung einer OpenSSL-Schwachstelle, um eine Remote-Code-Ausführung durchzuführen.
Auf der Serverseite müsste der angegriffene Server ein Client-Authentifizierungszertifikat von einem bösartigen Client anfordern. Dies ist keine normale Konfiguration für Server, die mit dem Internet verbunden sind, und wird eher bei Geräten vor Ort verwendet. In diesem Fall müsste eine böswillige dritte Partei nahe genug sein, um ein Netzwerk anzugreifen.
Ein weiterer wichtiger Faktor zur Abschwächung dieser Schwachstellen ist, dass die verwendeten Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle (CA) signiert sein müssen, oder die Anwendung muss fortgesetzt werden, ohne dass ein Pfad zu einer vertrauenswürdigen CA hergestellt werden kann, um diese Überläufe auszulösen. Dies ist für die meisten Angreifer eine nicht triviale Aufgabe, auch wenn es Möglichkeiten gibt, offenere Zertifizierungsstellen zu verwenden, ist die Wahrscheinlichkeit groß, dass diese Anbieter die Zertifikatsignierungsanfragen überprüfen, um diese E-Mail-Adressfelder zu finden, die möglicherweise bösartig sind.
Es gibt auch keine große Anzahl von Systemen, auf denen OpenSSL3.0 läuft. Die Zahl ist definitiv nicht null, aber um es in die richtige Perspektive zu rücken, haben zwei der wichtigsten Nicht-Windows-Server-Betriebssysteme, RHEL und Ubuntu, OpenSSL3.0 erst in diesem Jahr in ihre Plattformen integriert. RHEL 9 wurde im Mai 2022 veröffentlicht und Ubuntu 22.04 im August 2022. Das bedeutet, dass viele Systemadministratoren noch keine Gelegenheit hatten, auf diese Zweige zu aktualisieren, und dass es sich dabei nur um die neuesten LTS-Versionen handelt, so dass ein Upgrade möglicherweise nicht erforderlich ist. Es sollte jedoch beachtet werden, dass diese Versionen möglicherweise für die Erstellung von Docker-Containern und anderen containerisierten Anwendungen verwendet werden.
Schließlich hat OpenSSL nicht festgestellt, dass diese Schwachstellen in freier Wildbahn ausgenutzt werden, es handelt sich also nicht um einen "Out of Band"-Patch, bei dem es eine aktive Angriffskampagne gibt. Trotzdem wird empfohlen, Systeme, auf denen OpenSSL3.0.0-3.0.6 läuft, auf 3.0.7 zu patchen.
Vectra verfügt nicht über eine spezielle Erkennung oder eine gespeicherte Suche, um potenzielle Nutzungen dieser spezifischen Schwachstellen zu finden. Wie bei allen Schwachstellen, die auf Infrastrukturen oder Clients abzielen, ist die Schwachstelle jedoch nur der erste Infektionsvektor in einer laufenden Kompromittierung. Wenn ein Client oder Server mit den oben genannten Techniken kompromittiert wird, wird wahrscheinlich ein Implantat oder Trojaner eingesetzt. In diesen Fällen könnten die Kunden mit den folgenden Erkennungen rechnen:
- Versteckter DNS-Tunnel
- Versteckter HTTP-Tunnel
- Versteckter HTTPS-Tunnel
- Externer Fernzugriff
- Vectra Intelligente Bedrohung Match
- Tunnel mit mehreren Häusern an der Fassade
Dazu gehören bösartige Tools und C2-Implantate, unabhängig von der Schwachstelle, über die sie eingesetzt werden.
Da es sich um eine laufende Kampagne handelt, ist davon auszugehen, dass es auch zu seitlichen Bewegungen kommen wird. In diesem Fall bietet Vectra Deckung für die folgenden Techniken:
- Verdächtige Remote-Ausführung
- Privilegienanomalie: Ungewöhnlicher Dienst
- Privilegienanomalie: Ungewöhnliches Konto auf dem Host
- Verdächtiger Remote Desktop
- Privilegienanomalie: Ungewöhnlicher Service - Insider
- Privilegienanomalie: Ungewöhnliches Trio, Privilegienanomalie: Ungewöhnlicher Gastgeber
- Privilegienanomalie: Ungewöhnlicher Dienst vom Host
- Verdächtiger Admin
Unabhängig vom verwendeten Tool sind diese Erkennungen so konzipiert, dass sie die Verhaltensweisen abdecken, die Angreifer nach der Kompromittierung einsetzen, um ihre endgültigen Ziele in Ihrer Umgebung zu erreichen.