Patchen der OpenSSL-Schwachstellen CVE-2022-3786 und CVE-2022-3602: X.509 nur der Anfang

[datensicherheit.de, 02.11.2022] „Die Katze ist aus dem Sack“, so Kevin Bocek, „VP of Security Strategy & Threat Intelligence“ bei Venafi, in seinem aktuellen Kommentar: Der Patch sei verfügbar und anstatt einer kritischen Schwachstelle habe es zwei gegeben – welche allerdings nur noch „hoch“ und nicht mehr „kritisch“ bewertet würden. Doch für IT-Abteilungen heiße es dennoch, diese Schwachstellen zu beheben, denn das Patchen dieser „OpenSSL“-Schwachstellen mit den Bezeichnungen „CVE-2022-3786“ und „CVE-2022-3602: X.509“ sei nur der Anfang. Vielmehr zeigten diese wieder einmal auf, „wie unsicher Maschinenidentitäten sein können, wenn sich Bedrohungsakteure ihrer bemächtigen und sich als vertrauenswürdige Dienste ausgeben“. Bocek führt aus: „Egal, ob ein Unternehmen in der Cloud in Azure arbeitet, Kubernetes in Amazon AWS nutzt oder Apache in einem Rechenzentrum verwendet, das gesamte digitale Geschäft erfordert eine sichere Authentifizierung von Maschinenidentitäten.“ Die Schwachstellen in „OpenSSL“ zeigten, welche Auswirkungen ein mangelhaftes Management von Maschinenidentitäten – insbesondere die Authentifizierung von Maschinenidentitäten – habe und damit „Angreifern Tür und Tor öffnet“.

Foto: Venafi

Kevin Bocek: „Heartbleed“ hat gezeigt, dass die Branche auf diese Ereignisse vorbereitet sein muss – jetzt und in Zukunft!

OpenSSL-Schwachstellen zeigen: Mangel an Transparenz komplexer Cloud-Umgebungen lässt Unternehmen gefährlich offen für Angriffe

Der derzeitige Mangel an Transparenz komplexer „Cloud“-Umgebungen lasse Unternehmen gefährlich offen für Angriffe. Die „Cloud“ sei eine unerschlossene Angriffsfläche für Bedrohungsakteure und es lasse sich vermuten, dass es in den nächsten Monaten noch viel mehr Angriffe auf native „Cloud“-Umgebungen geben werde.

Bocek warnt: „Sowohl auf Seiten der Bedrohungsakteure als auch auf Seiten der Sicherheitsbehörden gibt es eine Wissenslücke, so dass die Auswirkungen auf die Sicherheit, die möglichen Angriffe und die Schwachstellen, die sie aufdecken könnten, noch nicht wirklich verstanden werden.“ Je besser Unternehmen diese komplexen Umgebungen verstehen, desto mehr kritische Schwachstellen und folgenschwere Angriffe würden aufgedeckt werden.

Wie bei Heartbleed müssen Unternehmen auch die von der OpenSSL-Schwachstelle betroffenen Maschinenidentitäten ersetzen

Jetzt, da die Sicherheitslücken bekannt geworden sind, sei es wahrscheinlich, dass Bedrohungsakteure bereits versuchten, diese auszunutzen. „Um sich zu schützen, müssen Unternehmen die Priorität auf Patches legen, und zwar schnell. Aber wie bei ,Heartbleed’ müssen Unternehmen auch die von der ,OpenSSL’-Schwachstelle betroffenen Maschinenidentitäten ersetzen.“

Unternehmen könnten nur dann erfolgreich sein, „wenn die vier Aufgaben des Maschinenidentitätsmanagements – Authentifizierung, Autorisierung, Lifecycle und Governance – korrekt funktionieren“. Abschließend unterstreicht Bocek: „,Heartbleed’ hat gezeigt, dass die Branche auf diese Ereignisse vorbereitet sein muss, jetzt und in Zukunft.“

Weitere Informationen zum Thema:

OpenSSL Blog, 01.11.2022
CVE-2022-3786 and CVE-2022-3602: X.509 Email Address Buffer Overflows

datensicherheit.de, 31.10.2022
OpenSSL: Kritische Sicherheitslücke weckt Erinnerungen an Heartbleed / Der Angriffsvektor ist durch Virtualisierung viel größer geworden

Unternehmen müssen den Weckruf hören

