Wie Sie das Log4j-Risiko minimieren

Die IT-Sicherheits-Community hat in der vergangenen Woche hart gearbeitet, um eine kritische und leicht auszunutzende Schwachstelle in einer beliebten Java-Komponente namens Log4j zu untersuchen. Die Sicherheitslücke betrifft Millionen von Anwendungen und Produkten. Seit Bekanntwerden der Schwachstelle (und deren Ausnutzung durch Cyberkriminelle) haben Sicherheitsforscher weitere Sicherheitsprobleme in Log4j und verschiedene Möglichkeiten zur Umgehung einiger, vorgeschlagener Abhilfemaßnahmen entdeckt. Sicherheitsteams suchen entsprechend händeringend nach Möglichkeiten, um ihre Anwendungen, Server und Netzwerke abzusichern. Ein Update der betroffenen Komponente auf die neueste Version - derzeit 2.17.0 für Java 8 (und aktueller) - ist die beste Möglichkeit, die bisher gefundenen Schwachstellen zu beseitigen:

• CVE-2021-44228 (auch bekannt als Log4Shell, die zu Remote Code Execution führt),

• CVE-2021-45046 und

• CVE-2021-45105 (beide können Denial-of-Service-Bedingungen verursachen).

Leider ist ein sofortiges Patchen nicht in allen Szenarien möglich: Produktpakete von Drittanbietern enthalten möglicherweise anfällige Versionen der beliebten Protokollbibliothek, die die Benutzer nicht ändern können, ohne das gesamte Produkt zu aktualisieren. So sind sie auf die Veröffentlichung von Updates durch die Hersteller angewiesen.

Geschäftskritische Server und Anwendungen können möglicherweise nicht sofort neu gestartet werden - oder die Anwendungen laufen in Containern, für die erst neue Container-Images erstellt werden müssen. Wie bei den meisten Schwachstellen sind alternative Abhilfemaßnahmen für Sicherheitsteams sehr nützlich. Zunächst ist es aber wichtig zu wissen, welche Wege Sie bei der Absicherung von Log4j nicht beschreiten sollten. Da die Sicherheits-Community diese Schwachstelle und ihre Auswirkungen weiterhin untersucht, können bestehende Abhilfestrategien geändert oder zurückgezogen werden.

Was nicht gegen Log4j hilft

Seit die Log4j-Schwachstelle öffentlich wurde, haben sich mehrere vorgeschlagene Abhilfemaßnahmen als unwirksam erwiesen. Diese sollten deshalb nicht mehr angewendet werden:

Ein Update der Java-Version reicht nicht

Der ursprüngliche Exploit funktionierte nicht bei Java-Versionen, die neuer als 6u212, 7u202, 8u192 oder 11.0.2 waren, weil die Standardkonfiguration in diesen Versionen das Laden von Klassen über JNDI (Java Naming and Directory Interface) von Remote Servern verhindert. Sicherheitsforscher haben jedoch inzwischen belegt, dass Angreifer Payloads erstellen können, die sich Klassen im eigenen Klassenpfad der Anwendung zunutze machen, so dass dies nicht alle Angriffe verhindert.

formatMsgNoLookups verhindert nicht alle Angriffe

Frühe Ratschläge zur Schadensbegrenzung - auch von den Log4j-Entwicklern - beinhalteten, eine Eigenschaft namens formatMsgNoLookups in Log4j-Versionen höher als 2.10 auf "true" oder eine Umgebungsvariable namens LOG4J_FORMAT_MSG_NO_LOOKUPS zu setzen. Das hat sich bei der zweiten Denial-of-Service-Schwachstelle als ineffizient erwiesen, die auch bei aktiviertem Flag funktioniert. "Es gibt immer noch Codepfade in Log4j, in denen Message Lookups auftreten können: Bekannte Beispiele sind Anwendungen, die Logger.printf("%s", userInput) verwenden, oder Anwendungen, die eine benutzerdefinierte Message Factory verwenden, in der die resultierenden Nachrichten nicht StringBuilderFormattable implementieren", so die Entwickler.

