Das halbe Internet und die meisten Sicherheitsbehörden sind gerade (zurecht) in Aufruhr versetzt. Der Grund: Eine kritische Sicherheitslücke in einer weit verbreiteten Software-Bibliothek, die ohne großen Aufwand ausnutzbar ist und von der gerade viele nicht wissen, ob sie betroffen sind. Software-Anbieter sind fleißig dabei, Patches zu bauen und auszurollen. Aber was ist mit eigenentwickelter Software? Wir haben ein paar schnelle Checks und Präventivmaßnahmen zusammengetragen.
Was kann passieren
Die Sicherheitslücke ermöglicht Remote-Code-Execution und erfordert vom Angreifer nur, einen String zu übermitteln, der vom System unverändert geloggt wird. Das kann eine Chatnachricht in Minecraft, oder ein Gerätename bei Verbindung mit der iCloud sein. Das BSI spricht von einer extrem kritischen Bedrohungslage.
Die Java-Version prüfen
Als erstes sollte die Java-Version auf allen Umgebungen, also auch auf im Internet erreichbaren Test-Umgebungen, geprüft werden. Die Lücke nutzt ein eher exotisches Java-Feature, das bereits vor einiger Zeit standardmäßig deaktiviert wurde. Wenn eine aktuelle Java-Version eingesetzt wird, schließt das die Lücke zwar nicht vollständig, erschwert einem möglichen Angreifer aber das Ausführen von Schadcode (siehe Guide: How To Detect and Mitigate the Log4Shell Vulnerability).
java -version
Laut Oracle-Changelogs wurden die betreffenden Properties mit Java8u121 auf false gesetzt. Laut einem Artikel von Lunasec sollte allerdings mindestens die Version 6u211, 7u201, 8u191 oder 11.0.1 verwendet werden. Wobei Java 6 und 7 ganz unabhängig von dieser Lücke nicht mehr ohne guten Grund verwenden werden sollten.
Die Abhängigkeiten prüfen
Die log4j Versionen 2.0 <= x <= 2.14.1 sind potentiell verwundbar. Ab 2.15 ist die Lücke geschlossen. Wenn man unschlüssig ist, welche Logging-Bibliothek oder -Version im eigenen Projekt verwendet wird, lässt sich das mit Maven oder Gradle relativ einfach herausfinden:
mvn dependency:tree | grep log4j-core -B 5
gradle -q dependencyInsight --dependency log4j-core
Diese Befehle durchsuchen den gesamten Abhängigkeitsbaum nach dem verwundbaren Paket. Der Parameter -B 5
mit Maven-Beispiel sorgt dafür, dass einige Zeilen vor dem Treffer mit ausgegeben werden. Das erleichtert das Lokalisieren einer transitiven Abhängigkeit.
Sollte das Update auf eine neuere Version länger dauern oder gar nicht möglich sein, kann bei Versionen ab 2.10 der Parameter -Dlog4j2.formatMsgNoLookups=true
beim Start der Anwendung angegeben werden, um für schnelle Abhilfe zu sorgen. Andernfalls muss manuell ein Class-File aus dem Package entfernt werden (siehe Apache Mailing Liste).
Wie wir damit umgehen
Wir prüfen weiterhin unsere Systeme, wenn neue Informationen zur Lücke bekannt werden. Das gilt auch für Eigenentwicklungen, die wir selbst im Einsatz haben. Wir arbeiten sowohl intern, als auch in Kundenprojekten viel mit Spring Boot, welches standardmäßig auf logback anstatt log4j setzt und deshalb in den meisten Fällen nicht betroffen ist. Die bei Bedarf genutzte log4j-Version in Spring soll noch vor Weihnachten aktualisiert werden (siehe Spring Blog).
Log4Shell Logo von GossiTheDog
Aktualisiert um 15:30: Gradle-Beispiel und Verweis zum BSI hinzugefügt.
Aktualisiert um 16:00: Text angepasst: Ein Java-Update schließt die Lücke nicht vollständig.
Hier noch ein Hinweis von CodeShield:
Nach den Neuigkeiten zur Log4J Vulnerability, haben wir das Wochenende schnell agiert und ein kleines Werkzeug geschrieben, mit dem sich jar Dateien (also auch ohne Source Code) analysieren lassen.
Es wird geprüft, ob Class-Files betroffen sind und/oder pom.xml-Files die Library inkludieren.
Wir haben das Werkzeug Open-Source gestellt und hoffen, so einen kleinen Beitrag beim Beheben leisten zu können.
https://github.com/CodeShield-Security/Log4JShell-Bytecode-Detector
https://www.linkedin.com/posts/codeshield_the-log4jshell-vulnerability-cve-2021-44228-activity-6876154248782979072-VE0H
Wir hoffen es hilft Euch! Leite es gerne an die Verantwortlichen bei Euch weiter.
Viele Grüße,
Johannes
———————————-
Dr. Johannes Späth
CEO & Co-Founder CodeShield
Sehr schöne Zusammenfassung!
Ich selbst habe gradle dependencies in grep gepiped. Schön, dass gradle das von sich aus kann.
Für Docker fand ich syft recht hilfreich.
Vielen Dank :-)