Open SSL: Patch veröffentlicht

Die kürzlich entdeckte Open SSL Schwachstelle hat potentiell gravierende Auswirkungen. Mit der jetzt erhältlichen Version 3.07 sollte das Problem behoben sein. Die Version, die als Security Fix Release angekündigt worden war, wurde am Dienstag, den 1. November veröffentlicht. Seit letztem Donnerstag gab es viele Spekulationen, aber jetzt ist klar, dass statt einer kritischen Schwachstelle zwei schwerwiegende Schwachstellen behoben wurden, die in erster Linie zu einem Denial-of-Service führen können.

Hierzu ein Kommentar von Claire Tills, Senior Research Engineer bei Tenable:

„Nach der Vorankündigung und dem gespannten Warten enthüllte das aktuelle Release von OpenSSL ein paar schwerwiegende Schwachstellen, die nicht leicht auszunutzen sind und nur eine kleine Teilmenge von OpenSSL-Implementierungen betreffen. CVE-2022-3786 und CVE-2022-3602 sind Buffer-Overflow-Schwachstellen in den OpenSSL-Versionen 3.0.0 bis 3.0.6. Das wahrscheinlichste Ergebnis einer erfolgreichen Ausnutzung ist ein Denial-of-Service, aber auch Remote-Code-Ausführung ist möglich, wenn kein Schutz vor Stack Overflow vorhanden ist. Beide Schwachstellen müssen nach der Signaturprüfung der Zertifikatskette ausgelöst werden, was bedeutet, dass ein Angreifer sein schädliches Zertifikat wahrscheinlich signieren lassen muss.

In diesem Fall bedeutete die Vorankündigung der Schwachstelle durch OpenSSL, bevor die Untersuchung abgeschlossen war, dass das Unternehmen seine Beschreibung der Schwachstellen anpassen musste. Diejenigen, die auf diese Situation reagierten, haben möglicherweise unnötig Ressourcen verbrannt. Dennoch ist dies eine Gelegenheit für Unternehmen, ihre Reaktionsprozesse zu bewerten und zu verstehen, was verbessert werden kann. Wie schwierig war es für sie, herauszufinden, welche Version von OpenSSL sie eingesetzt hatten oder ob eine Software, auf die sie angewiesen waren, anfällig war? Waren ihre Kommunikationskanäle ausgereift genug, um die richtigen Informationen an die Personen zu übermitteln, die sie benötigten, sobald sie verfügbar waren?“

Update von Check Point zur OpenSSL-Sicherheitslücke

Eine angespannte Woche des Wartens hat ein Ende, da das Embargo aufgehoben wurde. Es gibt zwei Sicherheitslücken in OpenSSL, die nun gepatcht werden müssen. Diese Schwachstellen können unter den Bezeichnungen CVE-2022-3602 (Remote Code Execution) und CVE-2022-3786 (Denial of Service) nachverfolgt werden. Sie betreffen die OpenSSL-Versionen 3.0.0 – 3.0.6 und sind in der neuesten Version 3.0.7 gepatcht. Sicherheitsforscher von Check Point arbeiten daran, dass alle Unternehmen so schnell wie möglich den besten Schutz erhalten. Check Point Research (CPR) wird sich auch zu den Auswirkungen eines möglichen Angriffs äußern, sobald mehr Informationen verfügbar sind.

Unternehmen müssen nun alle anfälligen Produkte mit dem Fix der OpenSSL-Entwickler aktualisieren, damit sich niemand Sorgen über Bedrohungsakteure machen muss, die über diese Schwachstellen gesammelte Informationen als Angriffsvektor einsetzen wollen. Dies ist jedoch keine leichte Aufgabe und wird bei einigen Anbietern einige Zeit in Anspruch nehmen. Hier kann eine Liste der verwundbaren und nicht verwundbaren Software eingesehen werden: https://github.com/NCSC-NL/OpenSSL-2022/tree/main/software?s=08

Lotem Finkelsteen, Director Threat Intelligence & Research kommentiert: „OpenSSL hat dem wochenlangen Warten um die kritische Sicherheitslücke ein Ende gesetzt. Die Enthüllung ist, dass diese Schwachstelle in der Lage ist, Remote-Code auszuführen, was ein hohes Risiko für jedes SSL-verschlüsselte Produkt darstellt. Unternehmen befinden sich jetzt in einer Form des Sicherheitswettrennens. Check Point wird einen virtuellen Patch bereitstellen, um Technologieanbietern die nötige Zeit zu geben, ihre offenen SSL-Bibliotheken zu aktualisieren. Die Benutzer sollten geschützt sein, bis weitere Updates verfügbar sind.“

Kommentar von Qualys zu den OpenSSL-Schwachstellen

Paul Baird, Chief Technology Security Officer UK bei Qualys, erklärt: „Die Security-Community kann wohl aufatmen, dass dies kein massives Wettrüsten zwischen Angreifern und Verteidigern wird. Es ist zwar immer noch wichtig, Patches zu installieren, aber es ist nicht das große Sicherheitsproblem, das beispielsweise Heartbleed war. Aus Sicht der Sicherheitsbranche ist das eine gute Nachricht, da das Risiko dieser Schwachstelle nicht so hoch ist.

