mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-06-12 19:11:44 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+46
-26
@@ -10,11 +10,11 @@
|
||||
../../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enumerate the cluster from the AWS Console
|
||||
### AWS Console से cluster enumerate करें
|
||||
|
||||
यदि आपके पास अनुमति **`eks:AccessKubernetesApi`** है, तो आप AWS EKS console के माध्यम से **Kubernetes objects** देख सकते हैं ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
यदि आपके पास permission **`eks:AccessKubernetesApi`** है, तो आप AWS EKS console के जरिए **Kubernetes objects** **देख** सकते हैं ([और जानें](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html))।
|
||||
|
||||
### Connect to AWS Kubernetes Cluster
|
||||
### AWS Kubernetes Cluster से connect करें
|
||||
|
||||
- आसान तरीका:
|
||||
```bash
|
||||
@@ -23,9 +23,9 @@ aws eks update-kubeconfig --name aws-eks-dev
|
||||
```
|
||||
- इतना आसान तरीका नहीं:
|
||||
|
||||
यदि आप **get a token** के साथ **`aws eks get-token --name <cluster_name>`** प्राप्त कर सकते हैं पर आपके पास cluster info (describeCluster) पाने की permissions नहीं हैं, तो आप अपना खुद का **`~/.kube/config`** तैयार कर सकते हैं। हालांकि, token होने के बावजूद, आपको अभी भी कनेक्ट करने के लिए **url endpoint to connect to** चाहिए (यदि आपने pod से JWT token प्राप्त किया है तो [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) पढ़ें) और **name of the cluster** भी चाहिए।
|
||||
यदि आप **`aws eks get-token --name <cluster_name>`** के साथ **token** **get** कर सकते हैं, लेकिन आपके पास cluster info (**describeCluster**) get करने की permissions नहीं हैं, तो आप **अपना खुद का `~/.kube/config`** prepare कर सकते हैं। हालांकि, token होने के बावजूद, आपको अभी भी connect करने के लिए **url endpoint** चाहिए (यदि आपने किसी pod से JWT token हासिल किया है, तो [यहाँ](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) पढ़ें) और **cluster का name** भी चाहिए।
|
||||
|
||||
मेरे केस में, मैंने जानकारी CloudWatch logs में नहीं पाई, लेकिन मैंने इसे LaunchTemaplates userData में पाया और EC2 machines के userData में भी। आप यह जानकारी userData में आसानी से देख सकते हैं, उदाहरण के लिए अगले उदाहरण में (the cluster name was cluster-name):
|
||||
मेरे मामले में, मुझे CloudWatch logs में info नहीं मिली, लेकिन मुझे यह **LaunchTemaplates userData** में और **EC2 machines के userData** में भी **found** हुई। आप यह info **userData** में आसानी से देख सकते हैं, उदाहरण के लिए अगले उदाहरण में (cluster name cluster-name था):
|
||||
```bash
|
||||
API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
|
||||
|
||||
@@ -70,35 +70,55 @@ provideClusterInfo: false
|
||||
```
|
||||
</details>
|
||||
|
||||
### From AWS to Kubernetes
|
||||
### AWS से Kubernetes तक
|
||||
|
||||
The **निर्माता** of the **EKS cluster** **हमेशा** kubernetes क्लस्टर के group **`system:masters`** (k8s admin) हिस्से में पहुँचने में सक्षम होगा। इस लेखन के समय यह पता लगाने का **कोई प्रत्यक्ष तरीका** नहीं है **कि किसने** क्लस्टर बनाया था (आप CloudTrail चेक कर सकते हैं)। और उस **privilege** को **हटाने** का **कोई तरीका** नहीं है।
|
||||
**EKS cluster** का **creator** **ALWAYS** kubernetes cluster के उस हिस्से में जा सकेगा जो group **`system:masters`** (k8s admin) का है। इस लेखन के समय **यह पता लगाने का कोई direct तरीका नहीं** है कि cluster **किसने बनाया** था (आप CloudTrail check कर सकते हैं)। और इस **privilege** को **remove** करने का **कोई तरीका नहीं** है।
|
||||
|
||||
The way to grant **K8s पर अधिक AWS IAM users या roles को access देने का तरीका** is using the **configmap** **`aws-auth`**.
|
||||
#### configmap का abuse
|
||||
|
||||
**अधिक AWS IAM users या roles** को **K8s तक access** देने का traditional तरीका **configmap** **`aws-auth`** का उपयोग करना है।
|
||||
|
||||
> [!WARNING]
|
||||
> इसलिए, जिनके पास config map **`aws-auth`** पर **write access** है वे पूरे क्लस्टर को **compromise** कर सकेंगे।
|
||||
> इसलिए, जिसके पास **config map `aws-auth`** पर **write access** है, वह **पूरे cluster को compromise** कर सकेगा।
|
||||
|
||||
For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
**उसी या अलग account** में **IAM roles & users** को extra privileges **grant** करने के बारे में अधिक जानकारी के लिए और [**privesc के लिए इसका abuse**] करने के लिए यह page देखें (../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
|
||||
**IAM -> Kubernetes authentication** कैसे काम करता है, यह सीखने के लिए [**यह awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post** भी देखें।
|
||||
|
||||
### Kubernetes से AWS
|
||||
#### Access Entries का abuse
|
||||
|
||||
यह संभव है कि kubernetes service account के लिए **OpenID authentication** की अनुमति दी जाए ताकि वे AWS में roles assume कर सकें। Learn how [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
AWS ने IAM users को access entries के through Kubernetes cluster तक access देने का एक अतिरिक्त तरीका implement किया है। यदि आपके पास `eks:CreateAccessEntry` और `eks:AssociateAccessPolicy` permissions हैं, तो आप अपने user या किसी specific role को Kubernetes administrator role भी assign कर सकते हैं।
|
||||
|
||||
### GET Api Server Endpoint from a JWT Token
|
||||
सबसे पहले, **अपने user या role के लिए एक access entry create करें**:
|
||||
```
|
||||
aws eks create-access-entry --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --type STANDARD
|
||||
```
|
||||
उस एंट्री के बन जाने के बाद, अब आप उस पर सीधे एक policy असाइन करने में सक्षम हो सकते हैं। एक built-in AWS policy होती है जिसका नाम *AmazonEKSClusterAdminPolicy* है, जिसे सीधे इस्तेमाल किया जा सकता है। ध्यान रखें कि अगर आपके environment में कुछ अन्य custom policies भी हैं जो EKS में elevated privileges देती हैं, तो आप `--policy-arn` को उनमें से किसी भी policy में बदल सकते हैं:
|
||||
```
|
||||
aws eks associate-access-policy --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy --access-scope type=cluster
|
||||
```
|
||||
आप इस नीति को AWS आधिकारिक दस्तावेज़ में [**यहाँ**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy) खोज सकते हैं
|
||||
|
||||
JWT token को decode करने पर हमें cluster id & साथ ही region मिलते हैं।  यह जानते हुए कि EKS url का standard format है
|
||||
इस बिंदु से आगे, अब आप एक *k8s* token का अनुरोध कर सकते हैं और cluster के साथ administrator के रूप में interact कर सकते हैं:
|
||||
```
|
||||
aws eks get-token --cluster-name <cluster_name> --output json | jq -r '.status.token'
|
||||
```
|
||||
### Kubernetes से AWS तक
|
||||
|
||||
**kubernetes service account** के लिए **OpenID authentication** को allow करना संभव है ताकि वे AWS में roles assume कर सकें। जानें कि [**यह कैसे काम करता है इस पेज में**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
|
||||
### JWT Token से GET Api Server Endpoint
|
||||
|
||||
JWT token को decode करने पर हमें cluster id और region भी मिलता है।  यह जानते हुए कि EKS url का standard format है
|
||||
```bash
|
||||
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
|
||||
```
|
||||
ऐसी कोई दस्तावेज़ नहीं मिली जो 'two chars' और 'number' के मानदंडों की व्याख्या करे। पर मेरी ओर से किए गए कुछ परीक्षणों में ये बार-बार दिखे:
|
||||
'दो chars' और 'number' के criteria को explain करने वाला कोई documentation नहीं मिला। लेकिन अपनी तरफ से कुछ test करने पर मुझे ये बार-बार दिखे:
|
||||
|
||||
- gr7
|
||||
- yl4
|
||||
|
||||
वैसे ये सिर्फ 3 chars हैं — इन्हें हम bruteforce कर सकते हैं। सूची जनरेट करने के लिए नीचे दिए गए script का उपयोग करें
|
||||
खैर, ये सिर्फ 3 chars हैं, हम इन्हें bruteforce कर सकते हैं। list generate करने के लिए नीचे वाला script use करें
|
||||
```python
|
||||
from itertools import product
|
||||
from string import ascii_lowercase
|
||||
@@ -119,25 +139,25 @@ f.write('\n'.join(result))
|
||||
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
|
||||
```
|
||||
> [!WARNING]
|
||||
> इन्हें बदलना याद रखें & .
|
||||
> याद रखें कि & . को बदलना है
|
||||
|
||||
### CloudTrail को बायपास करें
|
||||
### CloudTrail को Bypass करना
|
||||
|
||||
यदि कोई attacker AWS के credentials प्राप्त कर लेता है जिसके पास **permission over an EKS** है। यदि attacker अपना खुद का **`kubeconfig`** (जैसा पहले बताया गया, **`update-kubeconfig`** को कॉल किए बिना) कॉन्फ़िगर करता है, तो **`get-token`** Cloudtrail में logs जनरेट नहीं करता क्योंकि यह AWS API के साथ इंटरैक्ट नहीं करता (यह सिर्फ token लोकली बनाता है)।
|
||||
यदि किसी attacker को **EKS पर permission** वाले AWS के credentials मिल जाते हैं। यदि attacker पहले बताए अनुसार अपना **`kubeconfig`** (बिना **`update-kubeconfig`** को call किए) configure करता है, तो **`get-token`** Cloudtrail में logs generate नहीं करता क्योंकि यह AWS API के साथ interact नहीं करता (यह बस token को locally create करता है)।
|
||||
|
||||
तो जब attacker EKS cluster के साथ संचार करता है, **cloudtrail उस चोरी किए गए user द्वारा किए गए access से संबंधित कुछ भी लॉग नहीं करेगा**।
|
||||
इसलिए जब attacker EKS cluster से बात करता है, **cloudtrail उस user के stolen होने और उसे access करने से related कुछ भी log नहीं करेगा**।
|
||||
|
||||
ध्यान दें कि **EKS cluster might have logs enabled** जो इस access को log करेंगे (हालाँकि, by default वे disabled होते हैं)।
|
||||
ध्यान दें कि **EKS cluster में logs enabled** हो सकते हैं जो इस access को log करेंगे (हालाँकि, by default, वे disabled होते हैं)।
|
||||
|
||||
### EKS Ransom?
|
||||
|
||||
Default रूप से जो **user or role that created** एक cluster है उसे cluster पर **ALWAYS going to have admin privileges** मिलेंगे। और वही AWS का Kubernetes cluster पर एकमात्र "secure" access होगा।
|
||||
By default **user या role जिसने cluster बनाया था** उसके पास cluster पर **ALWAYS** admin privileges होंगे। और यही Kubernetes cluster पर AWS का एकमात्र "secure" access होगा।
|
||||
|
||||
तो, यदि एक **attacker compromises a cluster using fargate** और **removes all the other admins** और d**eletes the AWS user/role that created** the Cluster, ~~the attacker could have **ransomed the cluste**~~**r**।
|
||||
इसलिए, यदि कोई **attacker fargate का उपयोग करने वाले cluster को compromise करता है** और **बाकी सभी admins को हटाता है** तथा **Cluster बनाने वाले AWS user/role को delete** कर देता है, तो ~~attacker cluster को **ransom** कर सकता था~~**r** सकता है।
|
||||
|
||||
> [!TIP]
|
||||
> ध्यान दें कि यदि cluster **EC2 VMs** का उपयोग कर रहा था, तो संभव है कि **Node** से Admin privileges प्राप्त करके cluster को recover किया जा सके।
|
||||
> ध्यान दें कि यदि cluster **EC2 VMs** का उपयोग कर रहा था, तो **Node** से Admin privileges प्राप्त करना और cluster को recover करना संभव हो सकता था।
|
||||
>
|
||||
> वास्तव में, यदि cluster Fargate का उपयोग कर रहा है आप EC2 nodes कर सकते हैं या सब कुछ EC2 पर मूव करके cluster को recover कर सकते हैं और node में मौजूद tokens को एक्सेस करके उसे वापस ले सकते हैं।
|
||||
> वास्तव में, यदि cluster Fargate का उपयोग कर रहा है तो आप EC2 nodes का उपयोग कर सकते हैं या सब कुछ EC2 पर move कर सकते हैं और node में tokens access करके उसे recover कर सकते हैं।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user