gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-08 19:30:51 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus

Browse Source
This commit is contained in:
Translator
2025-04-14 22:03:46 +00:00
parent 993de8c8ad
commit d3b9d0a0e2
2 changed files with 147 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md
View File

@@ -4,11 +4,11 @@
## Introduction
Kubernetes में, यह देखा गया है कि एक डिफ़ॉल्ट व्यवहार **समान नोड पर निवास करने वाले सभी कंटेनरों** के बीच कनेक्शन स्थापित करने की अनुमति देता है। यह नामस्थान भिन्नताओं की परवाह किए बिना लागू होता है। ऐसी कनेक्टिविटी **लेयर 2** (Ethernet) तक फैली हुई है। परिणामस्वरूप, यह कॉन्फ़िगरेशन प्रणाली को कमजोरियों के लिए संभावित रूप से उजागर करता है। विशेष रूप से, यह एक **दुष्ट कंटेनर** के लिए एक **ARP स्पूफिंग हमले** को अन्य कंटेनरों के खिलाफ निष्पादित करने की संभावना खोलता है जो समान नोड पर स्थित हैं। ऐसे हमले के दौरान, दुष्ट कंटेनर धोखे से अन्य कंटेनरों के लिए लक्षित नेटवर्क ट्रैफ़िक को इंटरसेप्ट या संशोधित कर सकता है।
Kubernetes में, यह देखा गया है कि एक डिफ़ॉल्ट व्यवहार **सभी कंटेनरों के बीच कनेक्शन स्थापित करने की अनुमति देता है जो एक ही नोड पर स्थित हैं**। यह नामस्थान भिन्नताओं की परवाह किए बिना लागू होता है। इस प्रकार की कनेक्टिविटी **लेयर 2** (Ethernet) तक फैली हुई है। नतीजतन, यह कॉन्फ़िगरेशन प्रणाली को कमजोरियों के लिए संभावित रूप से उजागर करता है। विशेष रूप से, यह एक **दुष्ट कंटेनर** के लिए एक **ARP स्पूफिंग हमले** को अन्य कंटेनरों के खिलाफ निष्पादित करने की संभावना खोलता है जो उसी नोड पर स्थित हैं। ऐसे हमले के दौरान, दुष्ट कंटेनर धोखे से अन्य कंटेनरों के लिए निर्धारित नेटवर्क ट्रैफ़िक को इंटरसेप्ट या संशोधित कर सकता है।
ARP स्पूफिंग हमलों में **हमलावर द्वारा स्थानीय क्षेत्र नेटवर्क पर गलत ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) संदेश भेजना शामिल है। इसके परिणामस्वरूप **हमलावर के MAC पते को नेटवर्क पर एक वैध कंप्यूटर या सर्वर के IP पते के साथ जोड़ा जाता है**। ऐसे हमले के सफल निष्पादन के बाद, हमलावर डेटा को इंटरसेप्ट, संशोधित या यहां तक कि ट्रांजिट में रोक सकता है। यह हमला OSI मॉडल की लेयर 2 पर निष्पादित होता है, यही कारण है कि Kubernetes में इस लेयर पर डिफ़ॉल्ट कनेक्टिविटी सुरक्षा चिंताओं को उठाती है।
ARP स्पूफिंग हमलों में **हमलावर द्वारा स्थानीय क्षेत्र नेटवर्क पर गलत ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) संदेश भेजना शामिल है। इसके परिणामस्वरूप **हमलावर के MAC पते को नेटवर्क पर एक वैध कंप्यूटर या सर्वर के IP पते के साथ जोड़ा जाता है**। ऐसे हमले के सफल निष्पादन के बाद, हमलावर डेटा को इंटरसेप्ट, संशोधित या यहां तक कि ट्रांजिट में रोक सकता है। यह हमला OSI मॉडल की लेयर 2 पर निष्पादित किया जाता है, यही कारण है कि Kubernetes में इस स्तर पर डिफ़ॉल्ट कनेक्टिविटी सुरक्षा चिंताओं को उठाती है।
परिदृश्य में 4 मशीनें बनाई जाएंगी:
परिदृश्य में 4 मशीनें बनाई जाने वाली हैं:
- ubuntu-pe: नोड पर भागने और मेट्रिक्स की जांच करने के लिए विशेषाधिकार प्राप्त मशीन (हमले के लिए आवश्यक नहीं)
- **ubuntu-attack**: **दुष्ट** कंटेनर डिफ़ॉल्ट नामस्थान में
@@ -102,16 +102,16 @@ kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; ba
### ARP
सामान्यत: **नोड के अंदर पॉड-से-पॉड नेटवर्किंग** एक **ब्रिज** के माध्यम से उपलब्ध है जो सभी पॉड्स को जोड़ता है। इस ब्रिज को “**cbr0**” कहा जाता है। (कुछ नेटवर्क प्लगइन्स अपनी खुद की ब्रिज स्थापित करेंगे।) **cbr0 ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) समाधान को भी संभाल सकता है। जब एक इनकमिंग पैकेट cbr0 पर आता है, तो यह ARP का उपयोग करके गंतव्य MAC पते को हल कर सकता है।
सामान्यतः, **नोड के अंदर पोड-से-पोड नेटवर्किंग** एक **ब्रिज** के माध्यम से उपलब्ध है जो सभी पोड्स को जोड़ता है। इस ब्रिज को “**cbr0**” कहा जाता है। (कुछ नेटवर्क प्लगइन्स अपना खुद का ब्रिज स्थापित करेंगे।) **cbr0 ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) समाधान को भी संभाल सकता है। जब एक इनकमिंग पैकेट cbr0 पर आता है, तो यह ARP का उपयोग करके गंतव्य MAC पते को हल कर सकता है।
यह तथ्य यह संकेत करता है कि, डिफ़ॉल्ट रूप से, **एक ही नोड में चलने वाला हर पॉड** किसी अन्य पॉड के साथ **संवाद** करने में सक्षम होगा जो उसी नोड में है (नेमस्पेस के स्वतंत्र) एथरनेट स्तर (लेयर 2) पर।
यह तथ्य यह संकेत करता है कि, डिफ़ॉल्ट रूप से, **एक ही नोड में चलने वाला हर पोड** किसी अन्य पोड के साथ **संवाद** करने में सक्षम होगा (नेमस्पेस के स्वतंत्र) एथरनेट स्तर (लेयर 2) पर।
> [!WARNING]
> इसलिए, एक ही नोड में पॉड्स के बीच A**RP Spoofing हमले करना संभव है।**
> इसलिए, एक ही नोड में पोड्स के बीच A**RP Spoofing हमले करना संभव है।**
### DNS
कुबरनेट्स वातावरण में आप आमतौर पर 1 (या अधिक) **DNS सेवाएं चलती हुई पाएंगे** जो आमतौर पर kube-system नेमस्पेस में होती हैं:
कubernetes वातावरण में आप आमतौर पर 1 (या अधिक) **DNS सेवाएं चलती हुई पाएंगे** जो आमतौर पर kube-system नेमस्पेस में होती हैं:
```bash
kubectl -n kube-system describe services
Name: kube-dns
@@ -138,21 +138,21 @@ Endpoints: 172.17.0.2:9153
```
पिछली जानकारी में आप कुछ दिलचस्प देख सकते हैं, **सेवा का IP** **10.96.0.10** है लेकिन **सेवा चला रहे पोड का IP** **172.17.0.2** है।
यदि आप किसी भी पोड के अंदर DNS पते की जांच करते हैं, तो आपको कुछ ऐसा मिलेगा:
यदि आप किसी भी पोड के अंदर DNS पते की जांच करते हैं, तो आपको कुछ इस तरह मिलेगा:
```
cat /etc/resolv.conf
nameserver 10.96.0.10
```
हालांकि, **पॉड** को उस **पते** तक पहुँचने का तरीका **नहीं पता** है क्योंकि इस मामले में **पॉड रेंज** 172.17.0.10/26 है।
हालांकि, **पॉड को** उस **पते** तक पहुँचने का तरीका **नहीं पता** है क्योंकि इस मामले में **पॉड रेंज** 172.17.0.10/26 है।
इसलिए, पॉड **10.96.0.10** के पते पर **DNS अनुरोध** भेजेगा जिसे cbr0 द्वारा **172.17.0.2** में **अनुवादित** किया जाएगा।
इसलिए, पॉड **DNS अनुरोधों को पते 10.96.0.10** पर भेजेगा जो cbr0 द्वारा **172.17.0.2** में **अनुवादित** किया जाएगा।
> [!WARNING]
> इसका मतलब है कि एक पॉड का **DNS अनुरोध** **हमेशा** **ब्रिज** की ओर जाएगा ताकि **सेवा IP को अंत बिंदु IP में अनुवादित** किया जा सके, भले ही DNS सर्वर पॉड के समान उपनेटवर्क में हो।
>
> यह जानकर, और यह जानकर कि **ARP हमले संभव हैं**, एक **पॉड** एक नोड में **उपनेटवर्क** में **प्रत्येक पॉड** के बीच **ट्रैफ़िक को इंटरसेप्ट** करने में सक्षम होगा और **DNS सर्वर** से **DNS प्रतिक्रियाओं को संशोधित** करेगा (**DNS Spoofing**)।
>
> इसके अलावा, यदि **DNS सर्वर** **हमलावर के समान नोड में** है, तो हमलावर क्लस्टर में किसी भी पॉड के सभी **DNS अनुरोधों** को (DNS सर्वर और ब्रिज के बीच) **इंटरसेप्ट** कर सकता है और प्रतिक्रियाओं को संशोधित कर सकता है।
> इसके अलावा, यदि **DNS सर्वर** **हमलावर के समान नोड में** है, तो हमलावर किसी भी पॉड के सभी DNS अनुरोधों को (DNS सर्वर और ब्रिज के बीच) **इंटरसेप्ट** कर सकता है और प्रतिक्रियाओं को संशोधित कर सकता है।
## समान नोड में पॉड्स में ARP Spoofing
@@ -233,11 +233,11 @@ arpspoof -t 172.17.0.9 172.17.0.10
```
## DNS Spoofing
जैसा कि पहले ही उल्लेख किया गया है, यदि आप **DNS सर्वर पॉड** के उसी नोड में एक पॉड को **समझौता** करते हैं, तो आप **MitM** के साथ **ARPSpoofing** का उपयोग करके **ब्रिज और DNS** पॉड को **संशोधित** कर सकते हैं और **सभी DNS प्रतिक्रियाओं** को **बदल** सकते हैं।
जैसा कि पहले ही उल्लेख किया गया है, यदि आप **DNS सर्वर पॉड के उसी नोड में एक पॉड को समझौता करते हैं**, तो आप **MitM** के साथ **ARPSpoofing** का उपयोग करके **ब्रिज और DNS** पॉड को **संशोधित** कर सकते हैं और **सभी DNS प्रतिक्रियाओं** को **बदल** सकते हैं।
आपके पास इसे परीक्षण करने के लिए एक बहुत अच्छा **उपकरण** और **ट्यूटोरियल** है [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
आपके पास इसे परीक्षण करने के लिए एक बहुत अच्छा **टूल** और **ट्यूटोरियल** है [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
हमारे परिदृश्य में, **हमलावर पॉड** में **उपकरण** को **डाउनलोड** करें और एक \*\*फाइल नाम `hosts` \*\* बनाएं जिसमें आप जिन **डोमेन** को **स्पूफ** करना चाहते हैं, जैसे:
हमारे परिदृश्य में, **हमलावर पॉड** में **टूल** डाउनलोड करें और एक **फाइल नाम `hosts`** बनाएं जिसमें आप जिन **डोमेन** को **स्पूफ** करना चाहते हैं, उन्हें शामिल करें:
```
cat hosts
google.com. 1.1.1.1
@@ -260,13 +260,45 @@ dig google.com
google.com. 1 IN A 1.1.1.1
```
> [!NOTE]
> यदि आप अपना खुद का DNS स्पूफिंग स्क्रिप्ट बनाने की कोशिश करते हैं, यदि आप **बस DNS प्रतिक्रिया को संशोधित करते हैं** तो यह **काम नहीं करेगा**, क्योंकि **प्रतिक्रिया** में **src IP** **दुष्ट** **पॉड** का IP पता होगा और इसे **स्वीकृत** नहीं किया जाएगा।\
> आपको **नया DNS पैकेट** उत्पन्न करने की आवश्यकता है जिसमें **src IP** उस **DNS** का हो जहाँ पीड़ित DNS अनुरोध भेजता है (जो कुछ ऐसा है जैसे 172.16.0.2, न कि 10.96.0.10, यह K8s DNS सेवा का IP है और न कि DNS सर्वर का IP, इसके बारे में अधिक जानकारी परिचय में है)।
> यदि आप अपना खुद का DNS स्पूफिंग स्क्रिप्ट बनाने की कोशिश करते हैं, यदि आप **केवल DNS प्रतिक्रिया को संशोधित करते हैं** तो यह **काम नहीं करेगा**, क्योंकि **प्रतिक्रिया** में **src IP** **दुष्ट** **पॉड** का IP पता होगा और इसे **स्वीकृत** नहीं किया जाएगा।\
> आपको **DNS** का **नया DNS पैकेट** उत्पन्न करने की आवश्यकता है जहां पीड़ित DNS अनुरोध भेजता है (जो कुछ ऐसा है जैसे 172.16.0.2, 10.96.0.10 नहीं, वह K8s DNS सेवा का IP है और DNS सर्वर का IP नहीं है, इसके बारे में अधिक जानकारी परिचय में है)।
## DNS Spoofing via coreDNS configmap
kube-system namespace में `coredns` configmap पर लिखने की अनुमति रखने वाला उपयोगकर्ता क्लस्टर की DNS प्रतिक्रियाओं को संशोधित कर सकता है।
इस हमले के बारे में अधिक जानकारी के लिए देखें:
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/README.md
{{/ref}}
## Abusing exposed kubernetes management services
Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, और Kubernetes डैशबोर्ड जैसी सेवाएँ अक्सर इंटरनेट या kubernetes नेटवर्क के भीतर उजागर होती हैं। एक हमलावर जो **kubernetes को प्रबंधित करने के लिए उपयोग की जाने वाली किसी भी प्लेटफ़ॉर्म को खोजने और उस तक पहुँचने में सफल होता है** उसे kubernetes API तक पहुँच प्राप्त करने के लिए इसका दुरुपयोग कर सकता है और नए पॉड बनाने, मौजूदा को संशोधित करने, या यहां तक कि उन्हें हटाने जैसी क्रियाएँ कर सकता है।
## Enumerating kubernetes network policies
संरचित **networkpolicies** प्राप्त करें:
```bash
kubectl get networkpolicies --all-namespaces
```
**Callico** नेटवर्क नीतियाँ प्राप्त करें:
```bash
kubectl get globalnetworkpolicy --all-namespaces
```
**Cillium** नेटवर्क नीतियाँ प्राप्त करें:
```bash
kubectl get ciliumnetworkpolicy --all-namespaces
```
अपने नेटवर्क प्लगइन या सुरक्षा समाधान द्वारा स्थापित अन्य नीति-संबंधित CRDs प्राप्त करें:
```bash
kubectl get crd | grep -i policy
```
## ट्रैफ़िक कैप्चर करना
उपकरण [**Mizu**](https://github.com/up9inc/mizu) एक सरल लेकिन शक्तिशाली API **ट्रैफ़िक व्यूअर है जो Kubernetes के लिए** आपको **सूक्ष्म सेवाओं के बीच सभी API संचार** देखने में सक्षम बनाता है ताकि आप अपने डिबग और समस्या निवारण में मदद कर सकें।\
यह चयनित पॉड में एजेंट स्थापित करेगा और उनके ट्रैफ़िक की जानकारी एक वेब सर्वर में दिखाएगा। हालाँकि, इसके लिए आपको उच्च K8s अनुमतियों की आवश्यकता होगी (और यह बहुत छिपा हुआ नहीं है)।
उपकरण [**Mizu**](https://github.com/up9inc/mizu) एक सरल लेकिन शक्तिशाली API **ट्रैफ़िक व्यूअर है Kubernetes के लिए** जो आपको **सूक्ष्म सेवाओं के बीच सभी API संचार** देखने में सक्षम बनाता है ताकि आप अपने डिबग और समस्या निवारण में मदद कर सकें।\
यह चयनित पॉड्स में एजेंट स्थापित करेगा और उनके ट्रैफ़िक की जानकारी एकत्र करेगा और आपको एक वेब सर्वर में दिखाएगा। हालाँकि, इसके लिए आपको उच्च K8s अनुमतियों की आवश्यकता होगी (और यह बहुत छिपा हुआ नहीं है)।
## संदर्भ