Log4j – Write Once, Run Everywhere

Disclaimer: Unsere Services sind von diesem Exploit NICHT betroffen. Wir berichten hier nur über den weltweiten Vorfall. Bei Ungewissheit stehen wir Ihnen gerne zur Seite.

Einleitung

Worüber schon oft Witze gemacht wurden, hat am 10. Dezember 2021 zum Verhängnis geführt – Eine kritische Zero-Day-Lücke in Log4j (ein Logging Framework für Java) gefährdet zahlreiche Server und Apps. Über eine Sicherheitslücke namens Log4Shell in der Java-Logging-Library Log4j können Angreifer Schadcode auf dem betroffenen Server ausführen lassen.

Der Exploit kann ausgenutzt werden, indem manipulierte Anfragen an einen Server oder eine Anwendung geschickt werden, welche(r) eine verwundbare Log4j Version einsetzt (<= v2.14.0). Der PoC (Proof-of-Concept) Code von der Pentesting-Gruppe 0x0021h zeigt, dass der Angreifer eine Zeichenkette der Form ${jndi:ldap://127.0.0.1:1389/a} ins Protokoll schreibt. JNDI als Verzeichnisdienst kontaktiert den LDAP-Server 127.0.0.1:1389 und nimmt die Daten wie potenziell bösartigen Code entgegen und führt diese aus. Ein Angreifer müsste demnach einen von ihm kontrollierten LDAP-Server angeben, um einen Server über das Logging zu kapern (Log4Shell).

verwundbare Komponenten

Für diese Zero-Day-Sicherheitslücke wurde bereits die CVE Nummer CVE-2021-44228, Risiko kritisch, CVSSv3 10/10) vergeben. Log4j ist ein standardisiertes Logging-Framework, welches sich durch zahlreiche und weit verbreitete Systeme zieht. Der französische Cybersecurity Engineer “SwitHak” hat auf GitHub eine Liste von betroffener Software zusammengestellt, darunter auch sehr weit verbreitete Software-Lösungen wie vmWare, Apache Solr, Amazon Web Services, Steam, Cloudflare, CPanel (setzen wir – dream-soft – glücklicherweise nicht ein), Docker und unzählig weitere Anwendungen.

verwundbare Java Bibliothek

Betroffen ist Log4J von Version v2.0-beta9 bis zur Version v2.14.1.

Die Apache Foundation hat kurzfristig die Version 2.15.0 veröffentlicht, die die Lücke (vorerst) schließt. In einer Sicherheitsmeldung listen die Apache-Entwickler zudem Maßnahmen auf, wie man die Server ohne Update vorläufig sichern kann. Bei Log4j ab v2.10 hilft das Setzen der Systemeigenschaft “log4j2.formatMsgNoLookups” auf “true” oder das Entfernen der JndiLookup-Klasse etwa mit dem Befehl zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

ursprünglicher Log4j-Patch nicht ausreichend!

Version 2.15.0 von Log4j sollte die Log4Shell-Sicherheitslücke schließen. Das reichte jedoch nicht aus. Log4j 2.16.0 behebt nun noch eine weitere Schwachstelle.

Die Apache-Entwickler haben in Version 2.16.0 von Log4j eine weitere Sicherheitslücke geschlossen, die nach dem ersten Versuch der Fehlerbehebung der Log4Shell-Schwachstelle in der 2.15.0er-Fassung offen stand. Der Patch war unvollständig, sodass bei bestimmten Logging-Optionen Angreifer die Software durch eine DoS-Lücke hätten lahmlegen können.

(Quelle: Heise)

Disclaimer: Unsere Services sind von diesem Exploit NICHT betroffen. Wir berichten hier nur über den weltweiten Vorfall. Bei Ungewissheit stehen wir Ihnen gerne zur Seite.

Über den Autor

Fabio ist der kreative Kopf des Unternehmens. Als Webentwickler und DevOps Spezialist bedient er neben dem Management die Optimierung bestehender Prozesse digital aufgestellter Unternehmen (Agenturen und Unternehmen mit eigener Infrastruktur). Seit 2017 ist Fabio bei dream-soft und betreut außerdem zusammen mit dem Team unsere technische Infrastruktur am Standort Frankfurt am Main im Herzen Hessens.

Comments are closed.