amulyakaushik/cve-2023-27163-labLab basato su Docker che riproduce la SSRF CVE-2023-27163 in Request-Baskets, con verifica dell'exploitation, script di rilevamento e remediation tramite isolamento di rete.
Progetto: Laboratorio di Ricerca e Riproduzione di Vulnerabilità — CVE-2023-27163
Autore: Amulya Kaushik
Ruolo: Candidato Tirocinante in Cybersecurity R&S e Sviluppo Contenuti per il Laboratorio
Server-Side Request Forgery in Request-Baskets ≤ 1.2.1
Un laboratorio di ricerca locale autonomo per riprodurre, rilevare e correggere CVE-2023-27163 con un'architettura di difesa in profondità.
| Campo | Valore |
|---|
| CVE ID | CVE-2023-27163 |
| CWE | CWE-918 — Server-Side Request Forgery (SSRF) |
| Prodotto Affetto | Request-Baskets |
| Versioni Affette | ≤ 1.2.1 |
| Versione Corretta | 1.2.2 (Sorgente upstream) / Isolamento di Rete con Difesa in Profondità |
| Punteggio CVSS v3.1 | 6.5 (Medio) |
| Vettore CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
| Complessità di Attacco | Bassa — singola chiamata API non autenticata |
Nota sulle Limitazioni Upstream e la Correzione:
Sebbene CVE-2023-27163 riguardi la validazione arbitraria dell'URL di inoltro, le build pubbliche dei container didarklynx/request-basketsnon applicano il filtraggio del loopback o delle sottoreti private out of the box. Seguendo le migliori pratiche DevSecOps del mondo reale, il nostro laboratorio dimostra la correzione attraverso l'Isolamento di Rete dei Container con Difesa in Profondità. Isolando i backend interni sensibili su una rete Docker solo interna (secure-internal-netconinternal: true), il percorso di relay viene reciso, mitigando la sfruttabilità della vulnerabilità SSRF anche quando si eseguono forwarder di webhook non attendibili.
Questo laboratorio fornisce due topologie Docker Compose distinte:
docker-compose.yml): Request-Baskets e un servizio interno di echo di segreti condividono la rete bridge lab-net. Request-Baskets è mappato sulla porta host 55556 (mappata dalla porta container 55555).docker-compose.patched.yml): Request-Baskets è collegato esclusivamente a public-net, mentre il servizio echo interno è collegato a secure-internal-net (internal: true).docker-compose.yml)┌─────────────────────────────────────────────────────────┐
│ Docker: lab-net │
│ │
│ ┌─────────────────────┐ ┌────────────────────────┐ │
│ │ request-baskets │───▶│ internal-service │ │
│ │ (v1.2.1) │ │ (http-echo:5678) │ │
│ │ Port 55556 ◀──HOST │ │ NOT exposed to host │ │
│ └─────────────────────┘ └────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
▲
│ HTTP (port 55556)
│
┌────┴─────┐
│ Attacker │
└──────────┘
docker-compose.patched.yml)┌─────────────────────────┐ ┌─────────────────────────┐
│ public-net │ │ secure-internal-net │
│ │ │ (internal: true) │
│ ┌───────────────────┐ │ │ ┌───────────────────┐ │
│ │ request-baskets │ │ ✕ │ │ internal-service │ │
│ │ Port 55556◀─HOST │ │ ──/──▶ │ │ (http-echo:5678) │ │
│ └───────────────────┘ │ │ └───────────────────┘ │
└─────────────────────────┘ └─────────────────────────┘
| Requisito | Versione Minima | Note |
|---|---|---|
| Docker Engine | 20.10+ | Runtime di virtualizzazione dei container |
| Docker Compose | v2.0+ | Orchestrazione multi-container |
| Python | 3.8+ | Strumenti CLI di verifica e rilevamento |
Configura l'ambiente virtuale Python e le dipendenze:
python3 -m venv .venv
source .venv/bin/activate
pip install requests fpdf2
Avvia l'ambiente vulnerabile (Request-Baskets v1.2.1 accessibile su http://localhost:55556):
docker compose up -d
Verifica che entrambi i container siano in esecuzione:
docker compose ps
Output atteso:
NAME IMAGE COMMAND SERVICE STATUS PORTS
isolated-internal-service hashicorp/http-echo:latest "/http-echo -text=CO…" internal-service Up 5678/tcp
vulnerable-request-baskets darklynx/request-baskets:v1.2.1 "/bin/sh -c /bin/ent…" request-baskets Up 0.0.0.0:55556->55555/tcp
Conferma che il servizio interno non sia direttamente raggiungibile dall'host:
curl http://localhost:5678 2>&1 || echo "Connection refused — internal service isolated as expected"
Esegui lo script automatizzato di verifica SSRF:
python3 scripts/verify_vulnerability.py
Cosa succede:
/api/baskets/ssrf-verification-basket impostando forward_url: "http://internal-service:5678" e proxy_response: true.CONFIDENTIAL_DATA{INTERNAL_SSRF_DEMONSTRATION_SUCCESS} e restituisce RESULT: VULNERABLE.Esegui la sonda di audit non distruttiva:
python3 scripts/detect.py
Cosa succede:
http://127.0.0.1:80) viene accettato.AUDIT RESULT: VULNERABLE in caso di accettazione (HTTP 201) e pulisce il basket di prova.Passa alla topologia corretta segmentata:
docker compose down
docker compose -f docker-compose.patched.yml up -d
python3 scripts/verify_vulnerability.py
Output atteso:
==============================================================
[✓] REMEDIATION VERIFIED: TARGET SECURED
The Request-Baskets instance failed to reach the internal
isolated service (HTTP 502 / Host Unreachable).
Network segmentation successfully prevented SSRF data exfiltration.
==============================================================
Smonta l'ambiente al termine:
docker compose -f docker-compose.patched.yml down
Il portfolio completo di evidenze visive per il Deliverable 3 è mantenuto nella directory evidence/:
| Artefatto | Scopo | Link al File | Descrizione |
|---|---|---|---|
| Screenshot 1 | Ambiente in Esecuzione | 01_lab_running.png | Mostra vulnerable-request-baskets (porta 55556) e isolated-internal-service in esecuzione simultanea su lab-net. |
| Screenshot 2 | Sfruttamento SSRF | 02_reproduction_ssrf.png | Mostra il flag esfiltrato CONFIDENTIAL_DATA{...} e lo stato VULNERABLE. |
| Screenshot 3 | Strumento di Rilevamento Difensivo | 03_detection_tool_run.png | Mostra il controllo delle firme in due fasi e l'audit loopback che segnala VULNERABLE. |
| Screenshot 4 | Verifica della Correzione | 04_remediation_verified.png | Dimostra il fallimento del relay (HTTP 502 / Host Unreachable) sotto la difesa di rete segmentata. |
| Screenshot 5 | Configurazione Web UI | 05_web_ui_ssrf.png | (Bonus) Cattura browser delle impostazioni dell'interfaccia di Request-Baskets configurate con Proxy Response. |
Procedure dettagliate, comandi e trascrizioni della console per ogni screenshot sono documentati in evidence/README.md.
Per catturare tutti gli screenshot del terminale in sequenza senza complicazioni di configurazione manuale, esegui:
./scripts/capture_evidence_flow.sh
Compila il report tecnico accademico in PDF:
python3 docs/generate_blog_pdf.py
Output generato: docs/CVE-2023-27163-Technical-Blog.pdf
cve-2023-27163-lab/
├── .gitignore # Git artifact exclusions (.venv, cache, OS files)
├── docker-compose.yml # Vulnerable environment (shared lab-net, port 55556)
├── docker-compose.patched.yml # Remediated environment (disjoint network isolation)
├── README.md # Complete documentation, attribution & guide
├── scripts/
│ ├── capture_evidence_flow.sh # Interactive runner for capturing screenshots
│ ├── verify_vulnerability.py # SSRF exploitation & remediation verification CLI
│ └── detect.py # Defensive audit and detection tool
├── evidence/
│ └── README.md # Formal screenshot evidence walkthrough
└── docs/
├── technical_blog.md # Academic technical write-up (800–1,200 words)
├── generate_blog_pdf.py # Markdown → PDF converter
└── CVE-2023-27163-Technical-Blog.pdf # Compiled academic report PDF
Questa ricerca e lo sviluppo del laboratorio si basano su standard di sicurezza aperti, avvisi dei fornitori e database delle vulnerabilità:
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).Questo laboratorio è destinato esclusivamente a scopi educativi e di ricerca sulla sicurezza autorizzata. Non utilizzare questi strumenti contro sistemi di cui non si è proprietari o per i quali non si ha esplicita autorizzazione al test.