...

Inhalt

Intro

Viele Java-Anwendungen setzen zum Logging Log4j 2 ein. Bestimmte Log-Inhalte können dazu führen, dass Log4j 2 von einem beliebigen Server Code lädt und ausführt (Remote Code Execution).

...

sofern diese Informationen mit Log4j geloggt werden.

Impact

Diese Schwachstelle kann durch jede Art von externem Input ausgelöst werden, wenn dieser über eine verwundbare Log4j-Instanz geloggt wird. Das kann dazu führen, dass auch Server, die nicht direkt aus dem Internet erreichbar sind, angegriffen werden, wenn zum Beispiel Anfragen an Server im Backend weitergereicht und dann geloggt werden. Die Angriffsfläche ist daher als sehr groß einzuschätzen, die möglichen Angriffsvektoren als extrem vielfältig.

Wer/was ist betroffen?

• Java-Anwendungen und unter Umständen Anwendungen, die Java-Anwendungen aufrufen,
• wenn fremdbestimmte Daten geloggt werden.
• Das angegriffene Service und die Stelle, wo der Exploit wirksam wird, können auf unterschiedlichen Servern laufen (z.B. Web-Frontend vs. Backend-Datenbank).
• Diese Schwachstelle betrifft Log4j mit Versionsnummern vor 2.17.0.

• Log4j 1 ist nach aktuellem Wissensstand nur in besonderen Konfigurationen betroffen.

• Für Anwendungen, die die lokale JRE verwenden, ist deren Log4j-Version ausschlaggebend.
• Java-Anwendungen, die ihre eigene JRE mitbringen, bringen auch ihre eigene Log4j-Version mit.
• eigene JRE mitbringen, bringen auch ihre eigene Log4j-Version mit.

...

• Solr
• Confluence, Jira Servicedesk
• Elasticsearch?
• Hadoop
• Kafka
• Spark
• Struts (das allerdings auch andere Probleme hat)
  

Was ist zu tun?

Tests, Diagnose

• Um auf einem Server nach verwundbaren Versionen zu suchen, hat Logpresso ein Tool zur Verfügung gestellt: https://github.com/logpresso/CVE-2021-44228-Scanner
• Ein Scan oder Test über das Netzwerk ist nützlich, um unbekannt verwundbare Systeme in einem Netz zu entdecken. Da aber nur einen Teil der möglichen Szenarien getestet werden kann, sollte das nicht für ein "Gesundtesten" benutzt werden.
  
  • Scanner von FullHunt: https://github.com/fullhunt/log4j-scan
  • Huntress Log4Shell Vulnerability Tester (benötigt etwa Burp oder anders erstellte Aufrufe): https://log4shell.huntress.com
  • Wenn ein Scanner eingesetzt werden soll, dann immer prüfen, ob dieser aus einer vertrauenswürdigen Quelle stammt und nicht verfälscht wurde.
• Angriffe können in Logfiles mit Hilfe von https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b.xxx 7d15db6e3860b gesucht werden. Achtung: Sofern die durchsuchten Logs mit Log4j erstellt wurden (im Gegensatz etwa zu Apache-Logs via syslog oder eigenem Logging), ist damit zu rechnen, dass erfolgreiche Angriffe nicht im Log zu sehen sind, da der Angriffsstring interpretiert statt geloggt wurde.
  Ein Beispiel, wie Angriffe im Logfile aussehen können, ist im Special Report von CERT.at unter Live-Artefakte zu finden.
• Als ACOnet-CERT erhalten wir von externen Researchern Hinweise auf verwundbare Systeme, die wir natürlich an die Security-Kontakte weiterleiten. Naturgemäß können wir diese Scans weder wiederholen noch detaillierte Auskünfte darüber erteilen.

Lösung

• Die einzige als sicher angesehene (per 18. Dezember 2021) Lösung ist ein Upgrade auf Log4j 2.17.0 oder höher. Dazu ist Java 8 erforderlich.

  • Lokale JRE: upgrade (relativ) leicht auf Maschinenebene lösbar
  • Anwendungen mit eigener JRE: Upgrade durch Hersteller / Distributor / Upstream
  • Bei Eigenentwicklungen:
    • Aktuell verteilte Versionen prüfen
    • Im Deployment auf aktuelle Log4j-Versionachten

Mitigierende Massnahmen

• Java Virtual Machine (JVM) Flag: -Dlog4j2.formatMsgNoLookups=true setzen – funktioniert nur ab 2.10.0
• JndiLookup class aus dem classpath entfernen für Versionen vor 2.16.0:
  • Einige Hersteller publizieren Anleitungen dazu
  • Manuelles Entfernen aus dem .jar-File, z.B mit zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    Siehe auch: https://github.com/zhangyoufu/log4j2-without-jndi/blob/master/README_en.md
    Dieser Workaround kann allerdings zu Fehlern in der Applikation führen, entsprechende Tests sind daher notwendig.
    
  • Danach ist die Applikation neu zu starten.
• Der früher angeratene Weg,PatternLayout patterns auf%m{nolookups}zu setzen, wird von lunasec nicht mehr empfohlen
  
• Serverseitig outgoing connections blocken
• Einsatz von NG-Firewalls, WAFs etc., um die typischen Exploit-Strings auszufiltern. Dies kann naturgemäß nur bei nicht verschlüsseltem Traffic funktionieren (also in der Regel bei TLS-Offloading)
• Einsatz von Reputation-Lists in z. B. NG-Firewalls, um die Chancen zu reduzieren, dass ein Angriff funktioniert
• Ggf. Applikation offline nehmen oder wenigstens stark abschotten (VPN)

Weblinks

Original-Webseite von lunasec, die die Schwachstelle entdeckt haben:
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/

...

Weitere Themen, Fragen

• Nicht nur Server, auch lokal auf Endgeräten installierte Applikationen können betroffen sein. Hier erscheinen beispielsweise Chat-Programme potentiell gefährdet, da sie mit vielen anderen Quellen Daten austauschen.
• Noch eher wenig ist über die Möglichkeit bekannt, ob auch Netzwerkkomponenten von der Schwachstelle betroffen sein könnten – etwa wenn sie reverse-lookup im DNS machen.
• Auch NAS-Server, die oft in Heimnetzen verwendet werden, kommen als Ziel von Angriffen in Betracht.
• Die initial publizierten Angriffsmuster nutzen LDAP. Es gibt widersprüchliche Informationen darüber, ob oder zu welchem Grad die Schwachstelle auch mit anderen Protokollen ausgenutzt werden kann. Spezifisch LDAP-Zugriffe, etwa an der Firewall, zu blockieren, erscheint demnach wenig effektiv.
  

...