CVE-2023-43804

Lab containerizzato a tre livelli che riproduce la fuga di cookie di urllib3 CVE-2023-43804 tramite redirect cross-origin, con script di exploit e verifica della patch.

• Docker Desktop installato e in esecuzione.
• Docker Compose (v2+).
• PowerShell o qualsiasi shell a riga di comando standard.

3. Passaggi di Installazione e Configurazione

1. Clonare il repository e spostarsi nella directory del progetto:
   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. Compilare e avviare l'infrastruttura containerizzata del laboratorio:

4. Come Avviare e Arrestare il Laboratorio

• Avviare i Container del Laboratorio:

• Arrestare il Laboratorio e Pulire le Risorse:

5. Panoramica della Vulnerabilità (CVE-2023-43804)

• Componente Vulnerabile: urllib3
• Versioni Vulnerabili: < 1.26.17 o < 2.0.5
• Descrizione della Vulnerabilità: urllib3 non riusciva a rimuovere gli header di autenticazione sensibili (come Cookie) quando seguiva redirect HTTP 302 tra origini diverse, consentendo a endpoint di redirezione non attendibili di intercettare token di sessione sensibili.

6. Come Sfruttare la Vulnerabilità (Fase 1)

1. Assicurarsi che la versione vulnerabile di urllib3 sia installata all'interno del container client:

2. Eseguire lo script di exploit:

3. Risultato Vulnerabile Atteso:

• L'output del client mostra "status": "EXFILTRATED" insieme al token di sessione divulgato.
• docker logs attacker_app mostra l'header cookie sensibile catturato.

7. Come Eseguire il Meccanismo di Rilevamento e Verifica (Fase 2)

Per verificare la patch dopo aver osservato l'exploit:

1. Aggiornare urllib3 all'interno del container client alla versione corretta:

2. Rieseguire lo script di exploit:

3. Risultato Corretto Atteso:

• L'output del client mostra "status": "SECURE", "stolen_cookie": "None / Stripped".
• I log di attacker_app confermano che la richiesta in ingresso contiene Leaked Cookie Header: None.

8. Remediation

• Aggiornamento della Libreria: Aggiornare le dipendenze in requirements.txt per imporre versioni sicure:

• Difesa in Profondità: Configurare esplicitamente le politiche di gestione degli header tramite remove_headers_on_redirect in configurazioni Retry personalizzate, se si mantengono runtime legacy.

9. Note di Risoluzione dei Problemi

• Denominazione dei Container: Assicurarsi di fare riferimento ai nomi dei container in modo accurato (victim_client, target_app, attacker_app) come assegnati da Docker Compose. Usare docker ps per verificare i nomi dei container attivi.
• Disponibilità delle Porte: Assicurarsi che le porte 5000 e 5001 non siano occupate da altri servizi locali prima di avviare lo stack Docker.

10. Dimostrazione del Laboratorio e Risultati

Fase 1: Stato Vulnerabile (Cookie Leakage)

Quando si esegue il laboratorio con urllib3==1.26.16 vulnerabile, il cookie di autenticazione sensibile viene intercettato durante i redirect cross-origin e registrato con successo dal server dell'attaccante.

• Output del Client e Cattura dei Log del Server:
  • Figura 1.1: exploit.py che mostra "status": "EXFILTRATED" insieme al token di sessione divulgato, verificato dall'output dei log di attacker_app.

Fase 2: Verifica della Patch (Stato Sicuro)

Dopo aver aggiornato urllib3 alla versione corretta (1.26.17), la libreria rimuove automaticamente l'header Cookie sensibile durante i redirect cross-origin.

• Aggiornamento del Pacchetto alla Versione Corretta:

  • Figura 2.1: Aggiornamento di urllib3 all'interno di victim_client tramite pip install urllib3==1.26.17.

• Output Sicuro del Client e Log Ripuliti:

  • Figura 2.2: exploit.py che restituisce "status": "SECURE" con "stolen_cookie": "None / Stripped", confermato dal log del server che mostra Leaked Cookie Header: None.