Message Lookups über Log Statement Formats deaktivieren

Eine weitere vorgeschlagene Abhilfemaßnahme bestand darin, alle Protokollanweisungsformate in der Anwendung von %m, %msg oder %message auf %m{nolookups}, %msg{nolookups} oder %message{nolookups} zu ändern, um die Nachschlagefunktion für Nachrichten zu deaktivieren. Dies funktioniert aus denselben Gründen wie das Flag formatMsgNoLookups nicht - ist darüber hinaus aber auch gefährlich, weil es ein falsches Gefühl der Sicherheit vermittelt. Es ist sehr leicht, die Aktualisierung einer Protokollierungsanweisung in einer Abhängigkeit zu übersehen oder eine anfällige %m-Anweisung später wieder einzuführen, ohne es zu merken. Wenn Sie diese Abschwächung bereits verwendet haben, sollten Sie sich nicht darauf verlassen.

Web Application Firewalls zur Filterung

Es ist zwar möglich, die bekannten Exploits mit einer Web Application Firewall zu blockieren, aber es ist sehr schwierig, alle möglichen Exploit-Strings zu erfassen. Seit Bekanntwerden der Schwachstelle haben Forscher viele Möglichkeiten aufgezeigt, wie sich solche verschachtelten und verschleierten Payloads erstellen lassen, mit denen sich die vorgeschlagenen WAF-Filterregeln umgehen lassen. Allerdings aktualisieren WAF- und IPS-Anbieter ihre Log4Shell-Signaturen ständig, so dass diese als sofortige und vorübergehende Reaktion verwendet werden können, um bekannte Exploits zu blockieren. Es gibt jedoch interne Exploit-Pfade und Szenarien für diese Schwachstelle, die nicht durch eine WAF blockiert werden können.

Was gegen Log4j hilft

JndiLookup-Klasse entfernen

Diese Schwachstelle wird durch die Art und Weise verursacht, wie Log4j JNDI nutzt. Das Java Naming and Directory Interface wurde entwickelt, um zusätzliche Java-Objekte während der Laufzeitausführung laden zu können. Mit JNDI können solche Objekte von Remote Naming Services über verschiedene Protokolle geladen werden. Der ursprüngliche Exploit verwendete LDAP (Lightweight Directory Access Protocol), das am weitesten verbreitet ist, aber auch andere Protokolle werden unterstützt: DNS (Domain Name System), RMI (Remote Method Invocation), NDS (Novell Directory Services), NIS (Network Information Service) und CORBA (Common Object Request Broker Architecture).

Eine Möglichkeit, die Schwachstelle zu beheben, besteht darin, die Verwendung von JNDI Message Lookups zu deaktivieren, wie es Log4j 2.16.0 tut. Das kann jedoch auch dadurch erreicht werden, die gesamte JndiLookup-Klasse, die diese Funktionalität implementiert, aus einem betroffenen Log4j-Paket zu entfernen. Da Java-Komponenten im Wesentlichen ZIP-Archive sind, können Administratoren den folgenden Befehl ausführen, um eine verwundbare Paketinstanz zu ändern und zu patchen:

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

Hotpatching mit Java-Agent

Unter Hotpatching versteht man das Einspielen eines Patches in einen laufenden Prozess, ohne diesen neu starten zu müssen. Durch eine Instrumentierungs-API und sogenannte Agenten unterstützt Java die On-the-Fly-Änderungen von Byte-Code, das bereits in einer Java Virtual Machine (JVM) läuft. Ein Java-Agent ist im Wesentlichen eine JAR-Datei (Java Archive), die während der Laufzeit dynamisch an eine JVM angehängt werden kann.

Als Reaktion auf die Log4j-Schwachstellen hat das Corretto-Team von Amazon Web Services einen Java-Agenten entwickelt, der versucht, die lookup()-Methode aller geladenen org.apache.logging.log4j.core.lookup.JndiLookup-Instanzen so zu patchen, dass sie die Zeichenkette "Patched JndiLookup::lookup()" zurückgibt, anstatt eine Verbindung zu einem Remote-Server herzustellen. Der Agent ist auf GitHub verfügbar und kann auch als ephemerer Container in einem bestehenden Kubernetes-Pod bereitgestellt werden, um Anwendungen zu patchen, die bereits in anderen Containern laufen. Ephemerale Container werden in Kubernetes v1.16 und höher unterstützt.

