Zwei Jahre nach Log4Shell: Die Gefahr ist nicht gebannt – Was ist zu tun?

Vor zwei Jahren wurde eine der kritischsten Zero-Day-Schwachstellen aller Zeiten bekannt: Log4Shell. Die Schwachstelle mit dem höchstmöglichen Schweregrad (10.0) befand sich in Apache Log4j, einem allgegenwärtigen Open-Source Java-Protokollierungs-Framework. Nach Schätzungen von Veracode haben damals 88 Prozent der Unternehmen Apache Log4j eingesetzt.

Angreifer konnten die Schwachstelle (CVE-2021-44228) in den Log4j-Versionen Log4j2 2.0-beta9 bis 2.15.0 (mit Ausnahme der Sicherheitsversionen 2.12.2, 2.12.3 und 2.3.1) ausnutzen, um RCE-Angriffe (Remote Code Execution) durchzuführen. Schätzungsweise Hunderte von Millionen an betroffenen Systemen mussten gepatcht werden – ein riesiger Aufwand.

Zum zweijährigen Jubiläum hat Veracode den Stand der Log4Shell-Schwachstellen erneut untersucht, um zu sehen, ob es Fortschritte in der Open-Source-Software-Sicherheit gibt. Die Ergebnisse zeigen, dass das Risiko zur Ausnutzung der Schwachstelle deutlich reduziert wurde. Allerdings enthalten 38 Prozent der Anwendungen in Unternehmen immer noch anfällige Versionen von Log4j.

Dabei fehlt es selten an den Fähigkeiten, die Mängel zu korrigieren. Viele Unternehmen scheinen sich vielmehr nicht bewusst zu sein, welchen Open-Source-Risiken sie ausgesetzt sind und wie sie diese reduzieren können. Oft mangelt es an Informationen und/oder an Ressourcen. Log4j ist nur ein Beispiel dafür, welche Risiken sich in Open Source Code verbergen können. Deswegen benötigen Entwickler Sicherheits-Richtlinien und Tools, um Sicherheitslücken einfacher zu finden, zu bekämpfen und um ihre eigene Arbeitslast zu verringern.

Mit SCA (Software Composition Analysis) und Infrastructure as Code-Scanning können Verantwortliche zulässige Open-Source-Module festlegen, die Entwickler verwenden dürfen. Außerdem sind Richtlinien hilfreich, die Open-Source-Schwachstellen nach Schweregrad und/oder "Breaking the Build" verbieten. So dürfen Entwickler keine Änderungen einführen, die neue Schwachstellen (im eigenen oder fremden Code) mit sich bringen.

Auch wenn Organisationen Software kaufen, sollten sie immer wissen, was in ihr enthalten ist. Dafür sind SBOMs (Software Bill of Materials) für die installierte Software von Drittanbietern nützlich. So ist es möglich, Schwachstellen schnell zu erkennen und zu beheben, bevor ernsthafte Probleme entstehen.