thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J CVE-2021-44228 : Aide-mémoire d'atténuation
Mise à jour - 28 décembre 2021
CVE-2021-44832 : Apache Log4j2 vulnérable à une exécution de code à distance (RCE) via l'Appender JDBC lorsqu'un attaquant contrôle la configuration.
Corrigé dans Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) et 2.3.2 (Java 6)
Mise à jour - 17 décembre 2021
Dans la nuit, Apache a divulgué que la version 2.16 de Log4j est également vulnérable à une attaque par déni de service dont l'impact est un crash complet de l'application ; la sévérité est classée comme Élevée (7.5). Le CVE-2021-45105 a été émis, et une nouvelle version corrigée (2.17) a été publiée par Apache, dont la mise à niveau est recommandée.
Contexte :
Les discussions sur Internet étaient en ébullition à propos d'une vulnérabilité 0-day (pouvant conduire à une exécution de code à distance) dans la célèbre bibliothèque de journalisation Log4J d'Apache pour Java. Cette vulnérabilité particulière – suivie sous le nom CVE-2021-44228 avec le score CVSS maximal « critique » de 10 – réside dans la capacité de recherche (lookup) de Log4J, combinée à JNDI (Java Naming and Directory Interface). Ce problème est très répandu car de nombreux développeurs ignoraient que Log4J était dangereux à utiliser avec des entrées non filtrées.
L'impact le plus significatif est qu'un attaquant peut amener une chaîne de caractères jusqu'au journaliseur qui, une fois traitée par Log4J, exécute du code arbitraire. Les premiers exemples de cette attaque utilisaient le chemin ${jndi:ldap}, ce qui pouvait conduire au chargement de code arbitraire depuis une URL distante. Ce chemin est partiellement atténué par l'utilisation de runtimes Java plus récents qui bloquent par défaut le chargeur de classes basé sur URL. Malheureusement, une version moderne de Java peut ne pas suffire à empêcher l'exploitation, car l'application elle-même peut exposer des classes qui peuvent être utilisées pour exécuter du code arbitraire.
L'architecture JNDI :
Mesures d'atténuation pour différents environnements :
Mise à jour - 17 décembre 2021
Vulnérabilité de sécurité CVE-2021-45105
Détails :
Les versions d'Apache Log4j2 allant de 2.0-alpha1 à 2.16.0 ne protégeaient pas contre la récursion incontrôlée provenant de recherches auto-référentielles. Lorsque la configuration de journalisation utilise une disposition de motifs (Pattern Layout) non par défaut avec une recherche de contexte (Context Lookup) (par exemple, $${ctx:loginId}), les attaquants qui contrôlent les données d'entrée du Thread Context Map (MDC) peuvent concevoir des données d'entrée malveillantes contenant une recherche récursive, entraînant une StackOverflowError qui terminera le processus. C'est ce qu'on appelle aussi une attaque DOS (Déni de service).
Mesure d'atténuation :
À partir de la version 2.17.0 (pour Java 8), seules les chaînes de recherche de la configuration sont développées de manière récursive ; dans tout autre usage, seule la recherche de niveau supérieur est résolue, et les recherches imbriquées ne sont pas résolues.
Dans les versions antérieures, ce problème peut être atténué en s'assurant que votre configuration de journalisation fait ce qui suit :
Dans PatternLayout de la configuration de journalisation, remplacez les recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} par les motifs du Thread Context Map (%X, %mdc ou %MDC).
Sinon, dans la configuration, supprimez les références aux recherches de contexte comme ${ctx:loginId} ou $${ctx:loginId} lorsqu'elles proviennent de sources externes à l'application, telles que les en-têtes HTTP ou les entrées utilisateur.
Mise à jour - 13 décembre 2021
** Log4j (version 2.16.0 – 2021-12-13) dispose de deux fonctionnalités améliorées :**
---------------!!Il est fortement recommandé de passer à la dernière version disponible car les recherches de messages sont désactivées par défaut.!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
Désactiver JNDI par défaut. Exiger que log4j2.enableJndi soit défini sur true pour autoriser JNDI.
Supprimer complètement la prise en charge des recherches de messages (Message Lookups)
Nouvelle mise à jour :
------------------CVE-2021-45046-----------------
Les motifs de messages de contexte de thread (Thread Context Message Pattern) et les motifs de recherche de contexte (Context Lookup Pattern) d'Apache Log4j2 sont vulnérables à une attaque par déni de service.
Mesure d'atténuation :
Atténuation Log4j 1.x : Log4j 1.x n'est pas affecté par cette vulnérabilité.
Atténuation Log4j 2.x : Mettez en œuvre l'une des techniques d'atténuation ci-dessous.
Les utilisateurs de Java 8 (ou version ultérieure) doivent passer à la version 2.16.0. Les utilisateurs nécessitant Java 7 doivent passer à la version 2.12.2 lorsqu'elle sera disponible (travail en cours, attendue prochainement).
Sinon, supprimez la classe JndiLookup du classpath : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Notez que seul le fichier JAR log4j-core est affecté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas affectées par cette vulnérabilité.
------------------CVE-2021-44228-------------------
Mesure d'atténuation
Atténuation Log4j 1.x : Log4j 1.x ne dispose pas de recherches (Lookups), le risque est donc plus faible. Les applications utilisant Log4j 1.x ne sont vulnérables à cette attaque que lorsqu'elles utilisent JNDI dans leur
configuration. Un CVE distinct (CVE-2021-4104) a été déposé pour cette vulnérabilité. Pour atténuer : auditez votre configuration de journalisation pour vous assurer qu'aucun JMSAppender n'y est configuré.
Les configurations Log4j 1.x sans JMSAppender ne sont pas affectées par cette vulnérabilité.
Atténuation Log4j 2.x : Mettez en œuvre l'une des techniques d'atténuation ci-dessous.
Les utilisateurs de Java 8 (ou version ultérieure) doivent passer à la version 2.16.0.
Les utilisateurs nécessitant Java 7 doivent passer à la version 2.12.2 lorsqu'elle sera disponible (travail en cours, attendue prochainement).
Sinon, supprimez la classe JndiLookup du classpath : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Notez que seul le fichier JAR log4j-core est affecté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas affectées par cette vulnérabilité.
1. Apache Log4j :
Dans les versions >=2.10** et
Pour les versions >=2.0-beta9 et <=2.10.0
2. Correctif pom.xml :
3. Azure App Service (Windows et Linux) :
4. Applications conteneurisées :
5. Azure Functions :
6. Hotpatch pour Apache Log4j
7. Comment Defender for Cloud détecte les machines affectées par les vulnérabilités Log4j
8. Détection dans les journaux Azure Sentinel et Azure WAF
9. Configuration du plug-in Maven pour bannir les versions vulnérables de log4j2 dans les futures compilations
1. Apache Log4j :
CVE-2021-44228 : les fonctionnalités JNDI d'Apache Log4j2 ne protègent pas contre les points de terminaison LDAP contrôlés par un attaquant et autres points de terminaison liés à JNDI.
Versions concernées : toutes les versions de log4j-core >=2.0-beta9 et <=2.14.1 Les fonctionnalités JNDI d'Apache Log4j <=2.14.1 utilisées dans la configuration, les messages de journalisation et les paramètres ne protègent pas contre les points de terminaison LDAP contrôlés par un attaquant et autres points de terminaison liés à JNDI. Un attaquant qui peut contrôler les messages de journalisation ou leurs paramètres peut exécuter du code arbitraire chargé depuis des serveurs LDAP lorsque la substitution de recherche de messages est activée. À partir de log4j 2.15.0, ce comportement a été désactivé par défaut.
Dans les versions >=2.10**, ce comportement peut être atténué en définissant soit la propriété système log4j2.formatMsgNoLookups, soit la variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS sur true. Pour les versions >=2.7 et <=2.14.1, tous les motifs PatternLayout peuvent être modifiés pour spécifier le convertisseur de messages comme %m{nolookups} au lieu de simplement %m.
Pour les versions >=2.0-beta9 et <=2.10.0, l'atténuation consiste à supprimer la classe JndiLookup du classpath : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
2.Correctif pom.xml :
Mettez à jour la dépendance dans pom.xml et remplacez-la par la dernière version disponible dans la section des dépendances : 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>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
</dependencies>
Référence : https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18
3.Azure App Service (Windows et Linux) :
Si possible, les clients doivent mettre à niveau Log4j vers la version v2.15.0 et redéployer les applications. C'est la mesure d'atténuation principale recommandée. Si vous n'êtes pas en mesure de redéployer votre application, vous pouvez, dans les versions de Log4j 2.10 et supérieures, atténuer ce comportement en définissant la propriété système « -Dlog4j2.formatMsgNoLookups=true ». Sur App Service, vous pouvez définir cette propriété en créant un paramètre d'application nommé JAVA_OPTS avec une valeur de « -Dlog4j2.formatMsgNoLookups=true ». Le paramètre d'application JAVA_OPTS est transmis à votre application Java au démarrage de celle-ci. Si vous avez déjà défini le paramètre d'application JAVA_OPTS, ajoutez simplement « -Dlog4j2.formatMsgNoLookups=true » à la valeur existante. Si vous utilisez Log4J version 2.9 ou inférieure, cette atténuation par propriété système ne fonctionnera pas et vous devez passer à la v2.15.0.
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.Applications conteneurisées
Pour les applications conteneurisées, si la version de Log4j 2 que vous utilisez est 2.10.0 ou ultérieure, il existe une variable d'environnement ou une option de ligne de commande Java que vous pouvez utiliser pour désactiver le comportement de substitution dangereux. Vous pouvez ajouter la ligne :
ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Référence du fichier Docker : https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
À votre Dockerfile, ou vous pouvez ajouter le drapeau équivalent « -Dlog4j.formatMsgNoLookups=true » à la commande que vous exécutez dans votre conteneur, par exemple :
CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
Vous pouvez également configurer la variable d'environnement au moment de l'exécution, ce qui peut être plus facile ; par exemple pour Kubernetes, vous pouvez ajouter ces lignes dans votre configuration.
spec:
containers:
- name: ...
image: ...
env:
- name: LOG4J_FORMAT_MSG_NO_LOOKUPS
value: "true"
5.Azure Functions :
La configuration de la propriété système dépendra de votre choix d'option d'hébergement : dédié, premium ou consommation. Pour rappel, la mesure d'atténuation principale recommandée consiste à mettre à niveau Log4J vers 2.15.0 et à redéployer votre application. Si vous ne pouvez pas le faire pour quelque raison que ce soit, vous pouvez alors appliquer la propriété système.
- Functions dédiées et premium :
Créez un paramètre d'application nommé JAVA_OPTS avec une valeur de « -Dlog4j2.formatMsgNoLookups=true ». Si vous avez déjà défini le paramètre d'application JAVA_OPTS, ajoutez simplement « -Dlog4j2.formatMsgNoLookups=true » à la valeur existante.
- Functions à consommation :
Linux : Créez un paramètre d'application nommé « languageWorkers__java__arguments » avec une valeur de « -Dlog4j2.formatMsgNoLookups=true ». Windows : Créez un paramètre d'application nommé « languageWorkers:java:arguments » avec une valeur de « -Dlog4j2.formatMsgNoLookups=true ». **Notez que la mise à jour du paramètre d'application redémarrera vos applications Web et Functions, ce qui pourrait affecter les performances de démarrage à froid. Si vous utilisez Log4J version 2.9 ou inférieure, cette atténuation par propriété système ne fonctionnera pas et vous devez passer à la v2.15.0.
6.Hotpatch pour Apache Log4j
Comment cela fonctionne-t-il ? Cet outil injecte un agent Java dans un processus JVM en cours d'exécution. L'agent tente de corriger la méthode lookup() de toutes les instances org.apache.logging.log4j.core.lookup.JndiLookup chargées pour renvoyer inconditionnellement la chaîne « Patched JndiLookup::lookup() ». Cela vise à traiter la vulnérabilité d'exécution de code à distance CVE-2021-44228 dans Log4j sans redémarrer le processus Java.
Si vous avez la possibilité de redéployer vos processus Java, vous pouvez également l'utiliser comme agent statique, ce qui signifie que vous pouvez inclure ce correctif dans votre environnement d'exécution sans vous connecter directement à vos serveurs.
GitHub : https://github.com/corretto/hotpatch-for-apache-log4j2
7.Comment Defender for Cloud détecte les machines affectées par les vulnérabilités Log4j
En utilisant l'inventaire, vous disposez de deux moyens puissants pour déterminer votre exposition :
Inventaire des logiciels
Résultats de l'évaluation des vulnérabilités
8.Détection dans les journaux Azure Sentinel et Azure WAF :
Chasse Azure WAF Log4j CVE-2021-44228
Correspondance Azure WAF pour la vulnérabilité Log4j (CVE-2021-44228)
9.Configuration du plug-in Maven pour bannir les versions vulnérables de log4j2 dans les futures compilations :
Configuration du plug-in Maven à placer dans votre POM parent pour éviter toute utilisation de versions obsolètes de log4j2, dont certaines sont sujettes à l'exécution de code à distance CVE-2021-44228
(« Log4Shell »), CVE-2021-45046 et CVE-2021-45105).
Référence : https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d
<!-- plug-in configuration to put into your parent POM for avoiding any usages of
outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
latest version of log4j2 at
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<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>
...
Contributions :
Heureux de recevoir des contributions de la communauté. Lignes directrices pour les contributions :
-->Merci de faire une PR.
-->Merci d'inclure une source de référence pour plus de contexte
Il peut y avoir plusieurs environnements différents et d'autres façons de corriger, n'hésitez pas à ouvrir une demande de tirage (pull request) :
Références :
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/