CVE-2023-43804

Laboratorio contenedorizado de tres niveles que reproduce la fuga de cookies de urllib3 CVE-2023-43804 mediante redirecciones de origen cruzado, con script de explotación y verificación del parche.

• Docker Desktop instalado y en ejecución.
• Docker Compose (v2+).
• PowerShell o cualquier shell de línea de comandos estándar.

3. Pasos de Instalación y Configuración

1. Clone el repositorio y navegue hasta el directorio del proyecto:
   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. Construya y levante la infraestructura del laboratorio contenerizado:

4. Cómo Iniciar y Detener el Laboratorio

• Iniciar Contenedores del Laboratorio:

• Detener el Laboratorio y Limpiar Recursos:

5. Descripción General de la Vulnerabilidad (CVE-2023-43804)

• Componente Vulnerable: urllib3
• Versiones Vulnerables: < 1.26.17 o < 2.0.5
• Descripción de la Vulnerabilidad: urllib3 no eliminaba los encabezados de autenticación sensibles (como Cookie) al seguir redirecciones HTTP 302 entre diferentes orígenes, lo que permitía que los puntos de redirección no confiables interceptaran tokens de sesión sensibles.

6. Cómo Explotar la Vulnerabilidad (Fase 1)

1. Asegúrese de que la versión vulnerable de urllib3 esté instalada dentro del contenedor cliente:

2. Ejecute el script de explotación:

3. Resultado Vulnerable Esperado:

• La salida del cliente muestra "status": "EXFILTRATED" junto con el token de sesión filtrado.
• docker logs attacker_app muestra el encabezado de cookie sensible capturado.

7. Cómo Ejecutar el Mecanismo de Detección y Verificación (Fase 2)

Para verificar el parche después de observar la explotación:

1. Actualice urllib3 dentro del contenedor cliente a la versión parcheada:

2. Vuelva a ejecutar el script de explotación:

3. Resultado Parcheado Esperado:

• La salida del cliente muestra "status": "SECURE", "stolen_cookie": "None / Stripped".
• Los registros de attacker_app confirman que la solicitud entrante contiene Leaked Cookie Header: None.

8. Remediación

• Actualización de la Biblioteca: Actualice las dependencias en requirements.txt para forzar versiones seguras:

• Defensa en Profundidad: Configure explícitamente las políticas de gestión de encabezados mediante remove_headers_on_redirect en configuraciones personalizadas de Retry si se mantienen tiempos de ejecución heredados.

9. Notas de Solución de Problemas

• Nombres de Contenedores: Asegúrese de apuntar a los nombres de contenedores con precisión (victim_client, target_app, attacker_app) tal como los asigna Docker Compose. Use docker ps para verificar los nombres de contenedores activos.
• Disponibilidad de Puertos: Asegúrese de que los puertos 5000 y 5001 no estén ocupados por otros servicios locales antes de lanzar el stack de Docker.

10. Demostración del Laboratorio y Resultados

Fase 1: Estado Vulnerable (Fuga de Cookies)

Al ejecutar el laboratorio con urllib3==1.26.16 vulnerable, la cookie de autenticación sensible es interceptada a través de redirecciones de origen cruzado y registrada exitosamente por el servidor atacante.

• Salida del Cliente y Captura de Registros del Servidor:
  • Figura 1.1: exploit.py mostrando "status": "EXFILTRATED" junto con el token de sesión filtrado, verificado por la salida del registro de attacker_app.

Fase 2: Verificación del Parche (Estado Seguro)

Después de actualizar urllib3 a la versión parcheada (1.26.17), la biblioteca elimina automáticamente el encabezado Cookie sensible durante las redirecciones de origen cruzado.

• Actualización del Paquete a la Versión Parcheada:

  • Figura 2.1: Actualización de urllib3 dentro de victim_client mediante pip install urllib3==1.26.17.

• Salida Segura del Cliente y Registros Eliminados:

  • Figura 2.2: exploit.py devolviendo "status": "SECURE" con "stolen_cookie": "None / Stripped", confirmado por el registro del servidor que muestra Leaked Cookie Header: None.