Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
No Kubernetes, observa-se que um comportamento padrão permite o estabelecimento de conexões entre todos os contêineres residindo no mesmo nó. Isso se aplica independentemente das distinções de namespace. Essa conectividade se estende até Camada 2 (Ethernet). Consequentemente, essa configuração potencialmente expõe o sistema a vulnerabilidades. Especificamente, abre a possibilidade para um contêiner malicioso executar um ataque de spoofing ARP contra outros contêineres situados no mesmo nó. Durante tal ataque, o contêiner malicioso pode enganosamente interceptar ou modificar o tráfego de rede destinado a outros contêineres.
Os ataques de spoofing ARP envolvem o atacante enviando mensagens ARP falsificadas (Protocolo de Resolução de Endereços) em uma rede local. Isso resulta na vinculação do endereço MAC do atacante com o endereço IP de um computador ou servidor legítimo na rede. Após a execução bem-sucedida de tal ataque, o atacante pode interceptar, modificar ou até mesmo interromper dados em trânsito. O ataque é executado na Camada 2 do modelo OSI, razão pela qual a conectividade padrão no Kubernetes nessa camada levanta preocupações de segurança.
No cenário, 4 máquinas serão criadas:
ubuntu-pe: Máquina privilegiada para escapar para o nó e verificar métricas (não necessária para o ataque)
ubuntu-attack: Contêiner malicioso no namespace padrão
ubuntu-victim: Máquina vítima no namespace kube-system
mysql: Máquina vítima no namespace padrão
Se você quiser mais detalhes sobre os tópicos de rede introduzidos aqui, consulte as referências.
De maneira geral, a rede pod-a-pod dentro do nó está disponível através de uma ponte que conecta todos os pods. Essa ponte é chamada de “cbr0”. (Alguns plugins de rede instalarão sua própria ponte.) O cbr0 também pode lidar com ARP (Protocolo de Resolução de Endereços). Quando um pacote de entrada chega ao cbr0, ele pode resolver o endereço MAC de destino usando ARP.
Esse fato implica que, por padrão, cada pod em execução no mesmo nó poderá comunicar-se com qualquer outro pod no mesmo nó (independentemente do namespace) em nível de ethernet (camada 2).
Portanto, é possível realizar ataques de ARP Spoofing entre pods no mesmo nó.
Em ambientes kubernetes, você geralmente encontrará 1 (ou mais) serviços DNS em execução geralmente no namespace kube-system:
No info anterior, você pode ver algo interessante, o IP do serviço é 10.96.0.10, mas o IP do pod que está executando o serviço é 172.17.0.2.
Se você verificar o endereço DNS dentro de qualquer pod, encontrará algo assim:
No entanto, o pod não sabe como chegar a esse endereço porque o intervalo de pods neste caso é 172.17.0.10/26.
Portanto, o pod enviará as solicitações DNS para o endereço 10.96.0.10, que será traduzido pelo cbr0 para 172.17.0.2.
Isso significa que uma solicitação DNS de um pod sempre irá para a ponte para traduzir o IP do serviço para o IP do endpoint, mesmo que o servidor DNS esteja na mesma sub-rede que o pod.
Sabendo disso, e sabendo que ataques ARP são possíveis, um pod em um nó será capaz de interceptar o tráfego entre cada pod na sub-rede e a ponte e modificar as respostas DNS do servidor DNS (DNS Spoofing).
Além disso, se o servidor DNS estiver no mesmo nó que o atacante, o atacante pode interceptar todas as solicitações DNS de qualquer pod no cluster (entre o servidor DNS e a ponte) e modificar as respostas.
Nosso objetivo é roubar pelo menos a comunicação do ubuntu-victim para o mysql.
Como já mencionado, se você comprometer um pod no mesmo nó do pod do servidor DNS, você pode MitM com ARPSpoofing a ponte e o pod DNS e modificar todas as respostas DNS.
Você tem uma ferramenta e um tutorial muito bons para testar isso em https://github.com/danielsagi/kube-dnsspoof/
No nosso cenário, baixe a ferramenta no pod do atacante e crie um arquivo chamado hosts com os domínios que você deseja spoof como:
Realize o ataque à máquina ubuntu-victim:
Se você tentar criar seu próprio script de spoofing de DNS, se você apenas modificar a resposta DNS isso não vai funcionar, porque a resposta vai ter um src IP o endereço IP do pod malicioso e não será aceita. Você precisa gerar um novo pacote DNS com o src IP do DNS onde a vítima envia a solicitação DNS (que é algo como 172.16.0.2, não 10.96.0.10, esse é o IP do serviço DNS do K8s e não o IP do servidor DNS, mais sobre isso na introdução).
A ferramenta Mizu é um visualizador de tráfego de API simples, mas poderoso para Kubernetes, permitindo que você veja toda a comunicação de API entre microsserviços para ajudar a depurar e solucionar regressões. Ela instalará agentes nos pods selecionados e coletará suas informações de tráfego e mostrará em um servidor web. No entanto, você precisará de altas permissões K8s para isso (e não é muito discreto).
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
