CVE-2023-43804

Labo conteneurisé à trois niveaux reproduisant la fuite de cookies urllib3 de CVE-2023-43804 via des redirections cross-origin, avec script d'exploitation et vérification du correctif.

• Docker Desktop installé et en cours d'exécution.
• Docker Compose (v2+).
• PowerShell ou tout shell de ligne de commande standard.

3. Étapes d'installation et de configuration

1. Clonez le dépôt et accédez au répertoire du projet :
   root@kitploit:~

   git clone [https://github.com/deepanshu-khurana/cve-2023-43804-lab.git](https://github.com/deepanshu-khurana/cve-2023-43804-lab.git)
   cd cve-2023-43804-lab
   
   
   
   

2. Construisez et démarrez l'infrastructure de laboratoire conteneurisée :

4. Comment démarrer et arrêter le laboratoire

• Démarrer les conteneurs du laboratoire :

• Arrêter le laboratoire et nettoyer les ressources :

5. Aperçu de la vulnérabilité (CVE-2023-43804)

• Composant vulnérable : urllib3
• Versions vulnérables : < 1.26.17 ou < 2.0.5
• Description de la vulnérabilité : urllib3 ne parvenait pas à supprimer les en-têtes d'authentification sensibles (tels que Cookie) lors du suivi des redirections HTTP 302 vers différentes origines, permettant ainsi aux points de redirection non fiables d'intercepter des jetons de session sensibles.

6. Comment exploiter la vulnérabilité (Phase 1)

1. Assurez-vous que la version vulnérable de urllib3 est installée dans le conteneur client :

2. Exécutez le script d'exploitation :

3. Résultat vulnérable attendu :

• La sortie du client affiche "status": "EXFILTRATED" accompagné du jeton de session divulgué.
• docker logs attacker_app affiche l'en-tête de cookie sensible capturé.

7. Comment exécuter le mécanisme de détection et de vérification (Phase 2)

Pour vérifier le correctif après avoir observé l'exploitation :

1. Mettez à niveau urllib3 dans le conteneur client vers la version corrigée :

2. Réexécutez le script d'exploitation :

3. Résultat corrigé attendu :

• La sortie du client affiche "status": "SECURE", "stolen_cookie": "None / Stripped".
• Les journaux de attacker_app confirment que la requête entrante contient Leaked Cookie Header: None.

8. Remédiation

• Mise à niveau de la bibliothèque : Mettez à jour les dépendances dans requirements.txt pour imposer des versions sûres :

• Défense en profondeur : Configurez explicitement les politiques de gestion des en-têtes via remove_headers_on_redirect dans des configurations Retry personnalisées si vous devez maintenir des environnements d'exécution hérités.

9. Notes de dépannage

• Nommage des conteneurs : Assurez-vous de cibler précisément les noms de conteneurs (victim_client, target_app, attacker_app) tels qu'attribués par Docker Compose. Utilisez docker ps pour vérifier les noms des conteneurs actifs.
• Disponibilité des ports : Assurez-vous que les ports 5000 et 5001 ne sont pas occupés par d'autres services locaux avant de lancer la pile Docker.

10. Démonstration du laboratoire et résultats

Phase 1 : État vulnérable (fuite de cookies)

Lors de l'exécution du laboratoire avec la version vulnérable urllib3==1.26.16, le cookie d'authentification sensible est intercepté lors des redirections cross-origin et journalisé avec succès par le serveur attaquant.

• Sortie client et capture des journaux serveur :
  • Figure 1.1 : exploit.py affichant "status": "EXFILTRATED" accompagné du jeton de session divulgué, vérifié par la sortie des journaux de attacker_app.

Phase 2 : Vérification du correctif (état sécurisé)

Après la mise à niveau de urllib3 vers la version corrigée (1.26.17), la bibliothèque supprime automatiquement l'en-tête Cookie sensible lors des redirections cross-origin.

• Mise à niveau du paquet vers la version corrigée :

  • Figure 2.1 : Mise à niveau de urllib3 dans victim_client via pip install urllib3==1.26.17.

• Sortie client sécurisée et journaux épurés :

  • Figure 2.2 : exploit.py renvoyant "status": "SECURE" avec "stolen_cookie": "None / Stripped", confirmé par le journal serveur affichant Leaked Cookie Header: None.