mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 12:51:33 -08:00
Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus
This commit is contained in:
Translator
@@ -3,16 +3,16 @@
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
यहाँ आप कुछ संभावित खतरनाक Roles और ClusterRoles कॉन्फ़िगरेशन पा सकते हैं।\
|
||||
याद रखें कि आप `kubectl api-resources` के साथ सभी समर्थित संसाधनों को प्राप्त कर सकते हैं।
|
||||
याद रखें कि आप `kubectl api-resources` के साथ सभी समर्थित संसाधन प्राप्त कर सकते हैं।
|
||||
|
||||
## **विशेषाधिकार वृद्धि**
|
||||
|
||||
इसका मतलब है **क्लस्टर के भीतर एक अलग प्रिंसिपल** तक **विभिन्न विशेषाधिकारों** के साथ पहुँच प्राप्त करना (क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं:
|
||||
इसका मतलब है **क्लस्टर के भीतर एक अलग प्रिंसिपल** तक **विभिन्न विशेषाधिकारों** के साथ पहुँच प्राप्त करना (कubernetes क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं:
|
||||
|
||||
- अन्य उपयोगकर्ता/समूह/एसए को **प्रतिनिधित्व** करने में सक्षम होना जिनके पास क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार हैं
|
||||
- **पॉड्स बनाना/पैच करना/एक्सेक्यूट करना** जहाँ आप **बेहतर विशेषाधिकार वाले एसए** को खोज या संलग्न कर सकते हैं
|
||||
- अन्य उपयोगकर्ता/समूह/एसए को **प्रतिनिधित्व** करने में सक्षम होना जिनके पास kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार हैं
|
||||
- **पॉड्स बनाना/पैच करना/कार्यक्रम चलाना** जहाँ आप kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार वाले एसए को **पाना या संलग्न** कर सकते हैं
|
||||
- **गुप्त पढ़ने** में सक्षम होना क्योंकि एसए टोकन गुप्त के रूप में संग्रहीत होते हैं
|
||||
- एक कंटेनर से **नोड पर भागने** में सक्षम होना, जहाँ आप नोड पर चल रहे कंटेनरों के सभी गुप्त, नोड की क्रेडेंशियल्स, और नोड के क्लाउड में चलने के दौरान की अनुमतियों को चुरा सकते हैं (यदि कोई हो)
|
||||
- एक कंटेनर से **नोड पर भागने** में सक्षम होना, जहाँ आप नोड पर चल रहे कंटेनरों के सभी गुप्त, नोड के क्रेडेंशियल और नोड के भीतर क्लाउड में चलने वाले अनुमतियों को चुरा सकते हैं (यदि कोई हो)
|
||||
- एक पांचवीं तकनीक जिसका उल्लेख किया जाना चाहिए वह है **पॉड में पोर्ट-फॉरवर्ड** चलाने की क्षमता, क्योंकि आप उस पॉड के भीतर दिलचस्प संसाधनों तक पहुँच प्राप्त कर सकते हैं।
|
||||
|
||||
### किसी भी संसाधन या क्रिया (वाइल्डकार्ड) तक पहुँच
|
||||
@@ -49,9 +49,9 @@ verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Create - Steal Token
|
||||
|
||||
एक हमलावर जिसके पास एक पोड बनाने की अनुमति है, वह पोड में एक विशेषाधिकार प्राप्त सेवा खाता संलग्न कर सकता है और सेवा खाते की पहचान चुराने के लिए टोकन चुरा सकता है। प्रभावी रूप से इसके लिए विशेषाधिकार बढ़ाना।
|
||||
एक हमलावर जिसके पास एक पोड बनाने की अनुमति है, वह पोड में एक विशेषाधिकार प्राप्त सेवा खाता संलग्न कर सकता है और सेवा खाते की पहचान चुराने के लिए टोकन चुरा सकता है। प्रभावी रूप से इसके लिए विशेषाधिकार बढ़ाना
|
||||
|
||||
`bootstrap-signer` सेवा खाते का टोकन चुराने और इसे हमलावर को भेजने वाले पोड का उदाहरण:
|
||||
एक पोड का उदाहरण जो `bootstrap-signer` सेवा खाते का टोकन चुराएगा और इसे हमलावर को भेजेगा:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -134,7 +134,7 @@ kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hos
|
||||
- **hostNetwork**
|
||||
- **hostIPC**
|
||||
|
||||
_आप पिछले विशेषाधिकार प्राप्त पोड कॉन्फ़िगरेशन बनाने/दुरुपयोग करने के उदाहरण [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) में पा सकते हैं।_
|
||||
_आप पिछले विशेषाधिकार प्राप्त पोड कॉन्फ़िगरेशन को बनाने/दुरुपयोग करने के उदाहरण [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) में पा सकते हैं।_
|
||||
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
@@ -189,16 +189,16 @@ path: /
|
||||
```
|
||||
### **Pods Exec**
|
||||
|
||||
**`pods/exec`** क्यूबेरनेट्स में एक संसाधन है जिसका उपयोग **पॉड के अंदर एक शेल में कमांड चलाने के लिए** किया जाता है। यह **कंटेनरों के अंदर कमांड चलाने या एक शेल प्राप्त करने** की अनुमति देता है।
|
||||
**`pods/exec`** kubernetes में एक संसाधन है जो **एक पॉड के अंदर एक शेल में कमांड चलाने के लिए** उपयोग किया जाता है। यह **कंटेनरों के अंदर कमांड चलाने या एक शेल के अंदर जाने** की अनुमति देता है।
|
||||
|
||||
इसलिए, यह संभव है कि **एक पॉड के अंदर जाएं और SA का टोकन चुरा लें**, या एक विशेषाधिकार प्राप्त पॉड में प्रवेश करें, नोड पर भागें, और नोड में सभी पॉड्स के टोकन चुरा लें और (ab)node का उपयोग करें:
|
||||
```bash
|
||||
kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
> [!NOTE]
|
||||
> डिफ़ॉल्ट रूप से, कमांड पॉड के पहले कंटेनर में निष्पादित होता है। `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` के साथ **कंटेनर में सभी पॉड्स प्राप्त करें** और फिर **कंटेनर को इंगित करें** जहां आप इसे निष्पादित करना चाहते हैं `kubectl exec -it <pod_name> -c <container_name> -- sh` के साथ।
|
||||
> डिफ़ॉल्ट रूप से, कमांड पॉड के पहले कंटेनर में निष्पादित होता है। `kubectl get pods <pod_name> -o jsonpath='{.spec.containers[*].name}'` के साथ **कंटेनर में सभी पॉड्स प्राप्त करें** और फिर `kubectl exec -it <pod_name> -c <container_name> -- sh` के साथ **कंटेनर को इंगित करें** जहां आप इसे निष्पादित करना चाहते हैं।
|
||||
|
||||
यदि यह एक डिस्ट्रोलैस कंटेनर है, तो आप कंटेनरों की जानकारी प्राप्त करने के लिए **शेल बिल्ट-इन्स** का उपयोग करने या अपने स्वयं के उपकरण जैसे **busybox** को अपलोड करने का प्रयास कर सकते हैं: **`kubectl cp </path/local/file> <podname>:</path/in/container>`** का उपयोग करके।
|
||||
यदि यह एक डिस्ट्रोलैस कंटेनर है, तो आप कंटेनरों की जानकारी प्राप्त करने के लिए **शेल बिल्ट-इन्स** का उपयोग करने या **busybox** जैसे अपने उपकरणों को अपलोड करने का प्रयास कर सकते हैं: **`kubectl cp </path/local/file> <podname>:</path/in/container>`**।
|
||||
|
||||
### port-forward
|
||||
|
||||
@@ -208,13 +208,13 @@ kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Hosts Writable /var/log/ Escape
|
||||
|
||||
As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), यदि आप एक पॉड तक पहुँच सकते हैं या एक पॉड बना सकते हैं जिसमें **hosts `/var/log/` directory mounted** है, तो आप **container से बाहर निकल सकते हैं**।\
|
||||
यह मूल रूप से इस कारण है कि जब **Kube-API एक container के logs प्राप्त करने की कोशिश करता है** (using `kubectl logs <pod>`), तो यह **पॉड के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` endpoint का उपयोग करके अनुरोध करता है।\
|
||||
Kubelet सेवा `/logs/` endpoint को उजागर करती है जो मूल रूप से **container के `/var/log` filesystem को उजागर कर रही है**।
|
||||
As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), यदि आप एक पॉड तक पहुँच सकते हैं या एक पॉड बना सकते हैं जिसमें **होस्ट का `/var/log/` डायरेक्टरी माउंटेड** है, तो आप **कंटेनर से बाहर निकल सकते हैं**।\
|
||||
यह मूल रूप से इस कारण है कि जब **Kube-API एक कंटेनर के लॉग प्राप्त करने की कोशिश करता है** (using `kubectl logs <pod>`), तो यह **पॉड के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` एंडपॉइंट का उपयोग करके अनुरोध करता है।\
|
||||
Kubelet सेवा `/logs/` एंडपॉइंट को उजागर करती है जो मूल रूप से **कंटेनर के `/var/log` फ़ाइल सिस्टम को उजागर कर रही है**।
|
||||
|
||||
इसलिए, एक हमलावर जिसके पास **container के /var/log/ folder में लिखने की पहुँच है** वह इस व्यवहार का दुरुपयोग 2 तरीकों से कर सकता है:
|
||||
इसलिए, एक हमलावर जिसके पास **कंटेनर के /var/log/ फ़ोल्डर में लिखने की पहुँच है** वह इस व्यवहार का दुरुपयोग 2 तरीकों से कर सकता है:
|
||||
|
||||
- अपने container के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह **`/etc/shadow`** की ओर इशारा करने वाला एक **symlink** बन जाए। फिर, आप निम्नलिखित करके hosts shadow फ़ाइल को exfiltrate कर सकेंगे:
|
||||
- अपने कंटेनर के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह एक **सिंबलिंक हो जो `/etc/shadow`** की ओर इशारा करता हो, उदाहरण के लिए। फिर, आप निम्नलिखित करके होस्ट का शैडो फ़ाइल निकालने में सक्षम होंगे:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -315,7 +315,7 @@ https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Listing Secrets
|
||||
|
||||
**गुप्त सूचनाओं की सूची बनाने की अनुमति एक हमलावर को वास्तव में गुप्त सूचनाओं को पढ़ने की अनुमति दे सकती है** REST API एंडपॉइंट तक पहुँचते हुए:
|
||||
**गुप्त सूचनाओं की सूची बनाने की अनुमति एक हमलावर को वास्तव में गुप्त सूचनाओं को पढ़ने की अनुमति दे सकती है** REST API एंडपॉइंट तक पहुँचकर:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
@@ -385,15 +385,74 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
|
||||
### एक secret पढ़ना – टोकन IDs का ब्रूट-फोर्सिंग
|
||||
|
||||
जब एक हमलावर के पास पढ़ने की अनुमति वाला एक टोकन होता है, तो उसे इसका उपयोग करने के लिए secret का सही नाम चाहिए होता है, जबकि व्यापक _**secrets की सूची**_ विशेषता के विपरीत, अभी भी कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट service accounts को सूचीबद्ध किया जा सकता है, प्रत्येक एक secret से संबंधित होता है। इन secrets का नाम संरचना होती है: एक स्थिर उपसर्ग उसके बाद एक यादृच्छिक पांच-चरित्र अल्फ़ान्यूमेरिक टोकन (कुछ वर्णों को छोड़कर) [स्रोत कोड](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) के अनुसार।
|
||||
जब एक हमलावर के पास पढ़ने की अनुमति वाला एक टोकन होता है, तो उसे इसका उपयोग करने के लिए secret का सही नाम चाहिए होता है, जबकि व्यापक _**secrets की सूची**_ विशेषता के विपरीत, अभी भी कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट service accounts को सूचीबद्ध किया जा सकता है, प्रत्येक एक secret से जुड़ा होता है। इन secrets का नाम संरचना होती है: एक स्थिर उपसर्ग उसके बाद एक यादृच्छिक पांच-चर अल्फ़ान्यूमेरिक टोकन (कुछ वर्णों को छोड़कर) [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) के अनुसार।
|
||||
|
||||
टोकन एक सीमित 27-चरित्र सेट (`bcdfghjklmnpqrstvwxz2456789`) से उत्पन्न होता है, न कि पूर्ण अल्फ़ान्यूमेरिक रेंज से। यह सीमा कुल संभावित संयोजनों को 14,348,907 (27^5) तक कम कर देती है। परिणामस्वरूप, एक हमलावर संभवतः कुछ घंटों में टोकन का अनुमान लगाने के लिए एक ब्रूट-फोर्स हमले को निष्पादित कर सकता है, जो संवेदनशील service accounts तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना पैदा कर सकता है।
|
||||
टोकन एक सीमित 27-चर सेट (`bcdfghjklmnpqrstvwxz2456789`) से उत्पन्न होता है, न कि पूर्ण अल्फ़ान्यूमेरिक रेंज से। यह सीमा कुल संभावित संयोजनों को 14,348,907 (27^5) तक कम कर देती है। परिणामस्वरूप, एक हमलावर संभवतः कुछ घंटों में टोकन का पता लगाने के लिए एक ब्रूट-फोर्स हमले को निष्पादित कर सकता है, जो संवेदनशील service accounts तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना को जन्म दे सकता है।
|
||||
|
||||
### प्रमाणपत्र हस्ताक्षर अनुरोध
|
||||
### EncrpytionConfiguration स्पष्ट पाठ में
|
||||
|
||||
यदि आपके पास संसाधन `certificatesigningrequests` में **`create`** क्रियाएँ हैं (या कम से कम `certificatesigningrequests/nodeClient` में)। आप एक **नए नोड** का नया CeSR **बना** सकते हैं।
|
||||
इस प्रकार की वस्तु में डेटा को स्थिर करने के लिए एन्क्रिप्ट करने के लिए स्पष्ट पाठ कुंजी खोजना संभव है जैसे:
|
||||
```yaml
|
||||
# From https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
|
||||
|
||||
[दस्तावेज़ के अनुसार, इन अनुरोधों को स्वचालित रूप से स्वीकृत करना संभव है](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), इसलिए इस मामले में आपको **अतिरिक्त अनुमतियों की आवश्यकता नहीं है**। यदि नहीं, तो आपको अनुरोध को स्वीकृत करने में सक्षम होना चाहिए, जिसका अर्थ है `certificatesigningrequests/approval` में अपडेट करना और `signers` में `approve` करना, जिसमें resourceName `<signerNameDomain>/<signerNamePath>` या `<signerNameDomain>/*` हो।
|
||||
#
|
||||
# CAUTION: this is an example configuration.
|
||||
# Do not use this for your own cluster!
|
||||
#
|
||||
|
||||
apiVersion: apiserver.config.k8s.io/v1
|
||||
kind: EncryptionConfiguration
|
||||
resources:
|
||||
- resources:
|
||||
- secrets
|
||||
- configmaps
|
||||
- pandas.awesome.bears.example # a custom resource API
|
||||
providers:
|
||||
# This configuration does not provide data confidentiality. The first
|
||||
# configured provider is specifying the "identity" mechanism, which
|
||||
# stores resources as plain text.
|
||||
#
|
||||
- identity: {} # plain text, in other words NO encryption
|
||||
- aesgcm:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZQ==
|
||||
- name: key2
|
||||
secret: dGhpcyBpcyBwYXNzd29yZA==
|
||||
- secretbox:
|
||||
keys:
|
||||
- name: key1
|
||||
secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=
|
||||
- resources:
|
||||
- events
|
||||
providers:
|
||||
- identity: {} # do not encrypt Events even though *.* is specified below
|
||||
- resources:
|
||||
- '*.apps' # wildcard match requires Kubernetes 1.27 or later
|
||||
providers:
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key2
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZSwgb3IgaXMgaXQ/Cg==
|
||||
- resources:
|
||||
- '*.*' # wildcard match requires Kubernetes 1.27 or later
|
||||
providers:
|
||||
- aescbc:
|
||||
keys:
|
||||
- name: key3
|
||||
secret: c2VjcmV0IGlzIHNlY3VyZSwgSSB0aGluaw==
|
||||
```
|
||||
### Certificate Signing Requests
|
||||
|
||||
यदि आपके पास संसाधन `certificatesigningrequests` में **`create`** क्रिया है (या कम से कम `certificatesigningrequests/nodeClient` में)। आप **एक नए नोड का** नया CeSR **बनाने** में सक्षम हैं।
|
||||
|
||||
[दस्तावेज़ के अनुसार, इन अनुरोधों को स्वचालित रूप से स्वीकृत करना संभव है](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), इसलिए उस मामले में आपको **अतिरिक्त अनुमतियों की आवश्यकता नहीं है**। यदि नहीं, तो आपको अनुरोध को स्वीकृत करने में सक्षम होना चाहिए, जिसका अर्थ है `certificatesigningrequests/approval` में अपडेट करना और `signers` में `approve` करना, जिसमें resourceName `<signerNameDomain>/<signerNamePath>` या `<signerNameDomain>/*` हो।
|
||||
|
||||
एक **भूमिका का उदाहरण** जिसमें सभी आवश्यक अनुमतियाँ हैं:
|
||||
```yaml
|
||||
@@ -426,12 +485,12 @@ resourceNames:
|
||||
verbs:
|
||||
- approve
|
||||
```
|
||||
तो, नए नोड CSR के स्वीकृत होने के साथ, आप नोड्स की विशेष अनुमतियों का **दुरुपयोग** कर सकते हैं ताकि **गुप्त जानकारी चुराई** जा सके और **अधिकार बढ़ाए** जा सकें।
|
||||
तो, नए नोड CSR के अनुमोदित होने के साथ, आप नोड्स की विशेष अनुमतियों का **दुरुपयोग** करके **गुप्त जानकारियाँ चुरा सकते हैं** और **अधिकार बढ़ा सकते हैं**।
|
||||
|
||||
[**इस पोस्ट**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) और [**इस एक**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) में GKE K8s TLS Bootstrap कॉन्फ़िगरेशन को **स्वचालित हस्ताक्षर** के साथ कॉन्फ़िगर किया गया है और इसका दुरुपयोग नए K8s नोड के क्रेडेंशियल्स उत्पन्न करने के लिए किया गया है और फिर उन पर अधिकार बढ़ाने के लिए गुप्त जानकारी चुराई गई है।\
|
||||
यदि आपके पास **उल्लेखित अधिकार हैं तो आप वही कर सकते हैं**। ध्यान दें कि पहला उदाहरण उस त्रुटि को बायपास करता है जो नए नोड को कंटेनरों के अंदर गुप्त जानकारी तक पहुँचने से रोकता है क्योंकि **नोड केवल उन कंटेनरों के गुप्त जानकारी तक पहुँच सकता है जो उस पर माउंट किए गए हैं।**
|
||||
[**इस पोस्ट**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) और [**इस एक**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) में GKE K8s TLS बूटस्ट्रैप कॉन्फ़िगरेशन को **स्वचालित हस्ताक्षर** के साथ कॉन्फ़िगर किया गया है और इसका **दुरुपयोग** करके एक नए K8s नोड के क्रेडेंशियल्स उत्पन्न किए जाते हैं और फिर उन क्रेडेंशियल्स का उपयोग करके गुप्त जानकारियाँ चुराकर अधिकार बढ़ाए जाते हैं।\
|
||||
यदि आपके पास **उल्लेखित अधिकार हैं तो आप वही कर सकते हैं**। ध्यान दें कि पहला उदाहरण उस त्रुटि को बायपास करता है जो नए नोड को कंटेनरों के अंदर गुप्त जानकारियों तक पहुँचने से रोकता है क्योंकि **नोड केवल उन कंटेनरों के गुप्त जानकारियों तक पहुँच सकता है जो उस पर माउंट किए गए हैं।**
|
||||
|
||||
इसका बायपास करने का तरीका बस यह है कि **उस नोड नाम के लिए नोड क्रेडेंशियल्स बनाएं जहां दिलचस्प गुप्त जानकारी वाला कंटेनर माउंट किया गया है** (लेकिन पहले पोस्ट में इसे करने का तरीका देखें):
|
||||
इसका बायपास करने का तरीका बस यह है कि **उस नोड नाम के लिए नोड क्रेडेंशियल्स बनाएं जहाँ दिलचस्प गुप्त जानकारियों वाला कंटेनर माउंट किया गया है** (लेकिन पहले पोस्ट में इसे करने का तरीका देखें):
|
||||
```bash
|
||||
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
|
||||
```
|
||||
@@ -485,11 +544,11 @@ groups:
|
||||
|
||||
### CoreDNS config map
|
||||
|
||||
यदि आपके पास `kube-system` namespace में **`coredns` configmap** को संशोधित करने की अनुमति है, तो आप पता डोमेन को संशोधित कर सकते हैं ताकि आप MitM हमले कर सकें **संवेदनशील जानकारी चुराने या दुर्भावनापूर्ण सामग्री इंजेक्ट करने** के लिए।
|
||||
यदि आपके पास `kube-system` namespace में **`coredns` configmap** को संशोधित करने की अनुमति है, तो आप पता डोमेन को संशोधित कर सकते हैं ताकि आप **संवेदनशील जानकारी चुराने या दुर्भावनापूर्ण सामग्री इंजेक्ट करने** के लिए MitM हमले कर सकें।
|
||||
|
||||
आवश्यक क्रियाएँ **`update`** और **`patch`** हैं **`coredns`** configmap (या सभी config maps) पर।
|
||||
|
||||
एक नियमित **coredns फ़ाइल** में कुछ इस तरह का डेटा होता है:
|
||||
एक नियमित **coredns फ़ाइल** में कुछ ऐसा होता है:
|
||||
```yaml
|
||||
data:
|
||||
Corefile: |
|
||||
@@ -531,7 +590,7 @@ K8s अनुमतियों को GCP प्रिंसिपलों क
|
||||
> K8s एपीआई एंडपॉइंट से बात करते समय, **GCP ऑथ टोकन भेजा जाएगा**। फिर, GCP, K8s एपीआई एंडपॉइंट के माध्यम से, पहले **जांच करेगा कि प्रिंसिपल** (ईमेल द्वारा) **क्लस्टर के अंदर कोई पहुंच है या नहीं**, फिर यह जांचेगा कि क्या इसकी **GCP IAM के माध्यम से कोई पहुंच है**।\
|
||||
> यदि **कोई भी** इनमें से **सत्य** है, तो उसे **उत्तर दिया जाएगा**। यदि **नहीं** तो **GCP IAM के माध्यम से अनुमतियाँ देने** का सुझाव देने वाला एक **त्रुटि** दिया जाएगा।
|
||||
|
||||
फिर, पहला तरीका **GCP IAM** का उपयोग करना है, K8s अनुमतियों के उनके **समकक्ष GCP IAM अनुमतियाँ** हैं, और यदि प्रिंसिपल के पास यह है, तो वह इसका उपयोग कर सकेगा।
|
||||
फिर, पहला तरीका **GCP IAM** का उपयोग करना है, K8s अनुमतियों के उनके **समान GCP IAM अनुमतियाँ** हैं, और यदि प्रिंसिपल के पास यह है, तो वह इसका उपयोग कर सकेगा।
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md
|
||||
@@ -545,7 +604,7 @@ K8s अनुमतियों को GCP प्रिंसिपलों क
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादन प्राप्त कर सकते हैं**, और संभावित रूप से **अपने नोड से बाहर निकल सकते हैं** एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर।
|
||||
प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादन प्राप्त कर सकते हैं**, और संभावित रूप से **अपने नोड से बाहर** निकल सकते हैं एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर।
|
||||
|
||||
### ValidatingWebhookConfigurations या MutatingWebhookConfigurations
|
||||
|
||||
@@ -556,7 +615,7 @@ K8s अनुमतियों को GCP प्रिंसिपलों क
|
||||
### वृद्धि करना
|
||||
|
||||
जैसा कि आप अगले अनुभाग में पढ़ सकते हैं: [**निर्मित विशेषाधिकार वृद्धि रोकथाम**](#built-in-privileged-escalation-prevention), एक प्रिंसिपल नई अनुमतियों के बिना भूमिकाओं या क्लस्टर भूमिकाओं को न तो अपडेट कर सकता है और न ही बना सकता है। सिवाय इसके कि उसके पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate` या `*`** हो और संबंधित बाइंडिंग विकल्प।\
|
||||
तब वह नई भूमिकाएँ, क्लस्टर भूमिकाएँ बेहतर अनुमतियों के साथ अपडेट/बना सकता है जो उसके पास हैं।
|
||||
तब वह नई भूमिकाओं, क्लस्टर भूमिकाओं को बेहतर अनुमतियों के साथ अपडेट/बना सकता है जो उसके पास हैं।
|
||||
|
||||
### नोड्स प्रॉक्सी
|
||||
|
||||
@@ -566,7 +625,7 @@ K8s अनुमतियों को GCP प्रिंसिपलों क
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
आपके पास [**Kubelet API से अधिकृत बात करने पर RCE प्राप्त करने का एक उदाहरण यहां है**](../pentesting-kubernetes-services/index.html#kubelet-rce)।
|
||||
आपके पास [**Kubelet API से अधिकृत बात करते हुए RCE प्राप्त करने का एक उदाहरण यहां है**](../pentesting-kubernetes-services/index.html#kubelet-rce)।
|
||||
|
||||
### पॉड्स को हटाना + अस्थायी नोड्स
|
||||
|
||||
@@ -605,7 +664,7 @@ Kubernetes में विशेषाधिकार वृद्धि को
|
||||
> [!CAUTION]
|
||||
> **स्पष्ट रूप से यह तकनीक पहले काम करती थी, लेकिन मेरे परीक्षणों के अनुसार यह अब काम नहीं कर रही है उसी कारण से जो पिछले अनुभाग में समझाया गया है। यदि आपके पास पहले से अनुमतियाँ नहीं हैं तो आप अपने लिए या किसी अन्य SA को कुछ विशेषाधिकार देने के लिए एक भूमिका बाइंडिंग नहीं बना/संशोधित कर सकते।**
|
||||
|
||||
भूमिका बाइंडिंग बनाने का विशेषाधिकार एक उपयोगकर्ता को **भूमिकाओं को एक सेवा खाते से बाइंड करने** की अनुमति देता है। यह विशेषाधिकार संभावित रूप से विशेषाधिकार वृद्धि की ओर ले जा सकता है क्योंकि यह **उपयोगकर्ता को एक समझौता किए गए सेवा खाते को प्रशासनिक विशेषाधिकार बाइंड करने** की अनुमति देता है।
|
||||
भूमिका बाइंडिंग बनाने का विशेषाधिकार एक उपयोगकर्ता को **भूमिकाओं को एक सेवा खाते से बाइंड करने** की अनुमति देता है। यह विशेषाधिकार संभावित रूप से विशेषाधिकार वृद्धि की ओर ले जा सकता है क्योंकि यह **उपयोगकर्ता को एक समझौता किए गए सेवा खाते को प्रशासनिक विशेषाधिकार बाइंड करने की अनुमति देता है।**
|
||||
|
||||
## Other Attacks
|
||||
|
||||
@@ -627,7 +686,7 @@ image: nginx
|
||||
image: busybox
|
||||
command: ["sh","-c","<execute something in the same pod but different container>"]
|
||||
```
|
||||
उदाहरण के लिए, एक नए कंटेनर के साथ एक मौजूदा पॉड में बैकडोर करने के लिए, आप बस विनिर्देशन में एक नया कंटेनर जोड़ सकते हैं। ध्यान दें कि आप दूसरे कंटेनर को **अधिक अनुमतियाँ** दे सकते हैं जो पहले को नहीं मिलेंगी।
|
||||
उदाहरण के लिए, एक नए कंटेनर के साथ एक मौजूदा पॉड में बैकडोर करने के लिए, आप बस विनिर्देशन में एक नया कंटेनर जोड़ सकते हैं। ध्यान दें कि आप दूसरे कंटेनर को **अधिक अनुमति** दे सकते हैं जो पहले को नहीं मिलेगी।
|
||||
|
||||
अधिक जानकारी के लिए: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
@@ -637,7 +696,7 @@ command: ["sh","-c","<execute something in the same pod but different container>
|
||||
|
||||
यदि एक हमलावर किसी तरह **Mutation Admission Controller** को **इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** करने में सक्षम होगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रूप से बने रहना।
|
||||
|
||||
**उदाहरण** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
**उदाहरण** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) से:
|
||||
```bash
|
||||
git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
|
||||
cd malicious-admission-controller-webhook-demo
|
||||
@@ -656,14 +715,14 @@ kubectl get deploy,svc -n webhook-demo
|
||||
kubectl run nginx --image nginx
|
||||
kubectl get po -w
|
||||
```
|
||||
जब आप `ErrImagePull` त्रुटि देख सकते हैं, तो छवि नाम की जांच करें किसी एक प्रश्न के साथ:
|
||||
जब आप `ErrImagePull` त्रुटि देख सकते हैं, तो छवि नाम की जांच करें निम्नलिखित में से किसी एक क्वेरी के साथ:
|
||||
```bash
|
||||
kubectl get po nginx -o=jsonpath='{.spec.containers[].image}{"\n"}'
|
||||
kubectl describe po nginx | grep "Image: "
|
||||
```
|
||||
|
||||
|
||||
जैसा कि आप ऊपर की छवि में देख सकते हैं, हमने `nginx` इमेज चलाने की कोशिश की लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। क्या हुआ!!?
|
||||
जैसा कि आप ऊपर की छवि में देख सकते हैं, हमने `nginx` इमेज चलाने की कोशिश की, लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। क्या हुआ!!?
|
||||
|
||||
#### Technicalities
|
||||
|
||||
@@ -696,7 +755,7 @@ The above snippet replaces the first container image in every pod with `rewantht
|
||||
|
||||
### **Namespace-विशिष्ट Roles पर Cluster-Wide Roles**
|
||||
|
||||
- **Roles बनाम ClusterRoles**: ClusterRoles और ClusterRoleBindings के बजाय namespace-specific अनुमतियों के लिए Roles और RoleBindings का उपयोग करना पसंद करें, जो क्लस्टर-व्यापी लागू होते हैं। यह दृष्टिकोण अधिक नियंत्रण प्रदान करता है और अनुमतियों के दायरे को सीमित करता है।
|
||||
- **Roles बनाम ClusterRoles**: ClusterRoles और ClusterRoleBindings के बजाय namespace-विशिष्ट अनुमतियों के लिए Roles और RoleBindings का उपयोग करना पसंद करें, जो क्लस्टर-व्यापी लागू होते हैं। यह दृष्टिकोण अधिक नियंत्रण प्रदान करता है और अनुमतियों के दायरे को सीमित करता है।
|
||||
|
||||
### **स्वचालित उपकरणों का उपयोग करें**
|
||||
|
||||
|
||||
@@ -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 अनुमतियों की आवश्यकता होगी (और यह बहुत छिपा हुआ नहीं है)।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
Reference in New Issue
Block a user