Die Entwickler sind dabei, das Java-Logging gegen weitere Angriffe zu härten. Eine neue Version des Tools Log4j verhindert den Angriff, während sich der Schutz durch bestimmte Java-Versionen oder –Einstellungen als unsicher und löchrig erwiesen hat.
Die neue Version Log4j 2.16.0 verhindert Angriffe
Nach der am 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 jetzt funktionieren Angriffe damit unabhängig von der Java-Version und bestimmten Java-Sicherheitseinstellungen.
Verlässlichen Schutz bietet also nur ein 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 dem Zweck deaktivieren die Entwickler das Java Naming and Directory Interface (JNDI) jetzt komplett. Die Benutzer könnten ihn manuell wieder einschalten, allerdings stelle er in ungeschützten Umgebungen ein hohes Sicherheitsrisiko dar, warnen die Apache-Entwickler in der Log4j-Versionsankündigung davor.
Java-Versions-Roulette bringt keine Sicherheit
Zunächst las man ja am vergangenen Freitag in der ersten Fassung der Apache-Sicherheitsmeldung zur Lücke einen Hinweis auf eine bestimmte Java-Version, die Angriffe verhindern sollte. Dieser Hinweis wurde kurz darauf aber wieder entfernt. Es hat sich inzwischen gezeigt, dass keine Java-Version verlässlich vor einem Angriff schützen kann.
So hat 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 dem 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.
Nur ein schneller Update auf Log4j 2.16.0 schützt vor Angriffen
Almeida weist auch darauf hin, dass ausschließlich das möglichst schnelle Update von Log4j gegen das Ausnutzen der Sicherheitslücke Log4Shell helfe. Allerdings liegen bisher noch keine gesicherten Erkenntnisse zu eventuellen Nebenwirkungen dieses Updates vor.
