Fehlende Upgrades: Mehr als jede dritte Anwendung mit Log4j ist angreifbar
Rund 38 Prozent aller Anwendungen, die das von der Apache Software Foundation entwickelte Logging-Framework Log4j verwenden, setzen noch auf eine veraltete Version mit bekannten Sicherheitslücken. Das geht aus einem Blogbeitrag des Software-Security-Unternehmens Veracode(öffnet im neuen Fenster) hervor, das nach eigenen Angaben über einen Zeitraum von 90 Tagen die verwendeten Log4j-Versionen von insgesamt 38.278 Applikationen von 3.866 Unternehmen untersuchte.
Zu den Sicherheitslücken, denen viele dieser Anwendungen ausgesetzt sind, zählt in einigen Fällen auch die vor zwei Jahren bekannt gewordene und als CVE-2021-44228 registrierte Log4Shell-Schwachstelle. Diese wurde mit einem CVSS von 10 mit dem maximal möglichen Schweregrad eingestuft. Sie lässt sich wohl heute noch in 2,8 Prozent aller untersuchten Applikationen ausnutzen, die eine Log4j-Version zwischen 2.0-beta9 und 2.15.0 verwenden.
Weitere 3,8 Prozent seien Veracode zufolge zwar mit Version 2.17.0 nicht anfällig für Log4Shell, dafür aber für eine andere schwerwiegende RCE-Schwachstelle, die als CVE-2021-44832 registriert ist. Mit einem Anteil von 32 Prozent setze ein Großteil der verwundbaren Anwendungen sogar noch auf Log4j 1.2.x, das schon seit August 2015 nicht mehr unterstützt werde und daher keine Patches erhalte. Daraus ergebe sich eine Anfälligkeit für insgesamt sieben schwere und kritische Schwachstellen, von denen allein drei im Januar 2022 offengelegt worden seien.
Upgrades kosten Zeit und Geld
Als möglichen Grund für die oftmals ausbleibenden Aktualisierungen nennt Veracode die Kosten und Herausforderungen, die ein Versionswechsel für Entwickler nach sich zieht. Größere Versions-Upgrades seien oftmals teuer, da es schwierig sei, die Kompatibilität mit bestehendem Code zu gewährleisten.
79 Prozent aller Entwickler würden verwendete Bibliotheken von Drittanbietern daher generell nie aktualisieren. Und wenn doch ein Upgrade durchgeführt werde, dann meist nur auf die höchste verfügbare Nebenversion, da dies weitaus weniger Änderungen am Anwendungscode erfordere als der Wechsel zu einer neuen Hauptversion.
Jedoch ist es wohl selten so, dass es den Entwicklern an Fachkompetenz mangelt, um ein Upgrade durchzuführen. Am häufigsten scheitere es laut Veracode an fehlenden Informationen darüber, wie eine anfällige Bibliothek mit ihrer Anwendung zusammenhänge, oder an fehlenden Ressourcen in Form von Zeit oder Personal.
- Anzeige Hier geht es zum Handbuch für Softwareentwickler bei Amazon Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.