München, den 13.12.2021. „Die Apache Log4j Zero-Day-Sicherheitslücke ist wahrscheinlich die kritischste Sicherheitslücke, die wir in diesem Jahr gesehen haben. Log4j2 ist eine Bibliothek, die von Millionen von Java-Anwendungen zur Protokollierung von Fehlermeldungen verwendet wird. Diese Sicherheitslücke lässt sich leicht ausnutzen. Angriffe finden bereits statt, und wir haben gesehen, dass PoC-Exploits in den öffentlichen Bereichen wie Twitter, GitHub usw. veröffentlicht wurden. 
Das Qualys-Forschungsteam beschäftigt sich aktiv mit dieser Sicherheitslücke. Es geht davon aus, dass viele Anbieter in den kommenden Wochen Sicherheitshinweise für ihre Angebote im Zusammenhang mit dieser Schwachstelle veröffentlichen werden. Qualys empfiehlt den Anwendern, ihre Anwendungen auf den neuesten Build für Log4j zu aktualisieren oder dringend Abhilfemaßnahmen zu ergreifen,“ so Bharat Jogi, Sr. Manager, Vulnerabilities and Signatures, Qualys.
Ein Exploit für eine kritische Zero-Day-Schwachstelle in Apache Log4j2, bekannt als Log4Shell, wurde am 9. Dezember 2021 bekannt gegeben. Alle Versionen von Log4j2 Versionen >= 2.0-beta9 und <= 2.14.1 sind von dieser Sicherheitslücke betroffen. Diese Sicherheitslücke wird aktiv „in the wild“ ausgenutzt.“
Log4j2 ist eine allgegenwärtige Bibliothek, die von Millionen von Menschen für Java-Anwendungen genutzt wird. Die Bibliothek ist Teil des Apache Logging Services-Projekts der Apache Software Foundation.
Wenn die Schwachstelle ausgenutzt wird, führt sie zur Remote Code-Ausführung auf dem verwundbaren Server mit Rechten auf Systemebene. Die Schwachstelle wird mit einem CVSS v3 Score von 10.0 bewertet.
Apache Log4j2 Version 2.15.0 behebt diese Sicherheitslücke. Wenn eine Aktualisierung der Version nicht möglich ist, kann die folgende Abhilfemaßnahme angewendet werden:
In Log4j-Versionen (>=2.10) kann dieses Verhalten durch Setzen der Systemeigenschaft „log4j2.formatMsgNoLookups“ auf „true“ oder durch Entfernen der Klasse JndiLookup aus dem Klassenpfad abgeschwächt werden.
Wenn der Server über Java-Laufzeiten später als 8u121 verfügt, ist er gegen Remotecodeausführung geschützt, indem „com.sun.jndi.rmi.object.trustURLCodebase“ und „com.sun.jndi.cosnaming.object.trustURLCodebase“ auf „false“ gesetzt werden (siehe https://www.oracle.com/java/technologies/javase/8u121-relnotes.html).
Weitere Informationen erhalten Sie hier hier auf dem Qualys Blog, der kontinuierlich upgedated wird.