GCP - Network Docker Escape
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)
In entrambi i report in cui è specificata questa tecnica, gli attaccanti sono riusciti a ottenere accesso root all'interno di un Docker container gestito da GCP con accesso alla rete host (e le capacità CAP_NET_ADMIN
e CAP_NET_RAW
).
Su un'istanza di Google Compute Engine, l'ispezione regolare del traffico di rete rivela numerose richieste HTTP in chiaro al metadata instance a 169.254.169.254
. Il Google Guest Agent, un servizio open-source, effettua frequentemente tali richieste.
Questo agente è progettato per monitorare le modifiche nei metadati. In particolare, i metadati includono un campo per le chiavi pubbliche SSH. Quando una nuova chiave pubblica SSH viene aggiunta ai metadati, l'agente la autorizza automaticamente nel file .authorized_key
. Può anche creare un nuovo utente e aggiungerlo ai sudoers se necessario.
L'agente monitora le modifiche inviando una richiesta per recuperare tutti i valori dei metadati in modo ricorsivo (GET /computeMetadata/v1/?recursive=true
). Questa richiesta è progettata per indurre il server dei metadati a inviare una risposta solo se c'è stata una modifica nei metadati dall'ultimo recupero, identificata da un Etag (wait_for_change=true&last_etag=
). Inoltre, è incluso un parametro di timeout (timeout_sec=
). Se non si verifica alcuna modifica entro il timeout specificato, il server risponde con i valori invariati.
Questo processo consente all'IMDS (Instance Metadata Service) di rispondere dopo 60 secondi se non si è verificata alcuna modifica della configurazione, creando una potenziale finestra per iniettare una risposta di configurazione falsa all'agente guest.
Un attaccante potrebbe sfruttare questo eseguendo un attacco Man-in-the-Middle (MitM), falsificando la risposta dal server IMDS e inserendo una nuova chiave pubblica. Questo potrebbe abilitare l'accesso SSH non autorizzato all'host.
Sebbene l'ARP spoofing sia inefficace sulle reti di Google Compute Engine, una versione modificata di rshijack sviluppata da Ezequiel può essere utilizzata per l'iniezione di pacchetti nella comunicazione per iniettare l'utente SSH.
Questa versione di rshijack consente di inserire i numeri ACK e SEQ come argomenti della riga di comando, facilitando la falsificazione di una risposta prima della reale risposta del server Metadata. Inoltre, viene utilizzato un piccolo script Shell per restituire un payload appositamente creato. Questo payload attiva il Google Guest Agent per creare un utente wouter
con una chiave pubblica specificata nel file .authorized_keys
.
Lo script utilizza lo stesso ETag per impedire al server Metadata di notificare immediatamente il Google Guest Agent di valori di metadati diversi, ritardando così la risposta.
Per eseguire la falsificazione, sono necessari i seguenti passaggi:
Monitorare le richieste al server Metadata utilizzando tcpdump:
Cerca una riga simile a:
Invia i dati di metadata falsi con l'ETAG corretto a rshijack:
Questo passaggio autorizza la chiave pubblica, abilitando la connessione SSH con la corrispondente chiave privata.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)