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).

Die Schwachstelle kann in vielen Fällen auch durch nicht-authentifizierte Verbindungen externer Clients ausgelöst werden, etwa durch:

• Eingaben in Formularen oder Suchfeldern
• User-Agent-Header in http-Requests
• Inhalte von Chat-Nachrichten
• Hostnamen, die durch Reverse-DNS festgestellt werden

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.

Beispiele für populäre betroffene Anwendungen, die als verwundbar genannt werden (siehe auch Weblinks weiter unten):

• 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-Version achten

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/

Mitre CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker-controlled LDAP and other JNDI related endpoints:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Mitre CVE-2021-45105: Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105

Zusammenfassung und Überblick von cert.at:
https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek
https://cert.at/de/spezielles/2021/12/special-report-empfehlungen-zu-log4shell

Wikipedia-Eintrag (besonders geeignet, um die Schwachstelle für ein nicht-technisches Publikum zu benennen und zu verdeutlichen, daß es sich um ein globales Problem handet)
Deutsch: https://de.wikipedia.org/wiki/Log4j#Sicherheitsl%C3%BCckenfund_im_Dezember_2021
Englisch: https://en.wikipedia.org/wiki/Log4j#Log4Shell_vulnerability

Ausführliche Beschreibung der Schwachstelle und wie sie ausgenutzt wird:
Fastly: https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
Cado: https://www.cadosecurity.com/analysis-of-initial-in-the-wild-attacks-exploiting-log4shell-log4j-cve-2021-44228/

Verzeichnisse betroffener Software:

• Niederländisches nationales CERT (NCSC-NL):
  https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
• SwitHak:
  https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
• Softcat:
  https://www.softcat.com/apache-vulnerability
  

Kurzer Post darüber, inwieweit Log4j 1 betroffen sein kann:
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126

Pattern, mit denen nach Angriffen in Logfiles gesucht werden kann:
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Ein ACOnet-Teilnehmer hat gute Erfahrungen mit dieser Blockliste gemacht:
https://github.com/hackinghippo/j4shell_ioc_ips
Anmerkung: Es ist wohl angebracht, weniger hilfreiche Einträge wie RFC-1918-Adressen mit z. B. grep -ve '^\(0\.0\.0\|1\.1\.1\|10\|172\|192\)\.' zu entfernen und eventuell TOR-Exit-Nodes auszunehmen.

Allgemeine Info- und Überblickseiten:

• Tech Solvency: Log4Shell log4j vulnerability (CVE-2021-44228 / CVE-2021-45046) - cheat-sheet reference guide  (sehr konzis, umfassend, viele nützliche Links)
  https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
• USA / Cybersecurity and Infrastructure Security Agency: Apache Log4j Vulnerability Guidance
  https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

News, anlassbezogen:

• ZDNet: Second Log4j vulnerability discovered, patch already released:
  https://www.zdnet.com/article/second-log4j-vulnerability-found-apache-log4j-2-16-0-released/
• Bericht über die früheste bekannte Sichtung (1. Dezember)

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.