OpenSSL warnt vor kritischer Sicherheitslücke

OpenSSL macht es möglich, sichere Transport Layer Security (TLS) unter Linux, Unix, Windows und vielen anderen Betriebssystemen zu verwenden. Jetzt ist eine Schwachstelle entdeckt worden: Mark Cox, ein Red Hat Distinguished Software Engineer und VP of Security der Apache Software Foundation (ASF), hat getwittert: „OpenSSL 3.0.7 update to fix Critical CVE out next Tuesday 1300-1700UTC“. LibreSSL ist nicht betroffen.

Laut OpenSSL betrifft ein Problem mit kritischem Schweregrad gängige Konfigurationen und ist wahrscheinlich auch ausnutzbar. Es ist wahrscheinlich, dass es missbraucht wird, um den Speicherinhalt des Servers offenzulegen und möglicherweise Benutzerdaten preiszugeben, und es könnte leicht aus der Ferne ausgenutzt werden, um private Schlüssel des Servers zu kompromittieren oder Code aus der Ferne auszuführen. Mit anderen Worten, so ziemlich alles, was Sie nicht auf Ihren Produktionssystemen haben wollen.

Das letzte Mal, dass OpenSSL eine Sicherheitslücke wie diese aufwies, war 2016. Diese Sicherheitslücke konnte dazu genutzt werden, Systeme zum Absturz zu bringen und zu übernehmen. Selbst Jahre nach ihrem Auftreten schätzte das Sicherheitsunternehmen Check Point, dass mehr als 42 % der Unternehmen davon betroffen waren.

Warum also die Sicherheitslücke ankündigen, bevor der Patch da ist? Cox erklärte: „Das ist unsere Politik … um den Leuten ein Datum zu geben, an dem sie wissen, dass sie bereit sind, ein Advisory zu analysieren und zu sehen, ob das Problem sie betrifft.

Es gibt noch einen kleinen Silberstreif. Diese neue Lücke betrifft nur die OpenSSL-Versionen 3.0.0 bis 3.0.6. Ältere Betriebssysteme und Geräte sind also wahrscheinlich von diesen Problemen verschont. So sind beispielsweise Red Hat Enterprise Linux (RHEL) 8.x und früher sowie Ubuntu 20.04 nicht betroffen. Bei RHEL 9.x und Ubuntu 22.04 sieht es jedoch anders aus. Sie verwenden OpenSSL 3.x.

Wenn Sie ein Linux-Benutzer sind, können Sie Ihr eigenes System überprüfen, indem Sie den Shell-Befehl „# openssl version“ eingeben.

Wenn Sie irgendetwas mit OpenSSL 3.x verwenden – egal was -, machen Sie sich bereit für den Patch am Dienstag. Es handelt sich wahrscheinlich um eine schlimme Sicherheitslücke, und es werden bald Exploits folgen. Sie sollten Ihre Systeme so schnell wie möglich absichern.

Mattias Gees, Container Product Lead bei Venafi, kommentiert: „Die Ankündigung der neuen kritischen OpenSSL-Sicherheitslücke in der Version 3.0.7 zum 1. November weckte sofort unangenehme Erinnerungen an Heartbleed oder – in jüngerer Zeit – an die Log4J-Sicherheitslücke. Heartbleed hatte erhebliche Auswirkungen auf alle IT-Teams weltweit, und seither ist die IT-Infrastruktur zehnmal komplizierter geworden. Die Schwachstelle ermöglichte damals den Diebstahl von Informationen, die unter normalen Bedingungen durch die SSL/TLS-Verschlüsselung geschützt gewesen wären. SSL/TLS bietet Kommunikationssicherheit und Datenschutz über das Internet für Anwendungen wie Web, E-Mail, Instant Messaging (IM) und einige virtuelle private Netze (VPN). Als Heartbleed 2015 entdeckt wurde, verwendete die Mehrheit der IT-Organisationen dedizierte Hardware oder virtuelle Maschinen. Doch jetzt befinden wir uns in der Cloud-Native-Ära, die fortschrittliche Container und serverlose Architekturen hervorgebracht hat.