Eine präventive Suche nach potenziell schwerwiegenden Problemen kann Unternehmen helfen, sich vorzubereiten, bevor Details veröffentlicht werden. So kann z.B. die Verwendung von Tools für die Verwaltung von Cybersicherheitsressourcen einen Überblick über den Stand der Dinge liefern, der bei der Festlegung von Prioritäten helfen kann. Bei diesem speziellen Problem kann das Wissen, dass nur die Versionen 3.0.0 bis 3.0.6 von OpenSSL betroffen sind, bevor die Details veröffentlicht werden, zeigen, ob es sich um ein ernstes Problem für handelt. Dies zeugt von Reife und Kontrolle über Ihre Umgebung.

Gleichzeitig müssen wir uns darüber im Klaren sein, wie viel Zeit und Mühe es kostet, wenn ein kritisches Problem in einem gängigen Softwarepaket aufgedeckt wird. Dies kann sich auf die Art und Weise auswirken, wie die Mitarbeiter im Laufe der Zeit Prioritäten setzen. Wenn wir vom Unternehmen ernst genommen werden wollen und wenn es um das Risikomanagement geht, können sich diese Vorfälle negativ auswirken. Die Branche muss den richtigen Weg finden, um diese Probleme zu bewältigen und sie sowohl für die IT als auch für das Unternehmen einfacher zu machen.“

OpenSSL-Schwachstellen nicht kritisch, schnelles patchen dennoch erforderlich

Dr. Johannes Ullrich, Dean of Research beim SANS Technology Institute, äußert sich wie folgt: „OpenSSL hat Version 3.0.7 veröffentlicht, die zwei zusammenhängende, als „hoch“ eingestufte Schwachstellen behebt. Ursprünglich wurde eine der Sicherheitslücken im Rahmen einer Vorankündigung als „kritisch“ eingestuft. OpenSSL 3.0 wurde ursprünglich im September letzten Jahres veröffentlicht.

Das Update behebt eine Pufferüberlaufschwachstelle, die während der Zertifikatsüberprüfung auftritt. Das Zertifikat muss einen bösartigen, in Punycode kodierten Namen enthalten und die Sicherheitslücke wird erst nach der Überprüfung der Zertifikatskette ausgelöst. Ein Angreifer muss zunächst in der Lage sein, ein bösartiges Zertifikat von einer Zertifizierungsstelle signieren zu lassen, der der Client vertraut. Für Server scheint dies kaum ausnutzbar zu sein, es sei denn, sie fordern ein Zertifikat vom Client an (mTLS). OpenSSL hat hierzu auch einen Blogbeitrag mit weiteren Details veröffentlicht: https://www.openssl.org/blog/blog/2022/11/01/email-address-overflows/

Es handelt sich zwar um eine potenzielle Schwachstelle für die Ausführung von Remotecode, aber die Voraussetzungen für die Auslösung der Schwachstelle sind nicht trivial und diese Schwachstelle kann nicht als „Heartbleed-Notfall“ angesehen werden. IT-Abteilungen sollten dennoch schnell patchen, sobald aktualisierte Pakete verfügbar sind, darüber hinaus besteht kein unmittelbarer Handlungsbedarf.“

OpenSSL-Schwachstellen: Patch verfügbar, aber nicht mehr kritisch

Kevin Bocek, VP of Security Strategy & Threat Intelligence bei Venafi, ergänzt: „Die Katze ist aus dem Sack. Der Patch ist verfügbar und anstatt einer kritischen Schwachstelle, gab es zwei, die allerdings nur noch „hoch“ und nicht mehr „kritisch“ sind. Doch für IT-Abteilungen heißt es dennoch, diese Schwachstellen zu beheben, denn das Patchen dieser OpenSSL-Schwachstellen mit den Bezeichnungen CVE-2022-3786 and CVE-2022-3602: X.509 ist nur der Anfang. Vielmehr zeigen sie wieder einmal auf, wie unsicher Maschinenidentitäten sein können, wenn sich Bedrohungsakteure ihrer bemächtigen und sich als vertrauenswürdige Dienste ausgeben. 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 zeigen, welche Auswirkungen ein mangelhaftes Management von Maschinenidentitäten – insbesondere die Authentifizierung von Maschinenidentitäten – hat und Angreifern Tür und Tor öffnet.

Der derzeitige Mangel an Transparenz komplexer Cloud-Umgebungen lässt Unternehmen gefährlich offen für Angriffe. Die Cloud ist eine unerschlossene Angriffsfläche für Bedrohungsakteure und es lässt sich vermuten, dass es in den nächsten Monaten noch viel mehr Angriffe auf native Cloud-Umgebungen geben wird. 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 werden aufgedeckt.

Jetzt, da die Sicherheitslücken bekannt geworden sind, ist es wahrscheinlich, dass Bedrohungsakteure bereits versuchen, sie 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önnen nur dann erfolgreich sein, wenn die vier Aufgaben des Maschinenidentitätsmanagements – Authentifizierung, Autorisierung, Lifecycle und Governance – korrekt funktionieren. Heartbleed hat gezeigt, dass die Branche auf diese Ereignisse vorbereitet sein muss, jetzt und in Zukunft.“