Capitolo: Gibson Cap 8 — Risk Management (Privilege Escalation) Concetti: Unix domain socket, container escape, privilege escalation, chroot, detection lato host
Obiettivo#
Replicare l'escalation da "container con docker.sock montato" a "shell root sull'host" — vederla con le tue mani, non solo leggerla. La teoria e i comandi sono già scritti in docker-sock: qui li fai girare, osservi cosa succede passo per passo, e poi la rilevi dal lato difensore.
Security angle: è esattamente il caso descritto in Privilege Escalation — un tester (o attaccante) parte da un punto di accesso a basso privilegio (un container "qualsiasi") e usa una configurazione errata per ottenere privilegi molto più alti (root sull'host). Il "Homer" di Gibson qui è il container, e il "privilegio in più" è il controllo completo di dockerd.
Career correlation: container/Kubernetes security è una delle 6 responsabilità DevSecOps in CARRIERA.md. Questo è il "Hello World" del container escape — la base per capire perché certi mount, capability o RBAC Kubernetes sono pericolosi.
Ambiente#
- Ubuntu (192.168.64.3): Docker Engine già installato (vedi
sprint-09-wazuh-docker-install) - Solo Docker — non serve Kali per questa parte
Stai per dare a un container il controllo completo del tuo host Docker. Fallo solo su Ubuntu nel tuo lab — mai su una macchina con dati che ti servono. Prima di iniziare, assicurati di sapere come ripristinare/ricreare la VM se qualcosa va storto.
Parte 1 — Setup: il container "vulnerabile"#
Obiettivo: crea un container che monta /var/run/docker.sock dall'host — simula un tool di monitoring mal configurato (stile Portainer/cAdvisor) che non dovrebbe avere quell'accesso in scrittura. La sintassi del mount è in docker-sock.
Come sai che hai finito: docker inspect di quel container mostra il mount di /var/run/docker.sock.
Parte 2 — L'escalation: dal container all'host#
Obiettivo: entra in quel container ed esegui l'escalation che porta a una shell con accesso al filesystem dell'host (la sequenza è già scritta — qui la fai girare e capisci ogni riga). Poi prova concretamente l'accesso: crea un file dal "secondo container" (quello con -v /:/host) e verifica che sia visibile sul filesystem reale dell'host, fuori da qualsiasi isolamento.
Come sai che hai finito: un file creato dall'interno dell'escalation è visibile sull'host — hai rotto l'isolamento del container originale.
Parte 3 — Lato difensore: rilevare l'escalation#
Obiettivo: sull'host, usa i comandi di detection già scritti in docker-sock — ma PRIMA di guardare quale container hai usato, prova a identificarlo solo dall'output. Poi controlla docker events per vedere se la creazione del "secondo container" (quello con -v /:/host) in Parte 2 lascia traccia.
Come sai che hai finito: identifichi correttamente, solo dalla detection, sia il container con docker.sock montato sia il container "figlio" creato durante l'escalation.
Parte 4 (opzionale) — Mitigazione: quanto basta :ro?#
Obiettivo: ripeti Parte 1-2 ma con il mount in modalità :ro (read-only, vedi docker-sock). L'escalation di Parte 2 funziona ancora, parzialmente, o per niente? Cosa cambia esattamente?
Come sai che hai finito: sai dire CONCRETAMENTE cosa :ro blocca e cosa NON blocca — è una mitigazione parziale, non una soluzione, e devi poter spiegare perché.
Collegato a#
- docker-sock — teoria, comandi e scenario Blue Team di questo lab
- Privilege Escalation — il concetto Security+ che questo lab rende concreto
- docker-security — superficie di attacco Docker più ampia
