Bedrohungslage Rot: Ist meine Anwendung von der kritischen log4j Schwachstelle betroffen?

Das Bundesamt für Sicherheit in der Informationstechnik hat wegen einer Schwachstelle im stark verbreiteten Java Logging-Framework log4j die IT-Bedrohungslage 4 / Rot ausgerufen. Daher schreibe ich aus aktuellem Anlass diesen Artikel, um euch eine Hilfestellung bei der Analyse zu geben.

Seit dem 12.12.2021 geht dieser Alarm durch die Presse, hier Meldungen:

Wie prüfen, ob mein System betroffen ist?

Um herauszufinden, ob ihr betroffen seid, durchsucht ihr die Dependencies bzw. verwendeten Bibliotheken in euer Software. Dabei prüft ihr, ob ihr generell log4j verwendet und wenn ja in welcher Version. Laut BSI sind die Versionen 2.0 bis 2.14.1 von log4j betroffen.

Die ältere Version 1.x ist nicht betroffen, sollte aber aus anderen Gründen nicht verwendet werden.
Ab Version 2.15.x ist der Fehler behoben, diese Version gibt es aber erst seit Dezember 2021 - daher ist die Chance sehr groß, dass man betroffen ist, wenn man log4j verwendet:
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core

Das Durchsuchen der Dependencies ist nicht trivial, da ihr in euer Build-Konfiguration nur direkte Dependencies auflistet. Viele Bibliotheken und Frameworks haben aber wiederum eigene Dependencies bzw. verwenden andere Bibliotheken, so dass diese als indirekte Dependencies Teil eures Systems sind. Zum Beispiel setzt Spring Boot mit den Starter-Bibliotheken genau auf dieses Konzept auf. Deshalb müsst ihr die Dependencies in der Tiefe analysieren.

Analyse mit Maven...

Wenn ihr Maven als Build-Tool verwendet, könnt ihr euch die Liste aller Dependencies mit diesem Befehl anzeigen lassen:
mvn dependency:list

Anschließend bekommt ihr in der Konsole eine List mit allen Dependencies, die euer Maven-Projekt verwendet, das sieht z.B. so aus:
[INFO] The following files have been resolved:
[INFO]    org.springframework.boot:spring-boot-starter:jar:2.6.1:compile -- module spring.boot.starter [auto]
[INFO]    org.springframework.boot:spring-boot:jar:2.6.1:compile -- module spring.boot [auto]
[INFO]    org.springframework.boot:spring-boot-autoconfigure:jar:2.6.1:compile -- module spring.boot.autoconfigure [auto]
[INFO]    org.springframework.boot:spring-boot-starter-logging:jar:2.6.1:compile -- module spring.boot.starter.logging [auto]
[INFO]    ch.qos.logback:logback-classic:jar:1.2.7:compile -- module logback.classic (auto)
[INFO]    ch.qos.logback:logback-core:jar:1.2.7:compile -- module logback.core (auto)
[INFO]    org.apache.logging.log4j:log4j-to-slf4j:jar:2.14.1:compile -- module org.apache.logging.slf4j [auto]
[INFO]    org.apache.logging.log4j:log4j-api:jar:2.14.1:compile -- module org.apache.logging.log4j
[INFO]    org.slf4j:jul-to-slf4j:jar:1.7.32:compile -- module jul.to.slf4j (auto)
[INFO]    jakarta.annotation:jakarta.annotation-api:jar:1.3.5:compile -- module java.annotation [auto]
...

In dieser Liste sucht ihr dann nach dem Text "log4j" und seht dann die Version, die bei euch im Einsatz ist - in meinem Log-Ausschnitt wäre das: log4j-api:jar:2.14.1

Trotz aktueller Spring Boot Version 2.6.1 ist log4j-api 2.14.1 noch in der betroffenen Version. Da Spring aber im Standard logback statt der log4j-core Bibliothek verwendet, ist das hier gezeigte System nicht betroffen - die Version werde ich aber trotzdem hochziehen.

Apache schreibt, dass sich der Fehler in der log4j-core Bibliothek befindet:
https://logging.apache.org/log4j/2.x/security.html
Spring Boot verwendet im Standard log4j-core nicht, siehe dazu:

Analyse mit Eclipse...

Die Analyse mit Eclipse funktioniert analog. Wenn ihr die pom.xml Datei öffnet, könnt ihr zur "Dependency Hierarchy" Ansicht wechseln und dort nach log4j suchen. Das sieht dann z.B. so aus:


Fazit

Wie ihr prüft, ob euer System über diese Lücke bereits angegriffen wurde und welche Quick-Fixes es gibt, habe ich hier nicht beschrieben, dazu hat das BSI weitere Infos:
https://www.heise.de/news/Roter-Alarm-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen

Wie aus allen zuvor genannten Quellen hervorgeht, die Lage ist ernst. Ich wünsche euch viel Erfolg beim Lösen des Problems.

Kommentare

Lukas hat gesagt…
Analyse mit gradle:

gradle dependencies

Und dann ebenfalls nach "log4j-core" suchen.
(Log4j-api und dergleichen werden in spring-boot verwendet, sind aber wohl nicht verwundbar)

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

Beliebte Posts aus diesem Blog

OpenID Connect mit Spring Boot 3

Authentifizierung in Web-Anwendungen mit Spring Security 6

Reaktive REST-Webservices mit Spring WebFlux