GCP - Network Docker Escape

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Estado Inicial

Em ambos os writeups onde essa técnica é especificada, os atacantes conseguiram obter acesso root dentro de um container Docker gerenciado pela GCP com acesso à rede do host (e as capacidades CAP_NET_ADMIN e CAP_NET_RAW).

Explicação do Ataque

Em uma instância do Google Compute Engine, a inspeção regular do tráfego de rede revela numerosas requisições HTTP em texto claro ao metadata instance em 169.254.169.254. O Google Guest Agent, um serviço open-source, frequentemente faz esse tipo de requisição.

Esse agente foi projetado para monitorar mudanças no metadata. Notavelmente, o metadata inclui um campo para chaves públicas SSH. Quando uma nova chave pública SSH é adicionada ao metadata, o agente automaticamente a autoriza no arquivo .authorized_key. Ele também pode criar um novo usuário e adicioná-lo aos sudoers se necessário.

O agente monitora mudanças enviando uma requisição para recuperar todos os valores do metadata recursivamente (GET /computeMetadata/v1/?recursive=true). Essa requisição é desenhada para provocar que o metadata server envie uma resposta somente se houver qualquer mudança no metadata desde a última recuperação, identificada por um Etag (wait_for_change=true&last_etag=). Adicionalmente, um parâmetro de timeout (timeout_sec=) é incluído. Se nenhuma mudança ocorrer dentro do timeout especificado, o servidor responde com os valores inalterados.

Esse processo permite que o IMDS (Instance Metadata Service) responda após 60 segundos se nenhuma mudança de configuração tiver ocorrido, criando uma potencial janela para injetar uma resposta de configuração falsa para o guest agent.

Um atacante poderia explorar isso realizando um Man-in-the-Middle (MitM) attack, forjando a resposta do servidor IMDS e inserindo uma nova chave pública. Isso poderia permitir acesso SSH não autorizado ao host.

Técnica de Escape

Enquanto ARP spoofing é ineficaz nas redes do Google Compute Engine, uma versão modificada do rshijack desenvolvida por Ezequiel pode ser usada para injeção de pacotes na comunicação para injetar o usuário SSH.

Essa versão do rshijack permite informar os números ACK e SEQ como argumentos de linha de comando, facilitando a falsificação de uma resposta antes da resposta real do Metadata server. Adicionalmente, um pequeno Shell script é usado para retornar um payload especialmente forjado. Esse payload aciona o Google Guest Agent para criar um usuário wouter com uma chave pública especificada no arquivo .authorized_keys.

O script usa o mesmo ETag para evitar que o Metadata server notifique imediatamente o Google Guest Agent sobre valores de metadata diferentes, atrasando assim a resposta.

Para executar o spoofing, os seguintes passos são necessários:

  1. Monitorar requisições ao servidor de Metadata usando tcpdump:
Monitorar requisições ao servidor de metadata com tcpdump ```bash tcpdump -S -i eth0 'host 169.254.169.254 and port 80' & ```

Procure por uma linha semelhante a:

Exemplo de linha de saída do tcpdump ```