Skip to content

Commit

Permalink
Merge pull request #47 from IadRabbit/patch-1
Browse files Browse the repository at this point in the history
Update aws-eks-post-exploitation.md
  • Loading branch information
carlospolop committed Apr 30, 2024
2 parents ebd97e1 + 60f78b2 commit 1dd3f70
Showing 1 changed file with 37 additions and 1 deletion.
Original file line number Diff line number Diff line change
Expand Up @@ -37,7 +37,7 @@ aws eks update-kubeconfig --name aws-eks-dev

* Not that easy way:

If you can **get a token** with **`aws eks get-token --name <cluster_name>`** but you don't have permissions to get cluster info (describeCluster), you could **prepare your own `~/.kube/config`**. However, having the token, you still need the **url endpoint to connect to** and the **name of the cluster**.
If you can **get a token** with **`aws eks get-token --name <cluster_name>`** but you don't have permissions to get cluster info (describeCluster), you could **prepare your own `~/.kube/config`**. However, having the token, you still need the **url endpoint to connect to** (if you managed to get a JWT token from a pod read [here](#get-api-server-endpoint-from-a-jwt-token)) and the **name of the cluster**.

In my case, I didn't find the info in CloudWatch logs, but I **found it in LaunchTemaplates userData** and in **EC2 machines in userData also**. You can see this info in **userData** easily, for example in the next example (the cluster name was cluster-name):

Expand Down Expand Up @@ -108,6 +108,42 @@ Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentic

It's possible to allow an **OpenID authentication for kubernetes service account** to allow them to assume roles in AWS. Learn how [**this work in this page**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).

### GET Api Server Endpoint from a JWT Token

Decoding the JWT token we get the cluster id & also the region.
![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9)
Knowing that the standard format for EKS url is
```bash
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
```
Didn't find any documentation that explain the criteria for the 'two chars' and the 'number'. But making some test on my behalf I see recurring these one:
- gr7
- yl4

Anyway are just 3 chars we can bruteforce them. Use the below script for generating the list
```python
from itertools import product
from string import ascii_lowercase

letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
number_combinations = product('0123456789', repeat = 1)

result = [
f'{''.join(comb[0])}{comb[1][0]}'
for comb in product(letter_combinations, number_combinations)
]

with open('out.txt', 'w') as f:
f.write('\n'.join(result))
```
Then with wfuzz
```bash
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
```
{% hint style="warning" %}
Remember to replace <cluster-id> & <region>.
{% endhint %}

### Bypass CloudTrail

If an attacker obtains credentials of an AWS with **permission over an EKS**. If the attacker configures it's own **`kubeconfig`** (without calling **`update-kubeconfig`**) as explained previously, the **`get-token`** doesn't generate logs in Cloudtrail because it doesn't interact with the AWS API (it just creates the token locally).
Expand Down

0 comments on commit 1dd3f70

Please sign in to comment.