Log4j Schwachstelle: Was ist jetzt zu tun?

Die Log4j-Schwachstelle (CVE-2021-44228) hat viel Aufmerksamkeit erhalten. Wir zeigen auf, wie Sie sich schützen können.

Log4J sorgt für Aufmerksamkeit und Wirbel

Sicher haben Sie schon aus unterschiedlichsten Quellen von der log4j Schwachstelle gehört. Sie wird unter CVE-2021-44228 geführt und hat in den letzten Tagen viel Aufmerksamkeit erhalten. Manch Beobachter spricht von der „größten einzelnen Schwachstelle in der Geschichte des modernen Computing“. Ob es wirklich soweit kommt, werden die kommenden Wochen und Monate zeigen. Aktuell möchten wir Ihnen – unseren Blog-Lesern und Kunden – einige Informationen an die Hand geben, wie Sie sich kurzfristig vorgehen und schützen können.

Worum geht es?

Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen. Sie wird z.B. für eine schnelle Aggregation von Logdaten einer Applikation genutzt. Es wurde eine Schwachstelle in den log4j Versionen 2.0 bis 2.14.1 gefunden, die es Angreifern ermöglicht, auf einem Zielsystem eingeschleusten Code auszuführen (Remote Code Execution). Die Schwachstelle kann dann ausgenutzt werden, wenn es dem Angreifer gelingt eine modifizierte Zeichenkette, z.B. über den HTTP User Agenten, in eine von log4j verwaltete Protokolldatei zu schreiben. Die offizielle CVE-ID dieser Schwachstelle ist CVE-2021-44228

Wie stelle ich fest ob meine Systeme betroffen sind?

Um festzustellen, ob eines Ihrer Systeme oder Applikation betroffen ist, kann geprüft werden, ob dort log4j in einer der betroffenen Versionen eingesetzt wird. Da dies unter Umständen ein langwieriger, manueller Prozess ist, gibt es auch die Möglichkeit einen Scan der Infrastruktur durchzuführen. Dabei wird ein speziell generierter Test eines Schwachstellenscanners ausgeführt und anhand der Ergebnisse kann eine Aussage getroffen werden, ob die Schwachstelle vorliegt oder nicht. Unser Technologiepartner Holm Security stellt für uns die notwendigen Tests zur Verfügung. Ein solcher Scan ist schnell vorbereitet und ein Bericht wird nach Beendigung automatisch erstellt. Grundsätzlich muss man jedoch auch festhalten, dass die Durchführung eines geeigneten Schwachstellenscans nichts ausschließt, dass die Schwachstelle ggf. schon in der jüngeren Vergangenheit ausgenutzt wurde. Mit anderen Worten: Der Scan schließt nicht aus, dass man bereits kompromittiert wurde. Da man eine Kompromittierung nicht mit absoluter Sicherheit ausschließen kann, ist eine kontinuierliche Überwachung der Infrastruktur mittels einer Anomalieerkennungslösung eine angemessene, dem Stand der Technik entsprechende Maßnahme.

Wie stelle ich fest, ob die Schwachstelle bereits ausgenutzt wurde?

Es gibt Anzeichen (Indicators of Compromise) anhand derer man prüfen kann, ob die vorhandene Schwachstelle ausgenutzt wurde (oder es zumindest versucht wurde).

Manuelle Vorgehensweise

