GCP - Network Docker Escape
Stato iniziale
In entrambi i writeup in cui viene specificata questa tecnica, gli attaccanti sono riusciti ad ottenere l'accesso root all'interno di un container 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 numerosi richieste HTTP in chiaro all'istanza dei metadati all'indirizzo 169.254.169.254. L'Agente Ospite di Google, 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 far sì che il server dei metadati invii 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 timeout (timeout_sec=). Se non si verifica alcuna modifica 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 l'iniezione di 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
Sebbene l'ARP spoofing sia inefficace nelle reti di Google Compute Engine, una versione modificata di rshijack sviluppata da Ezequiel può essere utilizzata per l'iniezione di pacchetti nella comunicazione al fine di iniettare l'utente SSH.
Questa versione di rshijack consente di inserire i numeri ACK e SEQ come argomenti della riga di comando, facilitando la contraffazione di una risposta prima della vera risposta del server dei metadati. Inoltre, viene utilizzato uno script Shell per restituire un payload appositamente creato. Questo payload attiva l'Agente Ospite di Google 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 all'Agente Ospite di Google valori dei metadati diversi, ritardando così la risposta.
Per eseguire la contraffazione, sono necessari i seguenti passaggi:
Monitorare le richieste al server dei metadati utilizzando tcpdump:
Cerca una riga simile a:
Invia i dati falsi del metadata con l'ETAG corretto a rshijack:
Questo passaggio autorizza la chiave pubblica, abilitando la connessione SSH con la corrispondente chiave privata.
Riferimenti
Last updated