Log4Shell : pourquoi cette vulnérabilité provoque un tel émoi

Qui est concerné ?

Les versions 2.0 beta 9 à 2.14.1 de log4j sont affectées. La mise à jour 2.15.0 corrige la vulnérabilité. Les versions antérieures de log4j ne sont pas concernées par cette vulnérabilité, une bonne nouvelle pour tous ceux qui les utilisent encore. À moins que le composant JMS Appender ne soit configuré pour prendre en compte JNDI, explique le Cert-FR.

Las, beaucoup d’entreprises sont probablement concernées par la vulnérabilité Log4Shell sans le savoir : il suffit qu’elles soient utilisatrices d’un produit mettant à profit la bibliothèque log4j. C’est par exemple le cas de nombreux produits signés Cisco, Splunk, VMware, ou encore CyberArk, F-Secure et Fortinet, pour n’en citer que quelques-uns. Le chercheur SwitHack tient à jour une liste des notices d’information publiées par les éditeurs et équipementiers.

Mais l’emploi d’une version vulnérable de log4j n’implique pas systématiquement d’être menacé par une éventuelle exploitation de la vulnérabilité. Comme le précise le Cert-CH, le fait que la vulnérabilité puisse être effectivement exploitée « dépend de plusieurs pré- et post-conditions telles que la JVM utilisée, la configuration, etc. ». Les applications fonctionnant avec des versions de Java antérieures aux 8u191, 7u201, 6u211 et 11.1 sont particulièrement affectées.

D’où vient cette vulnérabilité ?

Cette vulnérabilité est liée à un package appelé JNDILookup plugin. JNDI signifie Java Naming and Directory Interface. Le composant JNDILookup fournit une interface permettant aux applications log4j d’interagir avec des annuaires.

La vulnérabilité CVE-2021-44228 a été tout récemment rendue publique, mais le vecteur d’attaque associé avait été identifié il y a plusieurs années. Lors de l’édition 2016 de la conférence BlackHat, deux chercheurs de HPE Fortify, Alavaro Muñoz et Oleksandr Mirosh l’avaient expliqué en détail. Avec une conclusion : « les applications ne devraient jamais lancer des requêtes JNDI avec des données n’étant pas de confiance ». Rétrospectivement, leurs travaux pourraient presque passer pour prémonitoires.

Quel peut être le cheminement de l’attaque ?

L’attaquant doit exposer, sur Internet, un serveur LDAP malicieux. Ce serveur abritera le code malveillant à exécuter sur les systèmes Java vulnérables. Pour exploiter Log4Shell, l’attaquant doit réussir à faire passer à l’instance log4j affectée une chaîne de caractères spécifique déclenchant l’appel JNDI, à destination du serveur d’annuaire malicieux. Sollicité, ce dernier renverra une charge utile malveillante qui devra ensuite être traitée et exécutée par la machine virtuelle Java.

Et les « endroits » où poser un piège pour exploiter la vulnérabilité ne manquent pas, comme le souligne Greylock : « le fichier robots.txt à la racine de votre site, le fichier security.txt à la racine de votre site, vos enregistrements DNS de type “TXT”, certains en-têtes des mails que vous envoyez », etc.

Cette cinétique d’attaque signifie que les systèmes exposés directement sur Internet sont concernés, mais aussi ceux qui ne le sont pas : il suffit que la chaîne de caractère déclenchant l’appel JNDI puisse remonter jusqu’au système de journalisation affecté. Et que les communications vers des serveurs LDAP externes soient possibles.

Des attaques déjà observées ?

Des attaques exploitant la vulnérabilité CVE-2021-44228 ont déjà eu lieu, conduisant au déploiement de logiciels malveillants tels que Kinsing, Mirai ou encore Muhstik. Le premier est un mineur de cryptopépettes ; les deux autres sont des botnets bien connus.

Mais selon les équipes de Microsoft, Log4Shell a également déjà été utilisé pour installer des balises Cobalt Strike. Celles-ci sont notamment fréquemment utilisées dans le cadre des activités de déplacement latéral préalable à la détonation de ransomware. GreyNoise fait également état de charges utiles malicieuses sur mesure pour certaines applications.

Mais les activités offensives autour de la vulnérabilité de log4j pourraient avoir commencé avant qu’elle n’ait été rendue publique. Matthew Prince, PDG de Cloudflare, indique ainsi avoir trouvé des traces de tentative d’exploitation remontant au premier décembre.

Comment se protéger ?

Cette donnée chronologique souligne l’importance de chercher des traces de tentatives d’exploitation de la vulnérabilité Log4Shell antérieures à sa divulgation. L’expert Florian Roth a développé un outil Python d’analyse de fichiers de journalisation pour chercher les tentatives d’exploitation.

La meilleure protection est assurément l’application des correctifs disponibles. Lorsque c’est impossible, un changement de configuration permet d’immuniser son instance de log4j. Cybereason a également mis à disposition un outil permettant d’immuniser ses serveurs, comme s’ils étaient attaqués.

NCC Group propose de son côté des règles de détection pour les tentatives d’attaque. Abuse tient à jour une liste de serveurs LDAP malicieux, mais ce n’est pas la seule. Au moins deux autres sont disponibles ici et là.