Schwachstelle in Log4j

Anmerkung: Diese Seite wird nicht weiter aktualisiert.

Updatehistorie

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:

• Mit local-log4j-vuln-scanner nach bekannten betroffenen Versionen von log4j suchen. Hier gibt's fertig gebaute Binaries für Linux, Windows und macOS.
• Alle Java-Pakete nach entsprechenden Abhängigkeiten durchsuchen: [2]
• Alle Java-Pakete nach der JNDILogger-Klasse (der anfällige Code) durchsuchen: [3].
• In Zweifel davon ausgehen dass log4j genutzt wird.

Wenn ja: Welcher Versionen werden verwendet?

• Betroffen sind nach aktuellem Stand die Versionen 2.0 bis 2.16.
• Laut diesem Kommentar auf GitHub zur Sicherheitslücke und diesem Tweet vom Entwickler von Log4j 1.x ist Log4j 1.x in der Standardkonfiguration nicht betroffen. Ist der JMS-Appender entgegen der Standardkonfiguration explizit aktiviert, kann die Schwachstelle ausgenutzt werden (CVE-2021-4104; siehe Apache, RedHat, snyk). Die Versionen 1.x sind End of Life und sollten sowieso nicht mehr verwendet werden! (End-of-Life Announcement)

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