Die Entwickler sind seit dem Wochenende fleißig dabei, das Java-Logging mit Log4j gegen weitere Angriffe zu härten. Eine ganz aktuelle, neue Version des Tools Log4j verhindert den Angriff, während sich der Schutz durch bestimmte Java-Versionen oder deren Einstellungen leider als unsicher und löchrig erwiesen hat.

Die neue Version Log4j 2.16.0 verhindert Angriffe

Nach der am letzten Freitag hastig veröffentlichten Version 2.15.0 zum Schließen der Log4Shell-Sicherheitslücke haben die Apache-Entwickler jetzt Log4j 2.16.0 fertiggestellt und die Schutzmaßnahmen darin verbessert.

Andere Java-Versionen helfen nicht wirklich

Andererseits haben Sicherheitsforscher inzwischen den Proof-of-Concept-Code (PoC) zum Ausnutzen der Schwachstelle verfeinert – und damit funktionieren die Angriffe leider auch unabhängig von der Java-Version und von bestimmten Java-Sicherheitseinstellungen.

Sicherer Schutz nur durch Update der Log4j-Bibliothek

In der neuen Version von Log4j 2.16.0 haben die Apache-Programmierer den Code entfernt, der die Nachrichten in den Logs mit den fatalen URL-Einträgen zu potenziell bösartigen LDAP-Servern analysiert.

Zu diesem Zweck deaktivieren die Entwickler das Java Naming and Directory Interface (JNDI) komplett. Die Benutzer könnten ihn zwar manuell wieder einschalten, allerdings stelle er in ungeschützten Umgebungen ein massives Sicherheitsrisiko dar, warnen die Apache-Entwickler in der Log4j-Versionsankündigung davor.

Keine Sicherheit durch Java-Versions-Roulette

Zunächst las man ja am Freitag in der ersten Fassung der Apache-Sicherheitsmeldung zu der Sicherheitslücke einen Hinweis auf eine bestimmte Java-Version, die angeblich Angriffe verhindern sollte. Dieser Hinweis wurde aber kurz darauf wieder entfernt. Es hat sich nämlich inzwischen gezeigt, dass keine Java-Version verlässlich vor einem Angriff schützen kann…

So hat beispielsweise der Sicherheitsforscher Márcio Almeida ein Exploit-Kit (siehe Artikelbild) zum Ausnutzen der Log4Shell-Schwachstelle so angepasst, dass es mit jeder Java-Version funktioniert und auch zum Beispiel die Einstellung  trustURLCodebase=false nicht dagegen hilft.

Zu diesem Zweck hat er die bösartigen Daten, also den Schadcode selbst, einfach per Serialization in ein anderes Format umgepackt. Die einzige Bedingung dabei sei, dass die vom eingeschleusten serialisierten Code genutzten Klassen im Klassenpfad der angegriffenen Anwendung stehen müssten, ergänzt Almeida.

Nur ein schneller Update auf Log4j 2.16.0 schützt vor Angriffen

Der Sicherheitsforscher weist auch darauf hin, dass nur das möglichst schnelle Update von Log4j gegen das Ausnutzen der Sicherheitslücke Log4Shell helfe. Allerdings liegen bisher noch keine gesicherten Erkenntnisse zu eventuell möglichen Nebenwirkungen dieses Updates vor.