Accueil > Alertes CERT-MC > AVIS CERTFR - 2021 - ALE - 022

AVIS CERTFR - 2021 - ALE - 022

Objet : [MaJ] Vulnérabilité dans Apache Log4j

Référence : CERTFR-2021-ALE-022

Risque(s)

- Exécution de code arbitraire à distance

Systèmes affectés

- 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] [mise à jour du 14 décembre 2021]

Résumé

[Version initiale] 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.

[Mise à jour du 14 décembre 2021]

Le CERT-FR recommande de réaliser une analyse approfondie des journaux réseau. Les motifs suivants permettent d'identifier une tentative d'exploitation de cette vulnérabilité lorsqu'ils sont utilisés dans les URLs ou certaines en-têtes HTTP comme user-agent :

${jndi:

$%7Bjndi: (prend en compte un obscurcissement simple)

Cependant, les attaquants peuvent utiliser des moyens d’obscurcissement pour contourner les motifs de détection précédents. Les motifs suivants permettent de prendre en compte certaines méthodes d'obscurcissement mais peuvent provoquer des faux positifs :

${${
${::-
%24%7B%3A%3A-
${env:
${date:
${lower:
${upper:
hostName}
}${
${ (génère beaucoup de faux positifs, mais très exhaustif)

Afin de déterminer si une tentative d'exploitation a réussi, et dans le cas où vous disposeriez de journaux contenant des requêtes DNS, il est recommandé de les corréler aux résultats des motifs précédemment énoncés. En effet, si l’exécution d'une requête de type ${jndi:xxx://nom.domaine.com} a fonctionné, une résolution DNS sera alors effectuée pour résoudre le nom de domaine externe nom.domaine.com. L'émission d'une requête DNS peut également faire l'objet d'une trace dans les journaux du serveur applicatif. Ainsi, il peut être utile de chercher le motif com.sun.jndi.dns.DnsContext@ dans ces journaux.
Note : une résolution de domaine externe ne signifie pas qu'une exécution de code a réussi mais permet de confirmer que l'application est vulnérable. Il sera donc nécessaire de poursuivre l'analyse des journaux pour détecter une compromission.

Contournement provisoire

Il est fortement recommandé d'utiliser la version 2.15.0 de log4j dès que possible. Cependant, en cas de difficulté de migration vers cette version, les contournements ci-dessous peuvent être appliqués temporairement :

Pour les applications utilisant les versions 2.7.0 et ultérieures de la bibliothèque log4j, il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur.

Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version.

Pour les applications utilisant les versions 2.10.0 et ultérieures de la bibliothèque log4j, il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque).

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].

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é.

[Mise à jour du 14 décembre 2021]

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.

Solution

[Mise à jour du 14/12/2021]

Il est fortement recommandé aux utilisateurs d'applications ou de logiciels sur étagère basés sur la technologie Java/J2EE :

- 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'utiliser la version 2.15.0 ou ultérieure et de fournir une nouvelle version de leur logiciel dans les plus brefs délais.

Une nouvelle version 2.16.0 a été publiée le 13 décembre. Elle complète la correction en désactivant le JNDI et la fonction de Lookup, qui doivent désormais être explicitement activées.

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
http://cve.mitre.org/cgi-bin/cvename.cgi?name=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  

Dernière version de ce document

https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/  

AVIS CERTFR - 2022 - AVI - 079

25 janvier 2022
actualite

Objet : Vulnérabilité dans strongSwanRéférence : CERTFR-2022-AVI-079Risque(s) - Déni de service à distance - Contournement de la politique de sécur... Lire la suite[+]

AVIS CERTFR - 2022 - AVI - 078

25 janvier 2022
actualite

Objet : Multiples vulnérabilités dans Foxit PDF Editor et Foxit PDF Reader versions MacOSRéférence : CERTFR-2022-AVI-078Risque(s) - Exécution de co... Lire la suite[+]

Contact

Agence Monégasque de Sécurité Numérique
24 rue du Gabian 
98000 MONACO

AMSN_contact@gouv.mc

Téléphone : (+377) 98 98 24 93
Bouton Alertes CSIRT-MC


       INFORMATIONS            PRATIQUES
Demande d'autorisation loi n°1.383
Conseils élémentaires
//amsn.gouv.mc/Alertes-CERT-MC/AVIS-CERTFR-2021-ALE-0222