GCP - Network Docker Escape

Sostieni HackTricks

Stato Iniziale

In entrambi i documenti in cui questa tecnica è specificata, gli attaccanti sono riusciti ad ottenere accesso root all'interno di un contenitore Docker 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 all'istanza di metadati a 169.254.169.254. Il Google Guest Agent, un servizio open-source, effettua frequentemente tali richieste.

Questo agente è progettato per monitorare i cambiamenti nei metadati. In particolare, i metadati includono un campo per le chiavi pubbliche SSH. Quando viene aggiunta una nuova chiave pubblica SSH ai metadati, l'agente la autorizza automaticamente nel file .authorized_key. Potrebbe anche creare un nuovo utente e aggiungerlo ai sudoers se necessario.

L'agente monitora i cambiamenti inviando una richiesta per recuperare tutti i valori dei metadati in modo ricorsivo (GET /computeMetadata/v1/?recursive=true). Questa richiesta è progettata per far sì che il server dei metadati invii una risposta solo se c'è stato un cambiamento nei metadati dall'ultimo recupero, identificato da un Etag (wait_for_change=true&last_etag=). Inoltre, è incluso un parametro timeout (timeout_sec=). Se non avviene alcun cambiamento entro il timeout specificato, il server risponde con i valori invariati.

Questo processo consente al IMDS (Instance Metadata Service) di rispondere dopo 60 secondi se non è avvenuto alcun cambiamento di configurazione, creando una potenziale finestra per iniettare una falsa risposta di configurazione all'agente ospite.

Un attaccante potrebbe sfruttare ciò eseguendo un attacco Man-in-the-Middle (MitM), contraffacendo la risposta dal server IMDS e inserendo una nuova chiave pubblica. Ciò potrebbe consentire l'accesso SSH non autorizzato all'host.

Tecnica di Fuga

Mentre lo spoofing ARP è 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 lo spoofing di una risposta prima della reale risposta del server dei Metadati. Inoltre, viene utilizzato uno script Shell piccolo 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 dei Metadati di notificare immediatamente al Google Guest Agent valori dei metadati diversi, ritardando così la risposta.

Per eseguire lo spoofing, sono necessari i seguenti passaggi:

  1. Monitorare le richieste al server dei Metadati 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 falsi del metadata 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