Schwachstelle in Log4j

Anmerkung: Diese Seite wird nicht weiter aktualisiert.

Updatehistorie
2021-12-28 02:25 Inhalte etwas aufgeräumt, Versionsnummern überall auf aktuellen Stand gebracht. Windows-Befehl zum Suchen von jar-Archiven eingefügt. local-log4j-vuln-scanner als erste Wahl für Suche nach anfälligen Versionen plaziert.
2021-12-22 14:41 Neue Version 1.1 der Warnmeldung des BSI verlinkt.
2021-12-18 14:48 log4j Versionen 2.0-alpha1 bis einschliesslich 2.16.0 sind anfällig für einen Denial of Service (CVE-2021-45105). log4j 1.x scheint nicht betroffen. Bitte zügig auf 2.17 updaten.
2021-12-17 11:53 Höhe des CVSS-Scores von CVE-2021-45046 zu 9.0 geändert.
2021-12-17 11:09 Version 2.15 ist immer noch anfällig für Remote Code Execution
2021-12-15 12:00 Hinweise zu potentieller Ineffektivität des NoMsgLookups-Workarounds und zu CVE-2021-45046 in log4j 2.15.0 hinzugefügt.
2021-12-15 11:52 Ausführliche Checklist von HiSolutions referenziert.
2021-12-14 13:55 Update auf log4j 2.16 hinzugefügt und Handlungsempfehlungen diesbezüglich formuliert.
2021-12-14 03:04 Links auf Liste von Royce Williams sowie auf Informationen zu CVE-2021-4104 (log4j 1.x) eingefügt. Link auf local-log4j-vuln-scanner eingefügt.
2021-12-13 17:55 BSI-Warnmeldung auf die neueste Version aktiviert.
2021-12-13 14:15 Anfälligkeit von log4j 1.x angepasst: Anfällig, wenn JMSAppender explizit aktiviert.
2021-12-13 14:04 Artikel des DFN-CERT verlinkt.
2021-12-12 20:46 BSI-Warnmeldung auf neue Version aktualisiert. Auf das GitHub-Repository vom NCSC-NL verwiesen.
2021-12-12 21:59 Spezifischere Detektion der anfälligen Java-Klasse in .jar-Dateien hinzugefügt. Workaround "Löschen der anfälligen Java-Klasse aus .jar-Dateien" aus der BSI-Warnmeldung explizit im Text erwähnt.
2021-12-12 20:49 Das BSI hat ein Update seiner Warnmeldung mit zusätzlichen Informationen und Heraufstufung auf Warnstufe "rot" veröffentlicht. Das hier verlinkte Dokument wurde aktualisiert.
2021-12-11 16:12 Dependencysuche via jdeps so angepasst, dass der Dateipfad zur betroffenen *.jar-Datei mit ausgegeben wird
2021-12-11 15:36 Anfälligkeit von log4j 1.x leicht angepasst
2021-12-11 15:07 Dependencysuche für apt-basierte Linuxdistributionen angepasst, dass nur installierte Pakete ausgegeben werden
2021-12-11 10:30 Anfälligkeit von log4j 1.x aktualisiert, Prozesssuche für Windows hinzugefügt
2021-12-10 22:00 Erste Version des Artikels
Artikel

In Apache Log4j besteht eine Sicherheitslücke, die es einem entfernten Angreifer erlaubt, beliebigen Code auszuführen. Die Lücke ist mit dem höchstmöglichen Score von 10.0 bewertet. Log4j wird von zahlreicher Java Software verwendet. Informationen zur Schwachstelle und durchführbaren Maßnahmen gibt es hier und in der BSI-Warnmeldung.

Dieses GitHub-Repository des NCSC-NL bündelt Informationen zu Erkennung von Angriffsversuchen und gesicherten Informationen von Softwareunternehmen bezüglich der Anfälligkeit ihrer Software. Achtung: Die Liste von betroffener Software ist nicht erschöpfend. Die Checkliste unten stehende Checkliste ist in jedem Fall durchzuarbeiten. Eine weitere gut gepflegte Liste findet sich bei Royce Williams.

Die Kollegen vom DFN-CERT haben einen nützlichen Artikel zu log4j formuliert.

Am 14.12.2021 wurde bekannt, dass der in der Checkliste beschriebene Workaround, der Message Lookups via JVM-Flag zu deaktiviert, für log4j-Versionen zwischen 2.10.0 und 2.14.0 unter bestimmten Umständen nicht effektiv ist. Werden in der Implementierung der Software spezielle Log Patterns verwendet, kann arbiträrer Code ausgeführt werden, obwohl der Workaround aktiv ist. Mehr Informationen gibt es im Blog von LunaSec. Ein Update auf log4j 2.17 behebt das Problem vollständig. In log4j 2.15.0 ist zumindest keine entfernte Codeausführung (RCE) möglich hat nur einen unvollständig implementierten Check für externe Hosts, der einen RCE nicht komplett verhindert, für einen hiermit durchführbaren Denial-of-Service-Angriff wurde eine neue Schwachstellennummer vergeben (CVE-2021-45046). Der CVSS Score wurde zwischenzeitlich auf 9.0 angehoben.

Update 18.12.2021: log4j Versionen 2.0-alpha1 bis einschliesslich 2.16.0 sind anfällig für einen Denial of Service (CVE-2021-45105), für Details siehe die Meldung bei Apache und diesen Artikel bei Threadpost. log4j 1.x scheint nicht betroffen.

In Anbetracht des hohen Schadenspotential der log4j-Lücke (CVE-2021-44228) bitte zeitnah folgende Checkliste abarbeiten. Es gibt außerdem seit dem 15.12.2021 eine noch ausführlichere Checkliste formuliert von der Firma HiSolutions.

1. Betreibe ich irgendwelche Dienste/Software die direkt oder indirekt von Dritten erreichbar ist?

Wenn ja:

2. Kommt dort Java-Software zum Einsatz? Evtl auch nur als Teilkomponente?

Wenn nicht sicher:

  • Nach Prozessen suchen die "java" im Namen haben [0]
  • Nach Dateien suchen die auf .jar enden
  • Für Debian / Ubuntu: Abhängigkeiten auf log4j finden die mit dem Paketsystem installiert wurden [1] 

Wenn ja:

3. Benutzt meine Java-Software log4j?

Wenn nicht sicher:

Wenn ja: Welcher Versionen werden verwendet?

4. Wenn (potentiell) betroffen:

  • Überprüfen, ob es Hinweise auf Ausnutzung gibt [4]
  • Log4j in der Software auf eine Version >= 2.17 aktualisieren oder bei Entwicklungsfirmen von Fremdsoftware nach Patches erkundigen
    • log4j 2.15.0 behebt zwar die triviale Ausnutzbarkeit der Schwachstelle, log4j 2.17 führt weitere, sehr sinnvolle Absicherungen ein
      • Vollständige Entfernung von Message Lookups (Interpretation von speziellen Zeichenfolgen im Logtext)
      • JNDI-Lookups standardmäßig deaktiviert. In log4j 2.15.0 ist dies nicht der Fall, wodurch weitere Schwachstellen durch fehlende Eingabevalidierung denkbar sind [5]
    • Selbstentwicklungen: Aktualisieren Sie log4j auf Version 2.17 und belassen Sie JNDI-Lookups entsprechend der Standardkonfiguration deaktiviert.
    • Fremdentwicklungen: Pochen Sie bei den Entwicklungsfirmen darauf, dass auf log4j 2.17 aktualisiert wird und die JDNI-Lookups deaktiviert bleiben.
  • Überlegen, ob die Software bis zur Verfügbarkeit eines Patches abgeschalten oder zugangsbeschränkt werden sollte
  • Update 2021-12-15: Dieser Workaround ist unter Umständen, wie im Eingangstext beschrieben, nicht effektiv. Unbedingt mit den Entwicklungsfirmen abklären, ob ein potentiell eingesetzter Workaround weiterhin effektiv ist und eigene Software auf log4j 2.17 updaten. Es gibt einen Workaround, der das Ausnutzen der Sicherheitslücke verhindert. Dieser ist im Blogpost von Lunasec und in der BSI-Warnmeldung beschrieben. Leider funktioniert der Workaround nur für log4j-Versionen >= 2.10.0.
  • Es gibt einen Workaround, der den anfälligen Code aus jar-Dateien entfernt, beschrieben in der BSI-Warnmeldung. Achtung: Dies kann die erfolgreiche Ausführung von Software verhindern. Dieser Workaround funktioniert für alle 2.x Versionen von log4j.

Fußnoten:

  • [0] z.B.
    • unter Linux via ps aux | grep java
    • unter Windows via 
      • tasklist /NH | findstr /I  java
      • tasklist /NH | findstr /I  jar
  • [1] apt-cache rdepends --installed liblog4j2-java
  • [2] Finden von Abhängigkeiten in .jar Dateien über jdeps (ggf. Pfad / anpassen). Leider ist dies wegen uber-jars nur eine Näherung.
    • Linux/macOS: find / -type f \( -iname \*.jar -o -iname \*.war \) -print0 | xargs -0 -I {} sh -c 'jdeps {} | grep log4j && echo ^ The hit above is in {} && echo'
    • Windows: Get-ChildItem -recurse -Attributes Compressed,Hidden,Normal -include ('*.jar', '*.war') | Select-String -pattern "log4j|jndilookup" -List | Select Path
  • [3] Finden der anfälligen Klasse JndiLookup.class in .jar Dateien via jar. Leider ist dies wegen uber-jars nur eine Näherung.
    • Linux/macOS: find / -type f \( -iname \*.jar -o -iname \*.war \) -print0 | xargs -0 -I {} sh -c 'jar tf {} | grep -i jndilookup && echo ^ The hit above is in {} && echo'
  • [4] https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
  • [5] https://issues.apache.org/jira/browse/LOG4J2-3221