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.
Betroffene Versionen: alle log4j-core Versionen >=2.0-beta9 und <=2.14.1 Apache Log4j <=2.14.1 JNDI-Funktionen, die in Konfiguration, Log-Nachrichten und Parametern verwendet werden, schützen nicht vor kontrollierten LDAP- und anderen JNDI-bezogenen Endpunkten durch Angreifer. Ein Angreifer, der Log-Nachrichten oder Log-Nachrichtenparameter kontrollieren kann, kann beliebigen Code ausführen, der von LDAP-Servern geladen wird, wenn die Message-Lookup-Ersetzung aktiviert ist. Ab Log4j 2.15.0 ist dieses Verhalten standardmäßig deaktiviert.
In Releases >=2.10 kann dieses Verhalten entschärft werden, indem entweder die Systemeigenschaft log4j2.formatMsgNoLookups oder die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt wird. Für Releases >=2.7 und <=2.14.1 können alle PatternLayout-Muster geändert werden, um den Message-Konverter als %m{nolookups} anstelle von nur %m anzugeben.
Für Releases >=2.0-beta9 und <=2.10.0 besteht die Minderung darin, die Klasse JndiLookup aus dem Klassenpfad zu entfernen: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
2. pom.xml Fix:
Aktualisieren Sie die Abhängigkeit in der pom.xml und tauschen Sie sie gegen die neueste verfügbare Version im Abhängigkeitsbereich aus: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version>
<!-- Tauschen Sie gegen untenstehendes aus, um zu zeigen, dass es behoben ist -->
<!-- <version>2.17.0</version>-->
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<!-- Tauschen Sie gegen untenstehendes aus, um zu zeigen, dass es behoben ist -->
<!-- <version>2.17.0</version>-->
</dependency>
</dependencies>
Referenz: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18
3. Azure App Service (Windows und Linux):
Wenn möglich, sollten Kunden Log4j auf Version v2.15.0 aktualisieren und Anwendungen erneut bereitstellen. Dies ist die primär empfohlene Minderung. Wenn Sie Ihre Anwendung nicht erneut bereitstellen können, können Sie in Log4j Versionen 2.10 und höher dieses Verhalten entschärfen, indem Sie die Systemeigenschaft „-Dlog4j2.formatMsgNoLookups=true“ setzen. Auf App Service können Sie diese Eigenschaft setzen, indem Sie eine App-Einstellung namens JAVA_OPTS mit dem Wert „-Dlog4j2.formatMsgNoLookups=true“ erstellen. Die App-Einstellung JAVA_OPTS wird Ihrer Java-Anwendung beim Start übergeben. Wenn Sie die App-Einstellung JAVA_OPTS bereits gesetzt haben, fügen Sie einfach „-Dlog4j2.formatMsgNoLookups=true“ an den vorhandenen Wert an. Wenn Sie Log4J Version 2.9 oder niedriger verwenden, funktioniert diese Systemeigenschaft-Minderung nicht, und Sie sollten auf v2.15.0 aktualisieren.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"
4. Containerisierte Anwendungen
Für containerisierte Anwendungen: Wenn die von Ihnen verwendete Version von Log4j 2 2.10.0 oder höher ist, gibt es eine Umgebungsvariable oder eine Java-Befehlszeilenoption, mit der Sie das unsichere Ersetzungsverhalten deaktivieren können. Sie können die Zeile hinzufügen:
ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Docker-Datei-Referenz: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
Oder Sie können das entsprechende Flag "-Dlog4j.formatMsgNoLookups=true" zum Befehl hinzufügen, den Sie in Ihrem Container ausführen, z. B.:
CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
Sie können die Umgebungsvariable auch zur Laufzeit konfigurieren, was einfacher sein kann, z. B. für Kubernetes könnten Sie diese Zeilen in Ihre Konfiguration einfügen.
spec:
containers:
- name: ...
image: ...
env:
- name: LOG4J_FORMAT_MSG_NO_LOOKUPS
value: "true"
5. Azure Functions:
Die Konfiguration der Systemeigenschaft hängt von Ihrer Wahl der Hosting-Option ab: dedicated, premium oder consumption. Zur Erinnerung: Die primär empfohlene Minderung ist die Aktualisierung auf Log4J 2.15.0 und die erneute Bereitstellung Ihrer Anwendung. Wenn Sie dies aus irgendeinem Grund nicht tun können, können Sie die Systemeigenschaft anwenden.
- Dedicated und Premium Functions:
Erstellen Sie eine App-Einstellung namens JAVA_OPTS mit dem Wert „-Dlog4j2.formatMsgNoLookups=true“. Wenn Sie die App-Einstellung JAVA_OPTS bereits gesetzt haben, fügen Sie einfach „-Dlog4j2.formatMsgNoLookups=true“ an den vorhandenen Wert an.
- Consumption Functions:
Linux: Erstellen Sie eine App-Einstellung namens „languageWorkers__java__arguments“ mit dem Wert „-Dlog4j2.formatMsgNoLookups=true“. Windows: Erstellen Sie eine App-Einstellung namens „languageWorkers:java:arguments“ mit dem Wert „-Dlog4j2.formatMsgNoLookups=true“. **Beachten Sie, dass das Aktualisieren der App-Einstellung Ihre Web- und Function-Apps neu startet, was sich negativ auf die Kaltstartleistung auswirken kann. Wenn Sie Log4J Version 2.9 oder niedriger verwenden, funktioniert diese Systemeigenschaft-Minderung nicht, und Sie sollten auf v2.15.0 aktualisieren.
6. Hotpatch für Apache Log4j
Wie funktioniert es? Dieses Tool injiziert einen Java-Agenten in einen laufenden JVM-Prozess. Der Agent versucht, die lookup()-Methode aller geladenen Instanzen von org.apache.logging.log4j.core.lookup.JndiLookup zu patchen, um bedingungslos den String „Patched JndiLookup::lookup()“ zurückzugeben. Dies soll die Remote-Codeausführungs-Sicherheitslücke CVE-2021-44228 in Log4j beheben, ohne den Java-Prozess neu zu starten.
Wenn Sie die Möglichkeit haben, Ihre Java-Prozesse erneut bereitzustellen, können Sie es auch als statischen Agenten verwenden, d. h. Sie können diesen Patch in Ihre Laufzeitumgebung einbinden, ohne sich direkt auf Ihren Servern anzumelden.
Github : https://github.com/corretto/hotpatch-for-apache-log4j2
7. Wie Defender for Cloud von Log4j-Schwachstellen betroffene Maschinen findet
Mit Hilfe von Inventar haben Sie zwei leistungsstarke Möglichkeiten, Ihre Gefährdung zu bestimmen:
Software-Inventar
Ergebnisse der Schwachstellenbewertung
8. Erkennung in Azure Sentinel und WAF-Protokollen:
Azure WAF Log4j CVE-2021-44228 Jagd
Azure WAF Übereinstimmung für Log4j-Schwachstelle (CVE-2021-44228)
9. Maven-Plug-in-Konfiguration zum Verbannen anfälliger log4j2-Versionen in zukünftigen Builds:
Maven-Plug-in-Konfiguration zum Einfügen in Ihre Parent-POM, um die Verwendung veralteter log4j2-Versionen zu vermeiden, von denen einige von der RCE CVE-2021-44228 ("Log4Shell"), CVE-2021-45046 und CVE-2021-45105 betroffen sind.
Referenz: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d
<!-- Plug-in-Konfiguration zum Einfügen in Ihre Parent-POM, um die Verwendung von
veralteten log4j2-Versionen zu vermeiden, von denen einige von der RCE CVE-2021-44228
("Log4Shell"), CVE-2021-45046 und CVE-2021-45105 betroffen sind. Stellen Sie sicher, dass Sie
die neueste Version von log4j2 unter
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core überprüfen -->
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>ban-bad-log4j-versions</id>
<phase>validate</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
</excludes>
</bannedDependencies>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
...
Mitwirken:
Wir freuen uns über Beiträge aus der Community. Richtlinien für Beiträge:
-->Bitte erstellen Sie einen Pull Request.
-->Bitte fügen Sie eine Referenzquelle für mehr Kontext hinzu.
Es gibt möglicherweise mehrere verschiedene Umgebungen und andere Möglichkeiten zur Behebung. Fühlen Sie sich frei, einen Pull Request zu öffnen:
Referenzen:
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
https://github.com/justincormack/log4jpoc
https://www.rumble.run/blog/finding-log4j/
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay
https://docs.oracle.com/javase/jndi/tutorial/getStarted/overview/index.html
https://logging.apache.org/log4j/2.x/security.html
https://aws.amazon.com/blogs/opensource/hotpatch-for-apache-log4j/