AuthZ& AuthN - Docker Access Authorization Plugin
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Il modello di autorizzazione di Docker è tutto o niente. Qualsiasi utente con permesso di accedere al demone Docker può eseguire qualsiasi comando del client Docker. Lo stesso vale per i chiamanti che utilizzano l'API Engine di Docker per contattare il demone. Se hai bisogno di maggiore controllo degli accessi, puoi creare plugin di autorizzazione e aggiungerli alla configurazione del tuo demone Docker. Utilizzando un plugin di autorizzazione, un amministratore Docker può configurare politiche di accesso granulari per gestire l'accesso al demone Docker.
I plugin di autorizzazione Docker sono plugin esterni che puoi utilizzare per consentire/nnegare azioni richieste al demone Docker a seconda dell'utente che le ha richieste e dell'azione richiesta.
Le seguenti informazioni provengono dalla documentazione
Quando viene effettuata una richiesta HTTP al demone Docker tramite la CLI o tramite l'API Engine, il sottosistema di autenticazione trasmette la richiesta ai plugin di autenticazione installati. La richiesta contiene l'utente (chiamante) e il contesto del comando. Il plugin è responsabile della decisione di consentire o negare la richiesta.
I diagrammi di sequenza qui sotto mostrano un flusso di autorizzazione di consenso e di negazione:
Ogni richiesta inviata al plugin include l'utente autenticato, le intestazioni HTTP e il corpo della richiesta/risposta. Solo il nome utente e il metodo di autenticazione utilizzato vengono passati al plugin. È importante notare che nessuna credenziale o token dell'utente vengono passati. Infine, non tutti i corpi di richiesta/risposta vengono inviati al plugin di autorizzazione. Solo quei corpi di richiesta/risposta in cui il Content-Type è text/* o application/json vengono inviati.
Per i comandi che possono potenzialmente dirottare la connessione HTTP (HTTP Upgrade), come exec, il plugin di autorizzazione viene chiamato solo per le richieste HTTP iniziali. Una volta che il plugin approva il comando, l'autorizzazione non viene applicata al resto del flusso. In particolare, i dati in streaming non vengono passati ai plugin di autorizzazione. Per i comandi che restituiscono risposte HTTP a chunk, come logs ed events, solo la richiesta HTTP viene inviata ai plugin di autorizzazione.
Durante l'elaborazione della richiesta/risposta, alcuni flussi di autorizzazione potrebbero aver bisogno di eseguire query aggiuntive al demone Docker. Per completare tali flussi, i plugin possono chiamare l'API del demone in modo simile a un utente normale. Per abilitare queste query aggiuntive, il plugin deve fornire i mezzi per un amministratore per configurare politiche di autenticazione e sicurezza adeguate.
Sei responsabile della registrazione del tuo plugin come parte dell'avvio del demone Docker. Puoi installare più plugin e concatenarli. Questa catena può essere ordinata. Ogni richiesta al demone passa in ordine attraverso la catena. Solo quando tutti i plugin concedono accesso alla risorsa, l'accesso viene concesso.
Il plugin authz ti consente di creare un semplice file JSON che il plugin leggerà per autorizzare le richieste. Pertanto, ti offre l'opportunità di controllare molto facilmente quali endpoint API possono raggiungere ciascun utente.
Questo è un esempio che consentirà ad Alice e Bob di creare nuovi contenitori: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
Nella pagina route_parser.go puoi trovare la relazione tra l'URL richiesto e l'azione. Nella pagina types.go puoi trovare la relazione tra il nome dell'azione e l'azione.
Puoi trovare un plugin facile da capire con informazioni dettagliate su installazione e debug qui: https://github.com/carlospolop-forks/authobot
Leggi il README e il codice di plugin.go per capire come funziona.
Le principali cose da controllare sono quali endpoint sono consentiti e quali valori di HostConfig sono consentiti.
Per eseguire questa enumerazione puoi utilizzare lo strumento https://github.com/carlospolop/docker_auth_profiler.
run --privileged non consentitoIn questo caso, l'amministratore di sistema ha vietato agli utenti di montare volumi e di eseguire container con il flag --privileged o di dare ulteriori capacità al container:
Tuttavia, un utente può creare una shell all'interno del container in esecuzione e darle i privilegi extra:
Ora, l'utente può uscire dal container utilizzando una delle tecniche precedentemente discusse e escalare i privilegi all'interno dell'host.
In questo caso, l'amministratore di sistema ha vietato agli utenti di eseguire container con il flag --privileged o di dare qualsiasi capacità extra al container, e ha solo consentito di montare la cartella /tmp:
Nota che forse non puoi montare la cartella /tmp, ma puoi montare una cartella scrivibile diversa. Puoi trovare directory scrivibili usando: find / -writable -type d 2>/dev/null
Nota che non tutte le directory in una macchina linux supporteranno il bit suid! Per controllare quali directory supportano il bit suid esegui mount | grep -v "nosuid" Ad esempio, di solito /dev/shm, /run, /proc, /sys/fs/cgroup e /var/lib/lxcfs non supportano il bit suid.
Nota anche che se puoi montare /etc o qualsiasi altra cartella contenente file di configurazione, puoi modificarli dal container docker come root per abusarne nell'host e aumentare i privilegi (magari modificando /etc/shadow)
La responsabilità dell'amministratore di sistema che configura questo plugin sarebbe quella di controllare quali azioni e con quali privilegi ogni utente può eseguire. Pertanto, se l'amministratore adotta un approccio di blacklist con gli endpoint e gli attributi, potrebbe dimenticarne alcuni che potrebbero consentire a un attaccante di escalare i privilegi.
Puoi controllare l'API docker in https://docs.docker.com/engine/api/v1.40/#
È possibile che quando l'amministratore di sistema ha configurato il firewall docker, abbia dimenticato qualche parametro importante dell'API come "Binds". Nell'esempio seguente è possibile abusare di questa misconfigurazione per creare ed eseguire un container che monta la cartella root (/) dell'host:
Nota come in questo esempio stiamo usando il Binds param come chiave di livello root nel JSON ma nell'API appare sotto la chiave HostConfig
Segui le stesse istruzioni di Binds in root eseguendo questa richiesta all'API Docker:
Segui le stesse istruzioni di Binds in root eseguendo questa richiesta all'API Docker:
Segui le stesse istruzioni di Binds in root eseguendo questa richiesta all'API Docker:
È possibile che quando l'amministratore di sistema ha configurato il firewall di docker si sia dimenticato di qualche attributo importante di un parametro dell'API come "Capabilities" all'interno di "HostConfig". Nel seguente esempio è possibile abusare di questa misconfigurazione per creare ed eseguire un container con la capacità SYS_MODULE:
Il HostConfig è la chiave che di solito contiene i privilegi interessanti per uscire dal container. Tuttavia, come abbiamo discusso in precedenza, nota come l'uso di Binds al di fuori di esso funzioni anche e possa permetterti di aggirare le restrizioni.
Se il sysadmin si è dimenticato di vietare la possibilità di disabilitare il plugin, puoi approfittarne per disabilitarlo completamente!
Ricorda di riattivare il plugin dopo l'escalation, o un riavvio del servizio docker non funzionerà!
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