[datensicherheit.de, 19.09.2018] Heartbleed ist ein schwerwiegender Bug in OpenSSL, der bereits im Jahr 2014 entdeckt wurde und es Unbefugten und Kriminellen erlaubt, scheinbar sichere und verschlüsselte TLS-Verbindungen auszuspionieren und private Daten von Clients und Servern zu lesen. Der Global Threat Index für August 2018 von Check Point zeigt, dass der Fehler noch vier Jahre nach seiner Entdeckung zu einer der Schwachstellen zählt, die am häufigsten ausgenutzt werden.

Foto: Venafi

Kevin Bocek, VP Security Strategy and Threat Intelligence bei Venafi

Kevin Bocek erklärt dazu: „Heartbleed lebt und wird von Kriminellen ausgenutzt. Check Point erkennt, dass die zweithäufigste ausgenutzte Schwachstelle im August 2018 Heartbleed war (CVE-2014-0160; CVE-2014-0346). Dies ist ein Weckruf, dass der oft scheiternde Korrekturschritt, die Ersetzung aller Maschinenidentitäten wie TLS-Schlüssel und Zertifikate, noch ausgeführt werden muss.“

„Die Global 5000 Unternehmen, darunter eine Mehrheit in Deutschland, hatten es bereits ein Jahr nach der ersten Meldung nicht geschafft, Heartbleed vollständig zu beseitigen, und schlimmer noch, die meisten deutschen Unternehmen sind immer noch anfällig – vier Jahre später. Eine vollständige Behebung der Schwachstelle erforderte sowohl das Patchen als auch ein anschließendes Ersetzen aller verletzlichen Maschinenidentitäten, weil diese leicht gestohlen werden können“, so Bocek weiter. „Während die Unternehmen patchen, ersetzten die meisten allerdings nicht die TLS-Schlüssel und -Zertifikate. Genau diese sind aber durch Heartbleed verwundbar. Ohne Reaktion können Maschinen im Internet nachgeahmt oder private Kommunikationen leicht mitgelesen werden. Daher ist der Schutz aller Maschinenidentitäten wie TLS-Schlüssel und Zertifikate dringend erforderlich. In der letzten Woche gab das US Government Accountability Office (GAO) bekannt, dass eine der Hauptursachen für den weitreichenden Equifiax-Vorfall der fehlende Schutz eines unbekannten und abgelaufenen TLS-Zertifikats war. Dadurch waren die Systeme zur Threat Protection für einen Angriff blind.“

Bild: Venafi

Jens Sabitzer, Sales Engineer DACH bei Venafi

Jens Sabitzer ergänzt: „Heartbleed war eine der am weitesten verbreiteten und gefährlichsten Sicherheitsprobleme in der jüngsten Geschichte der Kryptografie, und der Bericht von Check Point beweist, dass es sich immer noch um ein großes Risiko im Internet handelt. Der Diebstahl von Maschinenidentitäten ermöglicht fortgeschrittene Attacken wie Man-in-the-Middle oder versteckte Lauschangriffe. Organisationen sollten ihren Schutz rund um ihre Maschinenidentitäten herum verbessern. Der Vorfall im Bundesministerium für Verkehr und digitale Infrastruktur (BMVI) im Jahr 2016 macht zudem deutlich, dass häufig eine Behebung keine ausreichenden Maßnahmen ergriffen werden. Nach dem unverzichtbaren Austausch von Maschinenidentitäten müssen außerdem zukünftige Fehler, wie z. B. bei der Einrichtung neuer Webserver und -Dienste, vermieden werden.“

Weitere Informationen zum Thema:

Check Point
Global Threat Index für August 2018

datensicherheit.de, 13.04.2016
Integration von SSL-Zertifikaten wird künftig zur Pflicht

datensicherheit.de, 09.06.2014
Security Advisory: Neue Sicherheitslücken in OpenSSL identifiziert

datensicherheit.de, 11.04.2014
OpenSSL: BSI stuft „Heartbleed Bug“ als kritisch ein

[datensicherheit.de, 09.06.2014] Gestern (08.06.2014) wurde ein neues Security Advisory von OpenSSL veröffentlicht, das sechs neue Sicherheitslücken verzeichnet. Im Gegensatz zu Heartbleed, der Sicherheitslücke, die im April 2014 identifiziert wurde, ist das Schlüsselmaterial digitaler Zertifikate nicht anfällig für die Gefährdung. Eine mögliche Ausnahme besteht allerdings, wenn man mit DTLS arbeitet.

Zu den neu identifizierten Sicherheitslücken gehören ein SSL/TLS-Bug, der es einem Angreifer erlaubt einen Man-in-the-Middle-Angriff (MITM) durchzuführen, der zur Exposition sensibler Daten führen kann und eine DTLS-Sicherheitslücke, die die Injektion von bösartigem Code in anfällige Software und Geräte ermöglicht.

Empfohlene Maßnahmen:

• OpenSSL-Benutzern sollten  ihre Systeme sofort mit den bereitgestellten Patches und Empfehlungen aktualisieren.
• Wenn DTLS nicht eingesetzt wird, müssen Zertifikate nicht neu ausgestellt werden
• Wenn DTLS im Gebrauch ist, können einige zusätzliche Schritte erforderlich sein.  Bitte wenden Sie sich an den Support des Zertifikatsanbieters  für weitere Hinweise

Empfohlene Upgrades aus dem OpenSSL Security Advisory:

• Benutzer von Version 0.9.8 SSL/TLS (Client und/oder Server) sollten auf 0.9.8za aktualisieren.
• Benutzer von Version 1.0.0 SSL/TLS (Client und/oder Server) sollten auf 1.0.0m aktualisieren.
• Benutzer von Version 1.0.1 SSL/TLS (Client und/oder Server) sollten auf 1.0.1h aktualisieren.
• Benutzer von Version 0.9.8 DTLS sollten auf 0.9.8za aktualisieren.
• Benutzer von Version 1.0.0 DTLS sollten auf 1.0.0m aktualisieren.
• Benutzer von Version 1.0.1 DTLS sollten auf 1.0.1h aktualisieren.
• Benutzer von Version 1.0.0 sollten auf 1.0.0m aktualisieren.
• Benutzer von Version 1.0.1 sollten auf 1.0.1h aktualisieren.

Weitere Informationen zum Thema:

OpenSSL, 05.06.2014
OpenSSL Security Advisory

datensicherheit.de, 11.04.2014
OpenSSL: BSI stuft „Heartbleed Bug“ als kritisch ein

[datensicherheit.de, 11.04.2014] Der „Heartbleed Bug“, über den derzeit in den Medien berichtet wird, ist eine Sicherheitslücke in einer Programmerweiterung von OpenSSL namens „Heartbeat“. OpenSSL ist eine freie Software-Bibliothek für Transport Layer Security (TLS) und umfasst Implementierungen verschiedener Verschlüsselungen. Insbesondere Web- und Mail-Server aber auch andere Dienste wie Virtual Private Networks oder Appliances wie Router nutzen häufig diese Bibliothek für TLS/SSL-Verbindungen. Die Bibliothek enthält in den Versionen 1.0.1 bis 1.0.1f eine Schwachstelle, den „Heartbleed-Bug“.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft diese Schwachstelle als kritisch ein. Ein Angreifer ist unter Ausnutzung der Schwachstelle in der Lage, Speicherinhalte des OpenSSL Servers auszulesen, sofern diese die „Heartbeat“-Erweiterung aktiviert haben. Mithilfe des „Heartbleed Bugs“ können zudem unter Umständen die geheimen Schlüssel von OpenSSL-Servern ausgelesen werden.

Seit dem 7. April 2014 steht mit OpenSSL Version 1.0.1g ein Update zur Verfügung, das die Sicherheitslücke schließt. Betreiber, die auf ihren Servern OpenSSL einsetzen, sollten das Update umgehend einspielen. Falls seit März 2012 eine verwundbare OpenSSL-Version mit aktivierter Heartbeat-Erweiterung eingesetzt wurde, kann eine vergangene Kompromittierung von Schlüsseln nicht ausgeschlossen werden. Daher empfiehlt das BSI in einem solchen Fall den Austausch der verwendeten OpenSSL Server-, beziehungsweise Client-Zertifikate und Schlüssel sowie eine Änderung der verwendeten Passwörter. Der Austausch sollte erst nach der Einspielung des Updates erfolgen, da ansonsten die neuen Zertifikate wieder kompromittiert werden könnten. Die alten Zertifikate müssen nach erfolgreichem Austausch gesperrt werden. Betreiber sind aufgerufen, ihre Nutzer über die Umsetzung der Aktualisierung zu informieren, damit diese ihre Passwörter kurzfristig ändern.