thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J CVE-2021-44228 : Gegenmaßnahmen-Cheat-Sheet
Update – 28. Dezember 2021
CVE-2021-44832: Apache Log4j2 ist anfällig für RCE über den JDBC Appender, wenn ein Angreifer die Konfiguration kontrolliert.
Behoben in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) und 2.3.2 (Java 6)
Update – 17. Dezember 2021
Über Nacht wurde von Apache offengelegt, dass auch Log4j Version 2.16 anfällig ist – und zwar durch einen Denial-of-Service-Angriff mit der Auswirkung eines vollständigen Anwendungsabsturzes. Der Schweregrad wird als Hoch (7.5) eingestuft. CVE-2021-45105 wurde veröffentlicht, und eine neue behobene Version (2.17) wurde von Apache veröffentlicht. Es wird empfohlen, auf diese zu aktualisieren.
Hintergrund:
In der Internetdiskussion war eine 0-Day-Sicherheitslücke (die Remote-Codeausführung ermöglicht) in Apaches beliebter Log4J-Logging-Bibliothek für Java ein großes Thema. Diese spezielle Schwachstelle – verfolgt als CVE-2021-44228 mit der maximalen „kritischen“ CVSS-Bewertung von 10 – liegt in der Lookup-Fähigkeit von Log4J in Kombination mit JNDI (Java Naming and Directory Interface). Das Problem ist weit verbreitet, da viele Entwickler nicht wussten, dass die Verwendung von Log4J mit ungefilterten Eingaben gefährlich ist.
Die schwerwiegendste Auswirkung ist, dass ein Angreifer eine Zeichenkette an den Logger schicken kann, die bei der Verarbeitung durch Log4J beliebigen Code ausführt. Die ersten Beispiele hierfür nutzten den ${jndi:ldap}-Pfad, der dazu führen kann, dass beliebiger Code von einer entfernten URL geladen wird. Dieser Pfad wird durch die Verwendung neuerer Java-Laufzeitumgebungen, die den URL-basierten Klassenlader standardmäßig blockieren, teilweise entschärft. Leider reicht eine moderne Java-Version möglicherweise nicht aus, um eine Ausnutzung zu verhindern, da die Anwendung selbst Klassen bereitstellen kann, die zur Ausführung beliebigen Codes verwendet werden können.
Die JNDI-Architektur:
Minderungen für verschiedene Umgebungen:
Update – 17. Dezember 2021
Sicherheitslücke CVE-2021-45105
Details:
Apache Log4j2 Versionen 2.0-alpha1 bis 2.16.0 schützten nicht vor unkontrollierter Rekursion durch selbstreferenzielle Lookups. Wenn die Logging-Konfiguration ein nicht standardmäßiges Pattern Layout mit einem Context Lookup verwendet (z. B. $${ctx:loginId}), können Angreifer mit Kontrolle über Thread Context Map (MDC)-Eingabedaten bösartige Eingabedaten erstellen, die einen rekursiven Lookup enthalten. Dies führt zu einem StackOverflowError, der den Prozess beendet. Dies wird auch als DOS (Denial of Service)-Angriff bezeichnet.
Minderung:
Ab Version 2.17.0 (für Java 8) werden nur Lookup-Zeichenketten in der Konfiguration rekursiv expandiert; in jeder anderen Verwendung wird nur der oberste Lookup aufgelöst und alle verschachtelten Lookups werden nicht aufgelöst.
In früheren Versionen kann dieses Problem entschärft werden, indem sichergestellt wird, dass Ihre Logging-Konfiguration Folgendes tut:
Ersetzen Sie in PatternLayout in der Logging-Konfiguration Context Lookups wie ${ctx:loginId} oder $${ctx:loginId} durch Thread Context Map-Muster (%X, %mdc oder %MDC).
Entfernen Sie andernfalls in der Konfiguration Verweise auf Context Lookups wie ${ctx:loginId} oder $${ctx:loginId}, wenn diese von Quellen außerhalb der Anwendung stammen, wie z. B. HTTP-Header oder Benutzereingaben.
Update – 13. Dezember 2021
Log4j (Release 2.16.0 – 2021-12-13) hat zwei verbesserte Funktionen:
---------------!!Es wird dringend empfohlen, auf die neueste verfügbare Version zu aktualisieren, da Message Lookups standardmäßig deaktiviert sind.!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
JNDI standardmäßig deaktivieren. Erfordert, dass log4j2.enableJndi auf true gesetzt wird, um JNDI zu erlauben.
Unterstützung für Message Lookups vollständig entfernt
Neues Update:
------------------CVE-2021-45046-----------------
Apache Log4j2 Thread Context Message Pattern und Context Lookup Pattern sind anfällig für einen Denial-of-Service-Angriff.
Minderung:
Log4j 1.x Minderung: Log4j 1.x ist von dieser Sicherheitslücke nicht betroffen.
Log4j 2.x Minderung: Implementieren Sie eine der folgenden Minderungstechniken.
Benutzer von Java 8 (oder neuer) sollten auf Release 2.16.0 aktualisieren. Benutzer, die Java 7 benötigen, sollten auf Release 2.12.2 aktualisieren, sobald dieses verfügbar ist (in Arbeit, voraussichtlich bald verfügbar).
Entfernen Sie andernfalls die Klasse JndiLookup aus dem Klassenpfad: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Beachten Sie, dass nur die JAR-Datei log4j-core von dieser Sicherheitslücke betroffen ist. Anwendungen, die nur die JAR-Datei log4j-api ohne die JAR-Datei log4j-core verwenden, sind von dieser Sicherheitslücke nicht betroffen.
------------------CVE-2021-44228-------------------
Minderung
Log4j 1.x Minderung: Log4j 1.x hat keine Lookups, daher ist das Risiko geringer. Anwendungen, die Log4j 1.x verwenden, sind nur dann anfällig für diesen Angriff, wenn sie JNDI in ihrer Konfiguration verwenden. Eine separate CVE (CVE-2021-4104) wurde für diese Sicherheitslücke eingereicht. Zur Minderung: Überprüfen Sie Ihre Logging-Konfiguration, um sicherzustellen, dass kein JMSAppender konfiguriert ist.
Log4j 1.x Konfigurationen ohne JMSAppender sind von dieser Sicherheitslücke nicht betroffen.
Log4j 2.x Minderung: Implementieren Sie eine der folgenden Minderungstechniken.
Benutzer von Java 8 (oder neuer) sollten auf Release 2.16.0 aktualisieren.
Benutzer, die Java 7 benötigen, sollten auf Release 2.12.2 aktualisieren, sobald dieses verfügbar ist (in Arbeit, voraussichtlich bald verfügbar).
Entfernen Sie andernfalls die Klasse JndiLookup aus dem Klassenpfad: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Beachten Sie, dass nur die JAR-Datei log4j-core von dieser Sicherheitslücke betroffen ist. Anwendungen, die nur die JAR-Datei log4j-api ohne die JAR-Datei log4j-core verwenden, sind von dieser Sicherheitslücke nicht betroffen.
Apache Log4j: In Releases >=2.10** und Für Releases >=2.0-beta9 und <=2.10.0
pom.xml Fix:
Azure App Service (Windows und Linux):
Containerisierte Anwendungen:
Azure Functions:
Hotpatch für Apache Log4j
Wie Defender for Cloud von Log4j-Schwachstellen betroffene Maschinen findet
Erkennung in Azure Sentinel und Azure WAF-Protokollen
Maven-Plug-in-Konfiguration zum Verbannen anfälliger log4j2-Versionen in zukünftigen Builds
1. Apache Log4j:
CVE-2021-44228: Die JNDI-Funktionen von Apache Log4j2 schützen nicht vor kontrollierten LDAP- und anderen JNDI-bezogenen Endpunkten durch Angreifer.
