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 :
$%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 :
${ (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é.
Il est également intéressant de rechercher les motifs suivants dans les
fichiers journaux des applications :
- 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é.
- 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.