Risque(s)
- Exécution de code arbitraire à distance
Systèmes affectés
- Apache Log4j versions 2.16.0 et 2.12.2 (java 7)
- Apache Log4j version 2.15.0
- Apache Log4j versions 2.0 à 2.14.1
- Apache Log4j versions 1.x (versions obsolètes) sous réserve d'une configuration particulière, cf. ci-dessous
- Les produits utilisant une version vulnérable de Apache Log4j : les CERT nationaux européens tiennent à jour une liste complète des produits et de leur statut vis-à-vis de la vulnérabilité [2]
Résumé
Une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.
Cette vulnérabilité permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification.
Des preuves de concept ont déjà été publiées. Cette vulnérabilité fait désormais l'objet d'une exploitation active.
Détection
${jndi:$%7Bjndi: (prend en compte un obscurcissement simple)
${${${::-%24%7B%3A%3A-${env:${date:${lower:${upper:hostName}}${${ (génère beaucoup de faux positifs, mais très exhaustif)
- le motif com.sun.jndi.ldap.LdapCtx@ (et non pas com.sun.jndi.dns.DnsContext@ comme indiqué précédemment) apparaîtra lorsqu'une injection LDAP est utilisée pour récupérer du contenu qui ne serait pas un objet java au standard rfc2713 : il peut s'agir d'un scan de détection ou d'une tentative erronée d'un attaquant
- l'injection sera enregistrée dans les journaux telle qu'elle a été soumise par l'attaquant si le serveur LDAP n'est pas joignable ou si l'objet qu'il souhaitait télécharger n'est pas trouvé sur le serveur LDAP : il est donc possible de trouver des tentatives d'injection sous une forme obscurcie dans les journaux, les motifs précédemment listés peuvent donc être utilisés pour identifier toutes les tentatives
- une erreur contenant le motif "Reference Class Name:" suivi d'un nom de classe puis des lignes commençant par "Type:" et "Content:" peut apparaître dans les journaux si l'injection LDAP fonctionne mais que la classe contenant la charge utile ne peut pas être récupérée sur le serveur LDAP visé
- il peut être intéressant de chercher des injections en DNS et LDAP basées sur la classe JavaLookup tels que ${java:hw}, ${java:vm} et ${java:os}. Ces dernières sont utilisées par les attaquants pour obtenir des informations sur la machine ciblée.
[Mise à jour du 07 janvier 2022] Le CERT-FR propose au téléchargement un ensemble de règles de détection basées sur la syntaxe utilisée par l'outil suricata. Ces règles peuvent être mises en œuvre, après adaptation, sur un équipement de détection réseau ou un pare-feu applicatif. Un guide de mise en œuvre est également proposé.
Précisions sur les CVE-2021-45046 et CVE-2021-45105
Précisions sur la CVE-2021-44832
La version 2.17.0 recommandée jusqu'à présent est affectée par une vulnérabilité, désignée par l'identifiant CVE-2021-44832 [6]. Cette vulnérabilité permet à un attaquant, autorisé à modifier le fichier de configuration Log4J, d'effectuer une exécution de code à distance. La complexité de l'attaque étant élevée, le CERT-FR continue de recommander la mise à jour des composants Log4j à la version 2.17.0 pour java 8 et 2.12.3 pour java7. Par ailleurs, il est fortement recommandé de rester attentif aux nouvelles vulnérabilités Log4j qui pourraient être identifiées à l'avenir ainsi qu'aux correctifs proposés par Apache.
Précisions sur les modes d'attaque
Contournement provisoire
La version 1 de log4j a été initialement déclarée vulnérable cependant la vulnérabilité n'existe que si le composant JMS Appender est configuré pour prendre en compte JNDI. Il s'agit donc d'une configuration très spécifique [1][3].
Il est recommandé d'utiliser une version à jour de l'environnement d'exécution Java (les versions 8u191 et ultérieures apportent des restrictions pour les appels JNDI basés sur LDAP et RMI), cependant les codes d'exploitation les plus récents sont en mesure de contourner ces protections pour continuer d'exploiter la vulnérabilité.
La mise en place de filtres au niveau de vos pare-feux applicatifs pour bloquer les tentatives d'exploitation de cette vulnérabilité peut constituer une première mesure d'urgence mais elle reste insuffisante : les attaquants utilisent différentes techniques d'obscurcissement des données injectées pour contourner ces filtres.
Les contournements proposés initialement ne permettent plus de se prémunir contre certaines formes d'exploitation. Face à la possibilité que d'autres exploitations soient encore découvertes y compris pour la version 2.15.0, le CERT-FR recommande d'utiliser les versions les plus à jour de la bibliothèque.
En cas d'impossibilité de migration, il reste possible de supprimer la classe Java vulnérable. Cette opération impose de tester le fonctionnement de l'application afin d'identifier les impacts de la modification sur son fonctionnement.
Cette suppression peut par exemple être effectuée avec la commande suivante : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Outillage
- Des outils de recherche de la bibliothèque Log4j sont proposés par le CERT/CC (non qualifiés par le CERT-FR) : https://github.com/CERTCC/CVE-2021-44228_scanner
- Le site du NCSC-NL recense également des outils, qui n'ont pas été qualifiés par le NCSC-NL ni par le CERT-FR : https://github.com/NCSC-NL/log4shell/tree/main/scanning
- La CISA a publié un scanner basé sur des outils issus de la communauté open-source : https://github.com/cisagov/log4j-scanner
Solution
Il est fortement recommandé aux utilisateurs d'applications ou de logiciels sur étagère basés sur la technologie Java/J2EE :
- de conserver les journaux a minima depuis le 1er décembre 2021 à des fins d'analyse ultérieure ;
- de préparer sans délai des mesures de préservation en cas d'incident majeur, notamment par la mise hors ligne de sauvegardes à jour ;
- de filtrer et de journaliser les flux sortants des serveurs pour les limiter aux seuls flux autorisés vers des services de confiance ;
- de prendre contact avec le développeur ou l'éditeur pour vérifier s'ils sont exposés à cette vulnérabilité et si un correctif est disponible.
Il est fortement recommandé aux développeurs/éditeurs :
- d'inventorier les solutions affectées par les vulnérabilités ;
- d'informer les utilisateurs et clients de leurs statuts et des actions en cours ;
- de corriger les solutions en utilisant à minima la version 2.17.0 pour java 8 ou la version 2.12.3 pour java 7 et idéalement la version 2.17.1 pour java 8 ou la version 2.12.4 pour java 7 ;
- de fournir une nouvelle version de leurs solutions dans les plus brefs délais.
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
La mise à jour d’un produit ou d’un logiciel est une opération délicate qui doit être menée avec prudence. Il est notamment recommandé d’effectuer des tests autant que possible. Des dispositions doivent également être prises pour garantir la continuité de service en cas de difficultés lors de l’application des mises à jour comme des correctifs ou des changements de version.
Documentation
- Bulletin de sécurité Apache du 09 décembre 2021
https://logging.apache.org/log4j/2.x/security.html - Référence CVE CVE-2021-44228
https://www.cve.org/CVERecord?id=CVE-2021-44228 - [1] https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
- [2] liste des produits et de leurs statuts vis-à-vis de la vulnérabilité
https://github.com/NCSC-NL/log4shell/tree/main/software - [3] Référence CVE CVE-2021-4104
https://www.cve.org/CVERecord?id=CVE-2021-4104 - [4] Référence CVE CVE-2021-45046
https://www.cve.org/CVERecord?id=CVE-2021-45046 - [5] Référence CVE CVE-2021-45105
https://www.cve.org/CVERecord?id=CVE-2021-45105 - [6] Référence CVE CVE-2021-44832
https://www.cve.org/CVERecord?id=CVE-2021-44832