Eigener Exploit, um weitere zu verhindern

Es besteht die Möglichkeit, die Log4j-Schwachstelle selbst auf betroffenen Servern auszunutzen, um bestimmte Änderungen am Live-System und an der Anwendung vorzunehmen, die eine weitere Ausnutzung verhindern. Forscher des Sicherheitsunternehmens Cybereason haben einen solchen Immunisierungs-Exploit entwickelt, Forscher von LunaSec haben diesen weiter verbessert und auf einem Live-Server als öffentlichen Service bereitgestellt.

Ein Anwendungsfall für einen solchen Exploit sind all die Produkte von Drittanbietern - Applikationspakete, Embedded Devices und Appliances - für die noch keine Patches verfügbar sind, oder anfällige Produkte, die das Ende ihrer Lebensdauer erreicht haben und keine offiziellen Updates mehr erhalten. Die Nutzung des Exploits gegen sich selbst könnte eine kurzfristige, praktikable Lösung sein.

Dabei sollten Sie sich darüber bewusst sein:

1. die Behebung ist nur vorübergehend, da die Änderungen, die der Exploit vornimmt, für den laufenden Java-Prozess gelten und beim Neustart der JVM rückgängig gemacht werden. Die Immunisierung muss also erneut angewendet werden, wenn der Server neu gestartet wird.

2. Obwohl die Methode auf verschiedenen Konfigurationen und Systemen getestet wurde, ist es möglich, dass sie nicht auf allen funktioniert und zu Abstürzen führt. Die Wiederherstellung nach einem Absturz kann einen Neustart des Servers erfordern. Daher ist es keine gute Idee, diese Methode auf kritische Systeme anzuwenden, bei denen eine Ausfallzeit nicht in Frage kommt.

3. Die Verwendung auf Servern, die nicht in Ihrem Besitz sind und die Sie nicht kontrollieren, ist sehr wahrscheinlich illegal, da die Sicherheitslücke ausgenutzt wird - wenn auch zu nicht böswilligen Zwecken.

Anfällige Systeme identifizieren

Bevor eine Reaktionsstrategie entwickelt und einer der oben genannten Wege zur Schadensbegrenzung beschritten werden kann, müssen Unternehmen zunächst alle Anwendungen und Systeme identifizieren, die für Log4j-Exploits anfällig sein könnten. Das ist kein leichtes Unterfangen, wenn man bedenkt, dass jede Anwendung ihre eigene Instanz von Log4j bündeln und auch dynamisch als Teil einer anderen Drittanbieterabhängigkeit laden kann.

Mehrere Listen von Log4Shell Vendor Advisories werden von der Sicherheitsgemeinschaft und den CERTs gepflegt, diese sind aber wahrscheinlich unvollständig. Solange Software-Stücklisten (Software Bills of Materials, SBOMs) nicht allgemein von Softwareentwicklern übernommen werden, müssen Sicherheitsteams leider bei jeder neuen Schwachstelle die zeitraubende und fehleranfällige Aufgabe bewältigen, die betroffenen Systeme in ihren Unternehmen zu identifizieren. Es ist zu erwarten, dass im Nachgang von Log4j Forscher wie Angreifer verstärkt nach Schwachstellen in anderen, weit verbreiteten Komponenten suchen werden.

Die Sicherheits-Community hat schnell reagiert und Open-Source-Tools entwickelt, mit denen anfällige Server und Instanzen des Log4j-Pakets automatisch gefunden werden können. Das Tool log4shell von LunaSec kann .jar- und .war-Dateien in einem Projektverzeichnis überprüfen und melden, ob diese anfällig sind. Auch andere Open-Source- und kommerzielle Schwachstellen-Scanner und -Tools unterstützen inzwischen die Log4j-Schwachstellen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Network World.