Lab Docker pour l'exploitation par traversée de chemin et RCE d'Apache CVE-2021-41773 avec script d'exploitation Python, démontrant l'analyse de vulnérabilités et les stratégies d'atténuation.
Ce dépôt reproduit une vulnérabilité publiquement divulguée et corrigée dans un environnement Docker de laboratoire contrôlé à des fins éducatives et de recherche.
L'environnement est intentionnellement vulnérable et ne doit être déployé que dans des environnements de test isolés. Ne tentez pas d'exploiter des systèmes sans autorisation explicite.
L'objectif de ce projet est de démontrer l'analyse des vulnérabilités, l'exploitation et les stratégies d'atténuation.
Traversée de chemin et exécution de code à distance
# Naviguer vers le dossier du projet
cd Apache-CVE-2021-41773
# Valider la syntaxe du fichier compose
docker compose config
# Démarrer le laboratoire
docker compose up -d --build
# Vérifier que tout tourne
docker compose ps
Apache 2.4.49 a introduit un bogue dans la normalisation des chemins d'URL. Les séquences encodées comme .%2e (équivalent à ..) ne sont pas correctement nettoyées, permettant à un attaquant de parcourir l'arborescence des répertoires au-delà de DocumentRoot.
Si mod_cgi est activé et que le répertoire racine (/) est configuré avec Require all granted, un attaquant peut :
/bin/sh (RCE)exploit.py)Aucune dépendance externe — utilise uniquement la bibliothèque standard Python.
Auto python exploit.py Vérifie la vulnérabilité et exécute id en démo
Lire un fichier python exploit.py -f /etc/shadow Lit n'importe quel fichier via RCE
RCE python exploit.py -c "whoami" Exécute une seule commande
Shell python exploit.py -i Pseudo-shell interactif
Cible personnalisée python exploit.py -u http://cible:8888 Cible un hôte distant
D'abord, nous vérifions que l'environnement est vulnérable
Comme prévu, la commande retourne l'identifiant uid=0(root) gid=0(root) groups=0(root)
Créons un shell inversé :
Nous sommes connectés en tant que root
Comme vous pouvez le voir, il y a une mauvaise configuration sur /proc/1/environ, nous avons obtenu le mot de passe SQL Cela révèle des secrets exposés causés par une configuration de conteneur non sécurisée
En utilisant les identifiants extraits, nous nous connectons à la base de données MySQL et affichons les données stockées
Ne reproduisez jamais ces configurations dans un environnement de production.