Im ersten Schritt versucht der Angreifer, das Protokollieren eines JNDI-Links zu provozieren. Eine Suche nach solchen Links in empfangenen Daten kann der erste Baustein zur Erkennung eines Angriffs sein. Für eine manuelle Suche können dazu die folgenden Suchbefehle verwendet werden: sudo egrep -I -i -r ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’ /var/log sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$(\{|%7B)jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):/[^\n]+’ sed -e ‘s/\${lower://’g | tr -d ‘}’ | egrep -I -i ‘jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):'” \; sudo find /var/log/ -name ‘*.gz’ -type f -exec sh -c “zcat {} | sed -e ‘s/\${lower://’g | tr -d ‘}’ | egrep -i ‘jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):'” \;

Automatisierte Vorgehensweise

Die obige manuelle Vorgehensweise liefert natürlich nur eine Momentaufnahme. Um eine kontinuierliche Überwachung der Daten zu erreichen, empfehlen wir die Nutzung einer Anomalieerkennungs-Lösung: Managed Detection and Response. Hier werden Log-, Infrastruktur- und Netzwerkverkehrsdaten (z.B. netflow) zentral gesammelt und mittels regelbasierter als auch Machine Learning gestützter Erkennungsmethoden verarbeitet, mit dem Ziel, potentiell sicherheitsrelevante Ereignisse zu identifizieren und gezielt zu bearbeiten.

1. Baustein

Unsere MDR-Lösung ermöglicht die Durchführung der oben beschriebenen Suche in Echtzeit mit Hilfe von Erkennungsregeln, welche die normalisierten Logdaten durchsuchen, z.B. im Feld „User Agent“.

2. Baustein

Ist die log4j-Schwachstelle tatsächlich ausgenutzt worden, ist ein JNDI-Lookup durch das angegriffene System zu beobachten. Dieser Lookup ist als ungewöhnliche ausgehende Verbindung in den Netzwerkverkehrsdaten sichtbar. Parallel dazu wird im EAGLE-System mittels der regelbasierten Erkennung die EAGLE-eigene Context-Engine sukzessive und automatisch mit Infrastrukturwissen gefüttert – ausschließlich aus Log- und Netzwerkverkehrsdaten, ohne eine bereits existierende Asset-Datenbank! Dies hat den Vorteil, dass die Context-Engine Datenbank weiß auf welchen Systemen Java installiert ist. Wird nun eine Anomalie im Netzwerkverkehr für Hosts beobachtet auf denen Java installiert ist, kann das ein Hinweis auf einen Angriff sein.

3. Baustein

War der Aufruf von Schadcode über die JNDI-Schwachstelle erfolgreich, startet der Angreifer eventuell weiteren Code, was als Start weiterer Prozesse durch die JVM in den Logs sichtbar wird Daher haben wir für die Anomalieerkennungslösung eine Detektionsregel erstellt, die gezielt auf Prozesse schaut, deren Parent-Prozess Java ist.

Was kann ich tun, um die Schwachstelle zu schliessen?

Grundsätzlich wird empfohlen, log4j auf eine Version 2.15.0 oder höher zu aktualisieren. Sollte dies nicht möglich sein, so kann eine Interpretation (Parsing) der eigentlichen Logdaten über einen Parameter deaktiviert werden. Dieser kann auf unterschiedliche Art aktiviert werden:
  • Durch Setzen von  “log4j2.formatMsgNoLookups” property to “true” in der entsprechenden Konfigurationsdatei (siehe auch hier)
  • Durch Setzen der Umgebungsvariable „LOG4J_FORMAT_MSG_NO_LOOKUPS“ auf „true“ auf Prozessebene
  • Durch Setzen der  “-Dlog4j2.formatMsgNoLookups=true” Option beim Aufruf der JVM (siehe auch hier)
Weiterhin können Maßnahmen wie der Einsatz von Filtern in einer Web Application Firewall (WAF) das Ausnutzen der Schwachstelle verhindern.

Wo finde ich weitere Informationen?

Aktuelle Informationen rund um die log4j Schwachstelle stellt das Bundesamt für Sicherheit in der Informationstechnologie zur Verfügung. Unter diesem Link können Sie sich über den aktuellen Stand informieren: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.html

Benötigen Sie weiterführende Unterstützung?

  • Sie sind sich ob der nächsten Schritte nicht sicher?
  • Sie wissen, dass es viele mögliche Verbesserungsmaßnahmen gibt, sind sich aber bezüglich der Effektivität und Priorisierung unsicher?
  • Sie suchen externe Beratung im Hinblick auf die aktuelle log4j-Schwachstelle oder zu Ihrem Umgang mit technischen Schwachstellen im Allgemeinen?
Buchen Sie einen ersten kostenfreien Beratungstermin über unser Kontaktformular!

Bild: iStock