Der Angriffsvektor ist viel größer geworden, und anstatt nur ihre VMs zu untersuchen, müssen sich IT-Teams darauf vorbereiten, als Reaktion auf diese Ankündigung alle ihre Container-Images zu patchen. Hoffentlich hat die Log4J-Schwachstelle viele dieser Teams dazu veranlasst, ihre Abhängigkeiten zu überprüfen. Wenn dies der Fall ist, helfen diese Schritte dabei, schnell eine gezielte Lösung für ihre Infrastruktur bereitzustellen. SBOMs (Software Bill of Materials) aller Container-Images sind ein guter Anfang, um einen Einblick in die Abhängigkeiten in den Anwendungen und der Infrastruktur zu erhalten.

Außerdem wissen IT-Teams jetzt, dass OpenSSL-Versionen vor 3.0 nicht betroffen sind und viele Betriebssysteme OpenSSL 1.1 verwenden, so dass diese Umgebungen nicht beeinträchtigt werden. Mit diesem Wissen können Cybersicherheits- und IT-Teams große Teile ihrer Infrastruktur ausschließen und hoffen, dass die Auswirkungen dieser Sicherheitslücke geringer sind als ursprünglich erwartet. Plattform-Engineering-Teams sollten jedoch weiterhin in eine bessere Überprüfung ihrer Umgebungen und ihrer Abhängigkeiten investieren, um sich auf die nächste Bedrohung vorzubereiten, die immer um die Ecke lauert.“

Wie Sie die OpenSSL 3.0.x-Schwachstelle patchen, erklärt Chris Dobrec, VP Product & Industry Solutions bei Armis. „Am Dienstag, den 1. November wird das Entwicklerteam hinter der Open Source Library OpenSSL eine kritische Schwachstelle und den dazu gehörigen Patch veröffentlichen. Seit geraumer Zeit hat es das nicht mehr gegeben. Die Entwickler erklären, dass frühere Versionen nicht betroffen sind. Während keine Details des bevorstehenden Patches oder der kritischen Schwachstelle, veröffentlicht wurden, gibt es nun einige Spekulationen, es könnte sich um eine mögliche DDoS-Schwachstelle handeln. OpenSSL 3.0.x wurde im Jahr 2021 veröffentlicht. Dieser Faktor wird hoffentlich das Ausmaß der Probleme, die am Dienstag bekannt gegeben werden, etwas einschränken, weil ältere Versionen nicht betroffen zu sein scheinen.

Ähnlich wie die im Dezember 2021 bekannt gewordene Log4j-Schwachstelle ist OpenSSL in vielen Betriebssystemen (Windows, macOS, verschiedene Linux-Distributionen usw.), clientseitigen Softwareanwendungen, Web- und E-Mail-Server-Software (Apache, nginx usw.), Netzwerkgeräten (Cisco, Fortinet, Juniper usw.) und sogar industriellen Steuerungssystemen enthalten.

Maßnahmen zur Behebung

OpenSSL bietet eine Command Line und eine schnelle Abfrage liefert die Ergebnisse der SSL-Bibliothek, die auf den Geräten läuft:

% openssl version

OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)

Die obigen Ergebnisse zeigen ein System mit einer SSL 3.x-Library, das den Patch vom Dienstag benötigt. Zusätzlich zu dieser Überprüfung müssen IT-Sicherheits- und IT-Teams möglicherweise nach nicht standardmäßigen Installationen suchen, da es möglich ist, dass auf den Systemen auch Anwendungssoftware oder Anwendungen laufen, die OpenSSL enthalten. Sie sollten auf Mitteilungen aller Software-Anbieter achten, insbesondere derjenigen, die Software oder Hardware mit Internet-Konnektivität anbieten.

IT-Sicherheits- und IT-Teams sollten sich die nötige Zeit nehmen, um die bevorstehenden OpenSSL 3.x-Schwachstellen zu identifizieren und zu beheben. Darüber hinaus sollten sie wissen, dass weitere kritische OpenSSL-Schwachstellen identifiziert wurden, die in der Zwischenzeit gepatcht werden sollten: CVE-2016-6309 und das größte OpenSSL-Problem von allen – Heartbleed, das 2014 bekannt wurde (Heartbleed ist älter als die Schweregradkriterien von OpenSSL). Heartbleed ermöglichte es Angreifern, sensible Daten aus der Ferne preiszugeben und richtete auch Jahre nach dem Ereignis noch Schaden an. Der Vorfall zeigte die Abhängigkeit des Internets von scheinbar kleinen Projekten auf, die von Freiwilligen betrieben werden. Die ganze Debatte danach brachte Forks wie LibreSSL und BoringSSL hervor, die versuchten, die komplexe Codebasis von OpenSSL zu bereinigen.“

