Wirksame Vorbereitung auf die OpenSSL 3.x-Sicherheitslücke
Update (1. November 2022): Die Bereitstellung von Akamai-Inhalten über HTTP und HTTPS ist von dieser Sicherheitslücke nicht betroffen, da die Server eine nicht betroffene Version von OpenSSL verwenden. Darüber hinaus nutzen Akamai-Systeme branchenübliche Stack-Schutzmechanismen, die die beschriebene Angriffsmethode entschärfen würden. Akamai ist dabei, alle potenziell betroffenen internen Systeme zu patchen, wir gehen jedoch nicht davon aus, dass diese Maßnahmen zu Ausfallzeiten für unsere Kunden führen.
Am 25. Oktober hat das OpenSSL-Projektteam bekannt gegeben, einen Sicherheitsfix für eine kritische Schwachstelle in OpenSSL Version 3.x zu veröffentlichen. Der Patch soll am 1. November 2022 zwischen 13:00 und 17:00 UTC veröffentlicht werden.
Diese Ankündigung hat wegen der weit verbreiteten Verwendung von OpenSSL viel Aufsehen erregt. Mit diesem Artikel hoffen wir, Klarheit zu schaffen und Hintergrundinformationen und Tipps zu geben, wie man die Bedrohung ohne Spekulationen erkennen und entschärfen kann. Im ersten Teil des Beitrags werden OpenSSL und das Ausmaß der Sicherheitslücke beschrieben. Im zweiten Teil wird beschrieben, wie OpenSSL in Anwendungen verwendet wird, und es werden Tools zur Erkennung anfälliger Ressourcen bereitgestellt. Sie können direkt zu diesen Dienstprogrammen springen, wenn Sie möchten.
Hinweis: Dieser Blogbeitrag behandelt einen voranschreitenden Vorfall und wird aktualisiert, sobald weitere Informationen gesammelt werden und die Fehlerbehebung veröffentlicht wird.
Wie groß ist das Ausmaß dieser Sicherheitslücke?
Diese Sicherheitslücke löste in der Sicherheits-Community Besorgnis aus, da es ungewöhnlich ist, dass das OpenSSL-Team eine Sicherheitslücke als kritisch einstuft, auch wenn diese später auf "Hoch" herabgestuft wurde. Seit diese Bezeichnungen für Sicherheitslücken nach Heartbleed (einer Sicherheitslücke, die Speicherverlust und eine mögliche Schlüssel-Preisgabe bewirken kann) eingeführt wurden, gab es nur eine andere Sicherheitslücke, CVE-2016-6309, die als "kritisch" eingestuft wurde.
Nach den Anforderungen des OpenSSL-Teams wird eine Schwachstelle dann als kritisch eingestuft, wenn sie gängige Konfigurationen betrifft und wahrscheinlich ausnutzbar ist. Ein Beispiel für eine solche Schwachstelle ist die „signifikante Offenlegung des Serverspeicher-Inhalts (die möglicherweise Nutzerdaten preisgibt), Schwachstellen, die leicht aus der Ferne ausgenutzt werden können, um die privaten Schlüssel des Servers zu kompromittieren, oder Schwachstellen, bei denen eine Remote-Codeausführung in geläufigen Szenarien als wahrscheinlich angesehen wird“.
Angesichts der weiten Verbreitung der OpenSSL-Bibliothek kann eine Sicherheitslücke in dieser Bibliothek sehr gefährlich sein. Obwohl Vorsicht geboten ist, gibt es noch keinen Grund für Panik. OpenSSL ist sehr häufig, die am weitesten verbreitete Version ist jedoch 1.x.x, und die Sicherheitslücke betrifft nur die OpenSSL-Versionen 3.0.0 und höher (die im September 2021 veröffentlicht wurde). Daher ist die Sicherheitslücke wahrscheinlich weniger weit als die OpenSSL-Bibliothek selbst verbreitet.
Wir haben unsere Erkennungstools in einigen unserer verwalteten Netzwerke ausgeführt und Folgendes erkannt:
In etwa 50 % der überwachten Umgebungen gab es mindestens einen Computer mit mindestens einem Prozess, der eine anfällige Version von OpenSSL nutzt.
Von diesen Netzwerken reichte der Prozentsatz der Maschinen im Netzwerk, die von einer anfälligen OpenSSL-Version abhängig waren, von 0,2% bis 33%.
Der Median der Abdeckung lag bei 6,1 % und das Mittel bei 11,3 % mit einer Standardabweichung von 11,6 %.
Diese Statistiken berücksichtigen nicht die Nutzung von nicht anfälligem OpenSSL. Die einzige Metrik sind Computer mit mindestens einem Prozess, der eine anfälligen Version von OpenSSL (3.0–3.6) nutzt. Auch andere Prozesse, die auf demselben Rechner laufen, wurden nicht berücksichtigt.
Was ist OpenSSL?
OpenSSL ist ein Open-Source-Software-Toolkit, und als solche sind OpenSSL-Versionen im Grunde Veröffentlichungen von Quellcode. Für die Erkennung bedeutet dies jedoch, dass es eine Vielzahl von Möglichkeiten gibt, wie eine Anwendung OpenSSL laden oder es nutzen kann, weshalb die Sicherheitslücke kritisch ist.
Zunächst müssen wir die drei Komponenten von OpenSSL definieren.
libcrypto – eine kryptografische Bibliothek mit Implementierung vieler Protokolle (z. B. AES, RSA, ChaCha usw.)
libssl – eine Bibliothek, die alle TLS-Protokolle bis zu TLSv1.3 implementiert
openssl – ein Befehlszeilenprogramm für verschiedene Operationen (z. B. das Generieren von Zertifikaten)
Damit eine Anwendung OpenSSL nutzen kann, muss sie eine Code-Logik von libcrypto oder libssl aufrufen (openssl selbst ist eine Anwendung, die die beiden anderen nutzt).
Entschärfen der OpenSSL-Sicherheitslücke
Der erste Schritt zur Entschärfung der OpenSSL-Bedrohung besteht darin, anfällige Ressourcen zu erkennen. Obwohl diese Empfehlung oft gehört wird, wird sie selten in die Tat umgesetzt. Wir stellen eine Liste der bekannten anfälligen Anwendungen (unten) bereit und empfehlen eine allgemeine Methode, um anfällige Anwendungen in Ihrem Netzwerk zu finden.
Segmentierung – eine Entschärfung vor und nach dem Patchen
Auch wenn das Patchen unter Umständen nicht sofort möglich ist, da der Großteil der Nutzung von OpenSSL durch die Software der Hersteller erfolgt (die den Fix selbst anwenden müssen), können wir dennoch die Einblicke nutzen, die wir durch die Erkennung erhalten. Wir können Segmentierung und Routing einsetzen, um die Verbreitung zu verringern, die ein Angreifer durch Ausnutzung der Schwachstelle haben könnte.
Wir können weitere Beschränkungen für Ressourcen, die mit dem Internet verbunden sind, in Form einer (strengeren) DMZ festlegen.
Wir können eine stärkere Segmentierung innerhalb der Domain vornehmen, sodass ein betroffener interner Rechner nicht zur Ausbreitung auf das gesamte Netzwerk genutzt werden kann. Dies kann auch genutzt werden, um die Angriffsfläche eines anfälligen Rechners auf den Teil des Netzwerks zu reduzieren, mit dem er tatsächlich kommunizieren muss.
Außerdem können wir diese Einblicke und Erkennung nutzen, um einen Patching-Aktionsplan zu erstellen und sicherzustellen, dass nichts übersehen wird. Nachdem Patches freigegeben und der Patchprozess abgeschlossen ist, können wir die Erkennungslogik erneut ausführen und die Ergebnisse vergleichen. Idealerweise finden wir keine weiteren anfälligen Maschinen.
Welche bekannten Anwendungen sind anfällig?
BoringSSL (wird in Google Chrome verwendet) und LibreSSL sind zwei Bibliotheken, die auf OpenSSL-Code basieren und noch nicht von der bevorstehenden Sicherheitslücke betroffen sind.
Verschiedene Linux-Distributionen werden häufig mit der OpenSSL-Bibliothek ausgeliefert. Wenn Sie eine Linux-Umgebung haben, sollten Sie überprüfen, ob Sie eine der folgenden Versionen verwenden, die mit dem anfälligen OpenSSL ausgeliefert werden.
Red Hat Enterprise Linux 9
Ubuntu 22.04 und höher
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
Wenn Sie eine Linux-Distribution verwenden, die nicht auf der Liste steht, ist die Sicherheit vor Sicherheitslücken dennoch nicht garantiert. Wenn Sie die Bibliothek aktiv aktualisiert haben (zum Beispiel als Teil des Upgrade-Befehls eines Paketmanagers), sind Sie ebenfalls anfällig. Sie können „openssl version“ in Ihrem Terminal eingeben, um die Version der Bibliothek zu sehen.
Docker veröffentlichte ebenfalls eine Empfehlung für die kommende Version, in der geschätzt wird, dass etwa 1.000 Image-Repositorys über verschiedene Docker Official-Images und Docker Verified Publisher-Images betroffen sein könnten. Dazu gehören Images, die auf Varianten der oben erwähnten Linux-Distributionen basieren.
Es gibt auch einige Frameworks, die betroffen sein könnten. Node.js v18.x und v19.x verwenden OpenSSL 3, daher wird angenommen, dass sie von der Sicherheitslücke betroffen sind. Alle neuen Updates werden in diesem Haifei Li finden Sie auch weitere Informationen über die Schwachstelle.
Eine weitere Programmiersprache, die Entwicklern momentan Sorgen bereitete, ist Golang. Bibliotheken in Go-Binärdateien sind statisch verknüpft, was möglicherweise erfordert hätte, dass Go-Entwickler ihre Software neu kompilieren. Als das Golang-Team neue inkrementelle Versionen ankündigte, die Sicherheitskorrekturen am selben Tag wie der kommende OpenSSL-Patch enthielten, wurde angenommen, dass die beiden Ereignisse miteinander in Verbindung stehen. Aber keine Sorge: Dabei handelte es sich um einen falschen Alarm. Die Versionen von Golang stehen in keinem Zusammenhang mit der bevorstehenden Sicherheitslücke.
Die Liste der anfälligen Anwendungen wird in den nächsten Tagen voraussichtlich länger werden, und wir werden diesen Beitrag entsprechend aktualisieren. Die nächsten Abschnitte enthalten Erkennungsmethoden und Tools, die Ihnen helfen, herauszufinden, welche Anwendungen in Ihrer Umgebung OpenSSL 3 nutzen und daher auch anfällig sind. Wenn Sie es vorziehen, können Sie direkt zu den Erkennungsmethoden springen.
Eine allgemeine Methode zur Erkennung von Anwendungen, die OpenSSL 3 nutzen
Hinweis: In diesem Abschnitt werden die internen Details der Verwendung von OpenSSL durch eine Anwendung beschrieben. Wenn Sie einfach nur an der Erkennung interessiert sind, können Sie direkt zu unseren YARA-Regeln oder OSQuery-Abfragen springen.
OpenSSL kann sowohl statisch als auch dynamisch mit einer Anwendung verknüpft werden. Bei der statischen Verknüpfung ist der OpenSSL-Quellcode als Teil des Anwendungscodes integriert und beide werden zusammen in derselben Binärdatei kompiliert. Bei der dynamischen Verknüpfung wird OpenSSL separat in einer gemeinsamen Bibliothek kompiliert (libssl.dll und libcrypto.dll unter Windows; libssl.so und libcrypto.so unter Linux). Der Anwendungscode enthält dann Verweise auf die freigegebene Bibliothek, die vom Betriebssystem beim Laden der Anwendung aufgelöst werden.
Wie führt dies zu einer Erkennung? Praktisch reicht eine Methode zur Erkennung statisch kompilierter Binärdateien aus. Warum? Wenn nämlich eine laufende Anwendung OpenSSL dynamisch lädt, oder sogar wenn sie eine Bibliothek dynamisch lädt, die wiederum OpenSSL dynamisch lädt (und so weiter und so fort), wird letzten Endes eine statisch kompilierte OpenSSL-Bibliothek geladen. Da alle dynamischen Ladevorgänge im Kontext desselben Prozesses stattfinden, müssen wir nur die Liste der in jeden Prozess geladenen Bibliotheken durchgehen und die statisch kompilierte Bibliothek finden.
Wir müssen also herausfinden, wie statisch kompiliertes OpenSSL aussieht. Glücklicherweise ist das ziemlich einfach. Alle statischen Kompilierungen von OpenSSL enthalten eine Versionszeichenfolge, die wie folgt aussieht: OpenSSL 3.0.6 11 Oct 2022 – wobei 3.0.6 die Versionsnummer ist. Diese Zeichenfolge kann entweder mit Regex oder YARA ziemlich einfach gefunden werden.
Allerdings könnte es sein, dass dies keine perfekte Übereinstimmung gibt. Da es sich bei OpenSSL um Open-Source-Code handelt, können Nutzer die Versionierungslogik ganz einfach an ihre Bedürfnisse anpassen (und so unsere Erkennung austricksen). Wir haben dies nur einmal gesehen (bei Cisco, das stattdessen die Zeichenfolge CiscoSSL 1.1.1k.7.2.225 verwendete), doch das könnte auch bei anderen Anbietern passieren.
Was mache ich jetzt?
Obwohl wir nicht viel wissen, bis der Fix veröffentlicht wird, gibt es einige Dinge, die man zum Schutz vorsorglich tun kann, um auf den Patch vorbereitet zu sein. Unser Team hat einige Dienstprogramme entwickelt, die Sie in Ihrer Umgebung ausführen können, um Einblick zu erhalten und die Entschärfung zu vereinfachen. Kunden von Akamai Guardicore Segmentation mit aktivierter Insight-Funktion können diese Logik mühelos in ihrer Umgebung ausführen.
YARA
Die wichtigste Regel, die wir nennen können, gilt für die oben erwähnte Zeichenfolge. Der Kürze halber beschränken wir unsere Erkennung auf die aktuellen Versionen von OpenSSL, die von der Veröffentlichung betroffen sind, doch wir können unsere Kriterien leicht ändern.
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
Falls wir uns die Zeichenfolge nicht verwenden wollen, können wir auch nach der Hauptanwendung suchen, die OpenSSL nutzt, und die Importe der ausführbaren Datei parsen. Dies ist jedoch eine weniger narrensichere Methode und sollte als solche behandelt werden.
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
Mit den obigen Abfragen können wir auch die YARA-Tabelle von osquery nutzen, um diese Regeln auf alle laufenden Prozesse anzuwenden.
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
Natürlich können Sie auch die anderen erwähnten YARA-Regeln einfügen oder mehr oder weniger Filter hinzufügen, um die Anzahl der geprüften Dateien einzuschränken oder zu erweitern.
Zusammenfassung
Das OpenSSL-Team hat einen interessanten Ansatz gewählt, indem es die Sicherheitsteams über die bevorstehende Veröffentlichung des Fixes informiert. Diese Ankündigung hat Verteidigern Zeit gegeben, kritische Ressourcen vorzubereiten und zuzuordnen, die für das Patching bereitstehen. In diesem Blogbeitrag haben wir versucht, genau dabei zu helfen – die Anwendungen und Ressourcen zu finden, die am Tag des Patches berücksichtigt werden müssen.
Dies ist eine sich laufend weiterentwickelnde Geschichte und wir werden diesen Blogbeitrag aktualisieren, sobald neue Informationen verfügbar sind. Schauen Sie also unbedingt wieder herein, um auf dem Laufenden zu bleiben. Sie können uns auch auf Twitter folgen, um weitere Updates in Echtzeit zu erhalten.