Comment fonctionne l'exploit

1. L'application victime journalise une entrée fournie par l'attaquant à partir d'un en-tête HTTP.
2. Le serveur LDAP de l'attaquant répond avec une référence à Exploit.class.
3. La victime récupère Exploit.class via HTTP.
4. L'initialiseur statique dans Exploit s'exécute, générant un reverse shell vers l'attaquant.

2. Risque

• Impact : RCE sans authentification - sévérité la plus élevée possible.

• Qui / quoi est à risque :

  • Toute application Java utilisant Log4j <= 2.14.1.
  • Les services exposés sur Internet et les services internes qui journalisent les entrées contrôlées par l'utilisateur (par exemple, les en-têtes HTTP).

• Conséquences :

  • Compromission du système (accès shell).
  • Exfiltration de données.
  • Pivotement vers les réseaux internes.
  • Contournement des défenses périmétriques (attaques via les services internes).

3. Preuve de concept

Prérequis

1. docker + docker-compose
2. netcat
3. make

Construire et démarrer

Exploit

1. Démarrer un écouteur netcat :

2. Déclencher l'exploit :

3. Netcat reçoit un reverse shell de la victime :

4. Remédiation

Correctif préféré

• Mettre à niveau vers Log4j 2.17.1 ou version ultérieure.
• C'est le seul correctif complet et à long terme. Les versions antérieures ont été corrigées partiellement mais laissaient encore des expositions :
  • CVE-2021-45046 : RCE via une configuration de journalisation non par défaut
  • CVE-2021-45105 : déni de service via des lookups auto-référentiels
  • CVE-2021-44832 : RCE via certaines configurations d'appender JDBC

Atténuations temporaires (si la mise à niveau n'est pas possible)

1. Gagner du temps

• Restreindre les chaînes d'exploitation entrantes (modèles ${jndi:) avec un WAF ou un middleware.
• Restreindre le trafic LDAP sortant des serveurs d'application avec un filtrage de sortie.

2. Désactiver les lookups :

3. Durcir la JVM :

Atténuations opérationnelles

1. Auditer les dépendances et l'environnement d'exécution

• Générer un SBOM (gradle dependencies, Snyk, Wiz, etc.).
• Rechercher les log4j-core-*.jar dans les images/serveurs déployés, y compris les fat JARs.
• Effectuer le tri et prioriser les mesures d'atténuation pour les charges de travail les plus risquées.

2. Surveiller et détecter

• Surveiller les tentatives d'exploitation dans les journaux (${jndi:...}, ${${lower:j}ndi:...}, etc.).
• Surveiller le trafic LDAP sortant pour détecter des callbacks.
• Traiter les découvertes comme des compromissions potentielles, escalader pour la réponse à incident (investigation forensique, suppression des artefacts malveillants, rotation des secrets, etc.).

3. Correctifs des fournisseurs

• Suivre les avis de sécurité des fournisseurs (par exemple, Elasticsearch) - beaucoup embarquent un Log4j intégré.
• Appliquer les hotfixes ou solutions de contournement fournis jusqu'à ce que des correctifs officiels soient disponibles.

4. Améliorations stratégiques

• Appliquer une politique de refus par défaut pour le filtrage du trafic sortant.
• Imposer l'analyse des dépendances dans le CI/CD.
• Formaliser les playbooks de réponse pour que les équipes sachent exactement quoi faire lors de la prochaine vulnérabilité « 10.0 CVSS ».
• Mener des exercices de résilience / exercices de table pour tester la préparation à un incident de type « nouvelle Log4Shell ».

5. Références

• Avis de sécurité Apache