GCP - Network Docker Escape

Support HackTricks

Stato Iniziale

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).

Spiegazione dell'Attacco

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 è avvenuta 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.

Tecnica di Fuga

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:

  1. Monitorare le richieste al server Metadata utilizzando tcpdump:

tcpdump -S -i eth0 'host 169.254.169.254 and port 80' &

Cerca una riga simile a:

<TIME> IP <LOCAL_IP>.<PORT> > 169.254.169.254.80: Flags [P.], seq <NUM>:<TARGET_ACK>, ack <TARGET_SEQ>, win <NUM>, length <NUM>: HTTP: GET /computeMetadata/v1/?timeout_sec=<SECONDS>&last_etag=<ETAG>&alt=json&recursive=True&wait_for_change=True HTTP/1.1
  1. Invia i dati di metadata falsi con l'ETAG corretto a rshijack:

fakeData.sh <ETAG> | rshijack -q eth0 169.254.169.254:80 <LOCAL_IP>:<PORT> <TARGET_SEQ> <TARGET_ACK>; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost

Questo passaggio autorizza la chiave pubblica, abilitando la connessione SSH con la corrispondente chiave privata.

Riferimenti

Supporta HackTricks

Last updated