Docker Breakout / Privilege Escalation
Impara e pratica l'Hacking su AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking su GCP:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=8a381701&sv=1)
Usa Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:
Enumerazione Automatica & Fuga
linpeas: Può anche enumerare i container
CDK: Questo strumento è abbastanza utile per enumerare il container in cui ti trovi e provare a fuggire automaticamente
amicontained: Strumento utile per ottenere i privilegi che il container ha al fine di trovare modi per fuggirne
deepce: Strumento per enumerare e fuggire dai container
grype: Ottieni i CVE contenuti nel software installato nell'immagine
Fuga dal Socket Docker Montato
Se in qualche modo scopri che il socket docker è montato all'interno del container docker, sarai in grado di fuggirne. Questo di solito accade nei container docker che per qualche motivo devono connettersi al demone docker per eseguire azioni.
In questo caso puoi utilizzare i comandi docker regolari per comunicare con il demone docker:
Nel caso in cui il socket di Docker si trovi in un posto inaspettato, è comunque possibile comunicare con esso utilizzando il comando docker
con il parametro -H unix:///percorso/a/docker.sock
Il demone Docker potrebbe anche essere in ascolto su una porta (di default 2375, 2376) o nei sistemi basati su Systemd, la comunicazione con il demone Docker può avvenire tramite il socket Systemd fd://
.
Inoltre, prestare attenzione ai socket di runtime di altri runtime di alto livello:
dockershim:
unix:///var/run/dockershim.sock
containerd:
unix:///run/containerd/containerd.sock
cri-o:
unix:///var/run/crio/crio.sock
frakti:
unix:///var/run/frakti.sock
rktlet:
unix:///var/run/rktlet.sock
...
Fuga dall'Abuso delle Capacità
Dovresti controllare le capacità del container, se ha una qualsiasi delle seguenti, potresti essere in grado di evadere da esso: CAP_SYS_ADMIN
, CAP_SYS_PTRACE
, CAP_SYS_MODULE
, DAC_READ_SEARCH
, DAC_OVERRIDE, CAP_SYS_RAWIO
, CAP_SYSLOG
, CAP_NET_RAW
, CAP_NET_ADMIN
Puoi controllare le capacità attuali del container utilizzando gli strumenti automatici precedentemente menzionati o:
Nella seguente pagina puoi saperne di più sulle capacità di Linux e su come abusarne per evadere/aumentare i privilegi:
Linux CapabilitiesFuga da Container Privilegiati
Un container privilegiato può essere creato con il flag --privileged
o disabilitando specifiche difese:
--cap-add=ALL
--security-opt apparmor=unconfined
--security-opt seccomp=unconfined
--security-opt label:disable
--pid=host
--userns=host
--uts=host
--cgroupns=host
Montare /dev
Il flag --privileged
abbassa significativamente la sicurezza del container, offrendo accesso illimitato ai dispositivi e aggirando diverse protezioni. Per una panoramica dettagliata, consulta la documentazione sugli impatti completi di --privileged
.
Privileged + hostPID
Con questi permessi puoi semplicemente passare allo spazio dei nomi di un processo in esecuzione nell'host come root come init (pid:1) eseguendo: nsenter --target 1 --mount --uts --ipc --net --pid -- bash
Provalo in un container eseguendo:
Privileged
Solo con il flag privilegiato puoi provare ad accedere al disco dell'host o provare a scappare abusando di release_agent o di altre falle.
Testa i seguenti bypass in un container eseguendo:
Montaggio del disco - Poc1
I container Docker ben configurati non permetteranno comandi come fdisk -l. Tuttavia, su un comando Docker mal configurato in cui viene specificato il flag --privileged
o --device=/dev/sda1
con le capacità, è possibile ottenere i privilegi per visualizzare il drive dell'host.
Quindi, per prendere il controllo della macchina host, è banale:
Ecco a te! Ora puoi accedere al filesystem dell'host perché è montato nella cartella /mnt/hola
.
Montaggio Disco - Poc2
All'interno del container, un attaccante potrebbe tentare di ottenere ulteriore accesso al sistema operativo sottostante dell'host tramite un volume hostPath scrivibile creato dal cluster. Di seguito sono riportate alcune cose comuni che puoi controllare all'interno del container per vedere se puoi sfruttare questo vettore dell'attaccante:
Fuga di privilegi sfruttando l'agent di rilascio esistente (cve-2022-0492) - PoC1
Fuga di privilegi sfruttando il release_agent creato (cve-2022-0492) - PoC2
Trova una spiegazione della tecnica in:
Docker release_agent cgroups escapeFuga privilegiata sfruttando release_agent senza conoscere il percorso relativo - PoC3
Nei precedenti exploit viene rivelato il percorso assoluto del container all'interno del filesystem dell'host. Tuttavia, questo non è sempre il caso. Nei casi in cui non si conosce il percorso assoluto del container all'interno dell'host è possibile utilizzare questa tecnica:
release_agent exploit - Relative Paths to PIDsEseguire il PoC all'interno di un container privilegiato dovrebbe fornire un output simile a:
Fuga di privilegi sfruttando i mount sensibili
Ci sono diversi file che potrebbero essere montati che forniscono informazioni sull'host sottostante. Alcuni di essi potrebbero addirittura indicare qualcosa da eseguire dall'host quando accade qualcosa (il che permetterà a un attaccante di fuggire dal container). L'abuso di questi file potrebbe permettere che:
release_agent (già trattato in precedenza)
Tuttavia, puoi trovare altri file sensibili da controllare in questa pagina:
Sensitive MountsMount arbitrari
In diverse occasioni potresti scoprire che il container ha alcuni volumi montati dall'host. Se questo volume non è stato configurato correttamente, potresti essere in grado di accedere/modificare dati sensibili: Leggere segreti, cambiare ssh authorized_keys...
Escalation dei privilegi con 2 shell e mount dell'host
Se hai accesso come root all'interno di un container che ha una cartella dell'host montata e sei scappato come utente non privilegiato sull'host e hai accesso in lettura sulla cartella montata. Puoi creare un file bash suid nella cartella montata all'interno del container e eseguirlo dall'host per ottenere privilegi elevati.
Escalation dei privilegi con 2 shell
Se hai accesso come root all'interno di un container e sei scappato come utente non privilegiato all'host, puoi abusare di entrambe le shell per escalare i privilegi all'interno dell'host se hai la capacità MKNOD all'interno del container (è di default) come spiegato in questo post. Con tale capacità, all'utente root all'interno del container è consentito creare file di dispositivo a blocchi. I file di dispositivo sono file speciali utilizzati per accedere all'hardware sottostante e ai moduli del kernel. Ad esempio, il file di dispositivo a blocchi /dev/sda fornisce accesso per leggere i dati grezzi sul disco del sistema.
Docker protegge dall'abuso dei dispositivi a blocchi all'interno dei container applicando una politica cgroup che blocca le operazioni di lettura/scrittura sui dispositivi a blocchi. Tuttavia, se un dispositivo a blocchi viene creato all'interno del container, diventa accessibile dall'esterno del container tramite la directory /proc/PID/root/. Questo accesso richiede che il proprietario del processo sia lo stesso sia all'interno che all'esterno del container.
Esempio di sfruttamento da questo articolo:
hostPID
Se puoi accedere ai processi dell'host, sarai in grado di accedere a molte informazioni sensibili memorizzate in quei processi. Esegui il laboratorio di test:
Per esempio, sarai in grado di elencare i processi utilizzando qualcosa del genere ps auxn
e cercare dettagli sensibili nei comandi.
Quindi, poiché puoi accedere a ciascun processo dell'host in /proc/, puoi semplicemente rubare i loro segreti dell'ambiente eseguendo:
Puoi anche accedere ai descrittori file di altri processi e leggere i file aperti da essi:
Puoi anche uccidere processi e causare un DoS.
Se in qualche modo hai accesso privilegiato su un processo al di fuori del container, potresti eseguire qualcosa come nsenter --target <pid> --all
o nsenter --target <pid> --mount --net --pid --cgroup
per eseguire una shell con le stesse restrizioni ns (sperabilmente nessuna) di quel processo.
hostNetwork
Se un container è configurato con il driver di rete host di Docker (--network=host
), lo stack di rete di quel container non è isolato dall'host Docker (il container condivide lo spazio dei nomi di rete dell'host) e al container non viene assegnato un proprio indirizzo IP. In altre parole, il container associa tutti i servizi direttamente all'IP dell'host. Inoltre, il container può intercettare TUTTO il traffico di rete che l'host sta inviando e ricevendo sull'interfaccia condivisa tcpdump -i eth0
.
Ad esempio, è possibile utilizzare questo metodo per intercettare e persino falsificare il traffico tra l'host e l'istanza dei metadati.
Come nei seguenti esempi:
Sarà anche possibile accedere ai servizi di rete associati a localhost all'interno dell'host o persino accedere alle autorizzazioni dei metadati del nodo (che potrebbero essere diverse da quelle a cui un container può accedere).
hostIPC
Con hostIPC=true
, si ottiene accesso alle risorse di comunicazione inter-processo (IPC) dell'host, come la memoria condivisa in /dev/shm
. Ciò consente la lettura/scrittura dove le stesse risorse IPC sono utilizzate da altri processi dell'host o del pod. Utilizzare ipcs
per ispezionare ulteriormente questi meccanismi IPC.
Ispeziona /dev/shm - Cerca eventuali file in questa posizione di memoria condivisa:
ls -la /dev/shm
Ispeziona le strutture IPC esistenti - È possibile verificare se vengono utilizzate strutture IPC con
/usr/bin/ipcs
. Controlla con:ipcs -a
Recupera le capacità
Se la chiamata di sistema unshare
non è vietata, è possibile recuperare tutte le capacità eseguendo:
Abuso dello spazio utente tramite symlink
La seconda tecnica spiegata nel post https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/ indica come è possibile abusare dei bind mounts con i namespace utente, per influenzare i file all'interno dell'host (in quel caso specifico, eliminare file).
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=8a381701&sv=1)
Utilizza Trickest per costruire facilmente e automatizzare flussi di lavoro supportati dagli strumenti della comunità più avanzati al mondo. Ottieni l'accesso oggi:
CVE
Exploit di Runc (CVE-2019-5736)
Nel caso in cui tu possa eseguire docker exec
come root (probabilmente con sudo), puoi provare a elevare i privilegi sfuggendo da un container abusando di CVE-2019-5736 (exploit qui). Questa tecnica sovrascriverà essenzialmente il binario /bin/sh dell'host da un container, quindi chiunque esegua docker exec potrebbe attivare il payload.
Modifica il payload di conseguenza e compila il main.go con go build main.go
. Il binario risultante dovrebbe essere posizionato nel container Docker per l'esecuzione.
All'esecuzione, non appena visualizza [+] Sovrascritto /bin/sh con successo
, è necessario eseguire quanto segue dalla macchina host:
docker exec -it <nome-container> /bin/sh
Questo attiverà il payload presente nel file main.go.
Per ulteriori informazioni: https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
Il container potrebbe essere vulnerabile anche ad altre CVE, puoi trovare un elenco su https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list
Fuga personalizzata da Docker
Superficie di fuga di Docker
Namespace: Il processo dovrebbe essere completamente separato dagli altri processi tramite namespace, quindi non possiamo sfuggire interagendo con altri processi a causa dei namespace (per impostazione predefinita non può comunicare tramite IPC, socket Unix, servizi di rete, D-Bus,
/proc
di altri processi).Utente root: Per impostazione predefinita, l'utente che esegue il processo è l'utente root (tuttavia i suoi privilegi sono limitati).
Capacità: Docker lascia le seguenti capacità:
cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
Syscall: Questi sono i syscall che l'utente root non potrà chiamare (a causa della mancanza di capacità + Seccomp). Gli altri syscall potrebbero essere utilizzati per cercare di sfuggire.
Container Breakout through Usermode helper Template
If you are in userspace (no kernel exploit involved) the way to find new escapes mainly involve the following actions (these templates usually require a container in privileged mode):
Find the path of the containers filesystem inside the host
You can do this via mount, or via brute-force PIDs as explained in the second release_agent exploit
Find some functionality where you can indicate the path of a script to be executed by a host process (helper) if something happens
You should be able to execute the trigger from inside the host
You need to know where the containers files are located inside the host to indicate a script you write inside the host
Have enough capabilities and disabled protections to be able to abuse that functionality
You might need to mount things o perform special privileged actions you cannot do in a default docker container
References
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F197708944-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FE5VfhVAq0qYsgU9deMR8%252Fuploads%252Fgit-blob-78abb7891633b1e8147b4e743e4f00af375d3cd6%252Fimage%2520%2848%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=8a381701&sv=1)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated