Laboratoire d'exploitation Log4Shell (CVE-2021-44228)

Reproduction de la vulnérabilité Log4Shell de bout en bout dans un environnement de laboratoire isolé, de l'exploitation initiale jusqu'à un rapport de remédiation complet. Réalisé dans le cadre d'un travail de master en binôme avec Aditya Chaudhari, rédigé ensemble sous forme de rapport conjoint.

Ce que j'ai fait

• Mis en place une application web Tomcat vulnérable basée sur Log4j dans un conteneur Docker
• Écrit un script Python pour générer la charge utile d'exploitation, puis déployé un serveur LDAP malveillant et un serveur HTTP pour la servir
• Déclenché la chaîne d'injection JNDI en envoyant une chaîne de recherche forgée, puis capturé le reverse shell résultant avec netcat et confirmé l'accès root
• Reconstruit le même conteneur avec un Dockerfile durci (lookups JNDI désactivés via JAVA_OPTS) et confirmé que l'exploit ne fonctionnait plus
• Rédigé un rapport de vulnérabilité structuré couvrant la cause racine, l'historique des correctifs et les mesures d'atténuation au niveau réseau, le genre de document que l'on remettrait réellement à un client ou à une équipe de développement

Pourquoi j'ai procédé ainsi

Je voulais comprendre moi-même la chaîne d'exploitation complète plutôt que de simplement lire à ce sujet. Log4Shell est une bonne vulnérabilité pour apprendre car elle touche à la fois le chargement de classes Java, LDAP et JNDI, et l'histoire des correctifs qui a suivi vous apprend ce qu'est réellement la remédiation au-delà de la simple application d'une mise à jour.

Captures d'écran