amulyakaushik/cve-2023-27163-labDocker-basiertes Lab zur Reproduktion von CVE-2023-27163 SSRF in Request-Baskets, mit Exploit-Verifikation, Erkennungsskript und Netzwerkisolations-Remediation.
Projekt: Vulnerability Research & Reproduction Lab — CVE-2023-27163
Autor: Amulya Kaushik
Rolle: Cybersecurity R&D & Lab Content Development Intern Candidate
Server-Side Request Forgery in Request-Baskets ≤ 1.2.1
Ein eigenständiges lokales Forschungslabor zur Reproduktion, Erkennung und Behebung von CVE-2023-27163 mit Defense-in-Depth-Architektur.
| Feld | Wert |
|---|
| CVE-ID | CVE-2023-27163 |
| CWE | CWE-918 — Server-Side Request Forgery (SSRF) |
| Betroffenes Produkt | Request-Baskets |
| Betroffene Versionen | ≤ 1.2.1 |
| Behobene Version | 1.2.2 (Upstream-Quellcode) / Defense-in-Depth-Netzwerkisolierung |
| CVSS v3.1 Score | 6.5 (Mittel) |
| CVSS-Vektor | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
| Angriffskomplexität | Gering — einzelner unauthentifizierter API-Aufruf |
Hinweis zu Upstream-Einschränkungen & Behebung:
Während CVE-2023-27163 die Validierung beliebiger Forward-URLs betrifft, erzwingen öffentliche Container-Builds vondarklynx/request-basketsnicht standardmäßig eine Loopback- oder Private-Subnet-Filterung. Nach realen DevSecOps-Best-Practices demonstriert unser Labor die Behebung durch Defense-in-Depth-Container-Netzwerkisolierung. Durch die Isolierung sensibler interner Backends in einem rein internen Docker-Netzwerk (secure-internal-netmitinternal: true) wird der Relay-Pfad unterbrochen, wodurch die Ausnutzbarkeit der SSRF-Schwachstelle selbst beim Betrieb nicht vertrauenswürdiger Webhook-Forwarder gemindert wird.
Dieses Labor bietet zwei separate Docker-Compose-Topologien:
docker-compose.yml): Request-Baskets und ein interner Secret-Echo-Service teilen sich das Bridge-Netzwerk lab-net. Request-Baskets ist auf Host-Port 55556 gemappt (gemappt von Container-Port 55555).docker-compose.patched.yml): Request-Baskets ist ausschließlich an public-net angebunden, während der interne Echo-Service an secure-internal-net (internal: true) angebunden ist.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) │ │
│ └───────────────────┘ │ │ └───────────────────┘ │
└─────────────────────────┘ └─────────────────────────┘
| Anforderung | Mindestversion | Hinweise |
|---|---|---|
| Docker Engine | 20.10+ | Container-Virtualisierungslaufzeit |
| Docker Compose | v2.0+ | Multi-Container-Orchestrierung |
| Python | 3.8+ | CLI-Verifikations- und Erkennungstools |
Einrichtung der Python-virtuellen-Umgebung und Abhängigkeiten:
python3 -m venv .venv
source .venv/bin/activate
pip install requests fpdf2
Starten Sie die verwundbare Umgebung (Request-Baskets v1.2.1 erreichbar unter http://localhost:55556):
docker compose up -d
Überprüfen Sie, dass beide Container laufen:
docker compose ps
Erwartete Ausgabe:
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
Bestätigen Sie, dass der interne Service nicht direkt vom Host erreichbar ist:
curl http://localhost:5678 2>&1 || echo "Connection refused — internal service isolated as expected"
Führen Sie das automatisierte SSRF-Verifikationsskript aus:
python3 scripts/verify_vulnerability.py
Was passiert:
/api/baskets/ssrf-verification-basket auf und setzt forward_url: "http://internal-service:5678" sowie proxy_response: true.CONFIDENTIAL_DATA{INTERNAL_SSRF_DEMONSTRATION_SUCCESS} und gibt RESULT: VULNERABLE aus.Führen Sie die nicht-destruktive Audit-Sonde aus:
python3 scripts/detect.py
Was passiert:
http://127.0.0.1:80) akzeptiert wird.AUDIT RESULT: VULNERABLE bei Akzeptanz (HTTP 201) und bereinigt den Probe-Basket.Wechseln Sie zur segmentierten behobenen Topologie:
docker compose down
docker compose -f docker-compose.patched.yml up -d
python3 scripts/verify_vulnerability.py
Erwartete Ausgabe:
==============================================================
[✓] 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.
==============================================================
Bauen Sie die Umgebung nach Abschluss ab:
docker compose -f docker-compose.patched.yml down
Das vollständige visuelle Nachweisportfolio für Deliverable 3 wird im Verzeichnis evidence/ geführt:
| Artefakt | Zweck | Dateilink | Beschreibung |
|---|---|---|---|
| Screenshot 1 | Laufende Umgebung | 01_lab_running.png | Zeigt vulnerable-request-baskets (Port 55556) & isolated-internal-service, die gleichzeitig auf lab-net laufen. |
| Screenshot 2 | SSRF-Ausnutzung | 02_reproduction_ssrf.png | Zeigt die exfiltrierte CONFIDENTIAL_DATA{...}-Flag und den Status VULNERABLE. |
| Screenshot 3 | Defensives Erkennungstool | 03_detection_tool_run.png | Zeigt die zweiphasige Signaturprüfung und das Loopback-Audit, das VULNERABLE meldet. |
| Screenshot 4 | Behebungsverifikation | 04_remediation_verified.png | Beweist Relay-Fehler (HTTP 502 / Host Unreachable) unter segmentierter Netzwerkverteidigung. |
| Screenshot 5 | Web-UI-Konfiguration | 05_web_ui_ssrf.png | (Bonus) Browser-Aufnahme der Request-Baskets-UI-Einstellungen mit konfiguriertem Proxy Response. |
Detaillierte Walkthroughs, Befehle und Konsolen-Transkripte für jeden Screenshot sind in evidence/README.md dokumentiert.
Um alle Terminal-Screenshots sequenziell ohne manuellen Aufwand zu erfassen, führen Sie aus:
./scripts/capture_evidence_flow.sh
Kompilieren Sie den akademischen technischen Bericht in PDF:
python3 docs/generate_blog_pdf.py
Generierte Ausgabe: 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
Diese Forschung und Laborentwicklung baut auf offenen Sicherheitsstandards, Herstellerhinweisen und Schwachstellendatenbanken auf:
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).Dieses Labor ist ausschließlich für Bildungs- und autorisierte Sicherheitsforschungszwecke bestimmt. Verwenden Sie diese Tools nicht gegen Systeme, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Testgenehmigung haben.