OpenSSL-Schwachstelle
Aktuelle Kommentare zur OpenSSL-Schwachstelle
Kommentare von Check Point, Armis, Venafi und Qualys
Check Point: Unternehmen müssen jetzt patchen
Von Lotem Finkelsteen, Head of Threat Intelligence bei Check Point Software
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.
Armis: Wie Sie die OpenSSL 3.0.x-Schwachstelle patchen
Von 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.
Mehr erfahren Sie in diesem Webcast am Mittwoch
Venafi: Kritische Sicherheitslücke in OpenSSL weckt Erinnerungen an Heartbleed
Von Mattias Gees, Container Product Lead bei Venafi
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.
Qualys zur OpenSSL-Schwachstelle
Von Paul Baird, UK Chief Technical Security Officer bei Qualys
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.
