„OpenSSL bietet eine Command Line“, so Dobrec, „und eine schnelle Abfrage liefert die Ergebnisse der SSL-Bibliothek, die auf den Geräten läuft“: Bringt zum Beispiel die Abfrage „% openssl version“ das Ergebnis „OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)“, dann handelt es sich um 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“, so Dobrec weiter, „da es möglich ist, dass auf den Systemen auch Anwendungssoftware oder Anwendungen laufen, die OpenSSL enthalten.“ IT-Teams sollten laut dem Armis-Experten auf Mitteilungen aller Softwareanbieter achten, insbesondere derjenigen, die Software oder Hardware mit Internet-Konnektivität anbieten.
IT-Sicherheits- und IT-Teams sollten sich laut Dobrec die Zeit nehmen, um die 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.“
„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“, bestätigt Mattias Gees, Container Product Lead beim OT-Security-Spezialisten Venafi. Heartbleed hatte erhebliche Auswirkungen auf alle IT-Teams weltweit – und seither, so Gees, sei die IT-Infrastruktur zehnmal komplizierter geworden.
Die Schwachstelle ermöglichte damals den Diebstahl von Informationen, die eigentlich durch die SSL/TLS-Verschlüsselung geschützt gewesen wären. Das Protokoll Transport Layer Security (TLS), vormals bekannt als Secure Sockets Layer (SSL), dient der Kommunikationssicherheit und dem Datenschutz bei Datenübermittlungen per Internet für Anwendungen wie Web, E-Mail, Instant Messaging (IM) und einige VPNs.
„Als Heartbleed 2015 entdeckt wurde, verwendete die Mehrheit der IT-Organisationen dedizierte Hardware oder virtuelle Maschinen“, führt Gees aus. „Doch jetzt befinden wir uns in der Cloud-Native-Ära, die fortschrittliche Container und Serverless-Architekturen hervorgebracht hat.“
Die Angriffsfläche ist dadurch stark gewachsen. „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“, erläutert Venafi-Fachmann Gees.
Er hofft, die Log4j-Schwachstelle Ende 2021 habe viele IT-Teams dazu veranlasst, ihre Software-Abhängigkeiten zu überprüfen. „Wenn dies der Fall ist, helfen diese Schritte dabei, schnell eine gezielte Lösung für ihre Infrastruktur bereitzustellen“, sagt Gees. SBOMs (Software Bills of Materials, also Software-Stücklisten) aller Container-Images seien ein guter Anfang, um einen Einblick in die Abhängigkeiten in den Applikationen und der Infrastruktur zu erhalten.
Eine Vielzahl von Betriebssystemen verwendet laut dem Venafi-Experten immer noch OpenSSL 1.1, sodass die neu entdeckte Schwachstelle diese Umgebungen nicht beeinträchtige. „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“, so Gees. „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.“
„Der derzeitige Mangel an Transparenz komplexer Cloud-Umgebungen lässt Unternehmen gefährlich offen für Angriffe“, warnt Kevin Bocek, VP of Security Strategy & Threat Intelligence bei Venafi. „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.“