„Die Apache-Log4j Zero-Day-Sicherheitslücke ist wahrscheinlich die kritischste Sicherheitslücke, die wir in diesem Jahr gesehen haben“, befürchtet Qualys . „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 arbeitet aktiv an 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 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 Remote-Codeausfü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 zu dieser schwerwiegenden Schwachstelle finden sich hier auf dem Qualys-Blog, der täglich upgedated wird.
#Qualys
