Kritische Sicherheitslücke in OpenSSL weckt Erinnerungen an Heartbleed
November 2022 von Mattias Gees von 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.