Paul Baird, Chief Technical Security Officer (CTSO) UK bei Qualys, erklärt: „Das OpenSSL-Team definiert ein kritisches Sicherheitsupdate als eines, das gängige Konfigurationen betrifft und wahrscheinlich auch ausnutzbar ist. Beispiele hierfür sind eine signifikante Offenlegung des Inhalts des Serverspeichers (die möglicherweise Benutzerdaten preisgibt), Schwachstellen, die leicht von außerhalb ausgenutzt werden können, um die privaten Schlüssel des Servers zu kompromittieren, oder bei denen eine Codeausführung in üblichen Situationen als wahrscheinlich angesehen wird.

Es handelt sich also um ein Problem, das so gut wie jeder sofort nach der Veröffentlichung der aktualisierten Versionen von OpenSSL beheben muss. Aus Sicht der Planung und Prioritätensetzung werden viele Sicherheitsexperten ihre Zeit in der nächsten Woche damit verbringen. Die beste Vorgehensweise wäre, alle Ihre OpenSSL-Implementierungen zu kennen, zu wissen, welche Versionen sie haben, und Ihre Aktualisierungspläne entsprechend zu priorisieren. Bei so etwas ist man immer gewarnt, denn ich gehe davon aus, dass sowohl Sicherheitsexperten als auch böswillige Akteure großes Interesse an den Details eines Problems und an der Veröffentlichung eines Proof-of-Concept-Codes zeigen werden.“

Lotem Finkelstein, Director, Threat Intelligence & Research Area bei Check Point Software, ergänzt: “In einer offiziellen Erklärung vom vergangenen Dienstag kündigte das OpenSSL-Projektteam die bevorstehende Veröffentlichung der nächsten Version an, die am Dienstag, den 1. November, erscheinen wird. Es wird erwartet, dass diese Version 3.0.7 einen Fix für eine kritische Sicherheitslücke enthält. Während genaue Details der Sicherheitslücke zu diesem Zeitpunkt noch unbekannt sind, rufen wir Organisationen dazu auf, die Veröffentlichung aufmerksam zu verfolgen, ihre Systeme mit Patches zu versehen und alle Schutzmaßnahmen auf dem neuesten Stand zu halten, bis weitere Details bekannt werden.

OpenSSL ist eine weit verbreitete Code-Bibliothek, die eine sichere Kommunikation über das Internet ermöglicht. Einfach ausgedrückt: Wann immer ein Nutzer im Internet surft, eine Website besucht oder auf einen Online-Dienst zugreift, nutzt er OpenSSL auf seiner grundlegenden Ebene. Das bedeutet, dass am Dienstagmorgen alle sehr aufmerksam sein müssen, was das OpenSSL-Projektteam veröffentlichen wird. Es wird erwartet, dass es weite Bereiche unserer alltäglichen Nutzung des Internets berührt. Die kritische Sicherheitslücke in OpenSSL hat das Potenzial, die Grundlagen des verschlüsselten Internets und die Privatsphäre seiner Nutzer zu erschüttern.

Während Unternehmen auf den Patch warten, sollten sie die besten Sicherheitspraktiken anwenden, einschließlich des Patchens und Aktualisierens aller Systeme auf das neueste Betriebssystem und der Vorbereitung auf die Aktualisierung von IPS, sobald diese verfügbar sind. Wichtig ist außerdem zu wissen, wo OpenSSL überall innerhalb des Unternehmens im Einsatz ist. Eine Möglichkeit ist die Software Bill of Materials (SBOM) zu verwenden, die eine detaillierte Liste der Softwarekomponenten des Unternehmens enthält. Auf diese Weise können Sicherheitsteams die kritischen Bereiche priorisieren und sich auf den erwarteten Patch vorbereiten.“