GCP - Network Docker Escape
Estado Inicial
Nos relatos onde essa técnica é especificada, os atacantes conseguiram acesso root dentro de um container Docker gerenciado pelo GCP com acesso à rede do host (e as capacidades CAP_NET_ADMIN e CAP_NET_RAW).
Ataque
Quando você inspeciona o tráfego de rede em uma instância regular do Google Compute Engine, você verá muitas requisições HTTP simples sendo direcionadas para a instância de metadados em 169.254.169.254. Um serviço que faz tais requisições é o Google Guest Agent de código aberto. Exemplo de requisição:
Este agente monitora os metadados para mudanças. Dentro dos metadados há um campo com chaves públicas SSH autorizadas.
Portanto, quando uma nova chave pública SSH aparece nos metadados, o agente irá autorizar a mesma no arquivo .authorized_key do usuário e irá criar um novo usuário se necessário, adicionando-o aos sudoers.
A forma como o Google Guest Agent monitora mudanças é através de uma chamada para recuperar todos os valores de metadados recursivamente (GET /computeMetadata/v1/?recursive=true), indicando ao servidor de metadados para enviar uma resposta apenas quando houver alguma mudança em relação aos últimos valores de metadados recuperados, identificados pelo seu Etag (wait_for_change=true&last_etag=).
Esta requisição também inclui um tempo limite (timeout_sec=), então se uma mudança não ocorrer dentro do tempo especificado, o servidor de metadados responde com os valores inalterados.
Isso faz com que o IMDS responda após 60 segundos se não houve mudança de configuração nesse intervalo, permitindo uma janela para injetar uma resposta de configuração falsa ao agente convidado do IMDS.
Portanto, se um atacante conseguir realizar um ataque MitM, ele poderia falsificar a resposta do servidor IMDS inserindo uma nova chave pública para permitir que um novo usuário acesse via SSH ao host.
Fuga
ARP spoofing não funciona nas redes do Google Compute Engine, no entanto, Ezequiel gerou esta versão modificada de rshijack **** que pode ser usada para injetar um pacote na comunicação para injetar o usuário SSH.
Esta versão modificada do rshijack permite passar os números ACK e SEQ como argumentos de linha de comando, economizando tempo e permitindo que nós falsifiquemos uma resposta antes que a verdadeira resposta do Metadata chegasse.
Além disso, este pequeno script Shell **** que retornaria um payload especialmente criado que acionaria o Google Guest Agent para criar o usuário wouter, com nossa própria chave pública no seu arquivo .authorized_keys.
Este script recebe o ETag como parâmetro, já que mantendo o mesmo ETag, o servidor de Metadados não informaria imediatamente ao Google Guest Agent que os valores de metadados eram diferentes na próxima resposta, em vez disso, esperando a quantidade especificada de segundos em timeout_sec.
Para realizar a falsificação, você deve observar as requisições ao servidor de Metadados com tcpdump: tcpdump -S -i eth0 'host 169.254.169.254 and port 80' & esperando por uma linha que pareça com esta:
Quando você ver esse valor, envie os dados falsos de metadados com o ETAG correto para 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
E isso deve fazer com que o agente autorize essa chave pública que permitirá que você conecte via SSH com a chave privada.
Referências
Última actualización
