mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+47
-27
@@ -4,28 +4,28 @@
|
||||
|
||||
## EKS
|
||||
|
||||
Per maggiori informazioni consulta
|
||||
Per ulteriori informazioni controlla
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-eks-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Enumerare il cluster dalla AWS Console
|
||||
### Enumerate the cluster from the AWS Console
|
||||
|
||||
Se hai il permesso **`eks:AccessKubernetesApi`** puoi **visualizzare oggetti Kubernetes** tramite la console AWS EKS ([Scopri di più](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
Se hai il permesso **`eks:AccessKubernetesApi`** puoi **visualizzare gli oggetti Kubernetes** tramite la console AWS EKS ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
|
||||
|
||||
### Connettersi al cluster Kubernetes AWS
|
||||
### Connect to AWS Kubernetes Cluster
|
||||
|
||||
- Metodo semplice:
|
||||
- Easy way:
|
||||
```bash
|
||||
# Generate kubeconfig
|
||||
aws eks update-kubeconfig --name aws-eks-dev
|
||||
```
|
||||
- Non è così semplice:
|
||||
|
||||
Se puoi **ottenere un token** con **`aws eks get-token --name <cluster_name>`** ma non hai i permessi per ottenere le informazioni del cluster (describeCluster), puoi **preparare il tuo `~/.kube/config`**. Tuttavia, avendo il token, ti serve comunque l'**endpoint URL a cui connetterti** (se sei riuscito a ottenere un JWT token da un pod leggi [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) e il **nome del cluster**.
|
||||
Se puoi **ottenere un token** con **`aws eks get-token --name <cluster_name>`** ma non hai i permessi per ottenere le info del cluster (describeCluster), potresti **preparare il tuo `~/.kube/config`**. Tuttavia, avendo il token, ti serve ancora il **url endpoint a cui connetterti** (se sei riuscito a ottenere un JWT token da un pod leggi [qui](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) e il **nome del cluster**.
|
||||
|
||||
Nel mio caso, non ho trovato le informazioni nei log di CloudWatch, ma le **ho trovate in LaunchTemaplates userData** e anche nelle **macchine EC2 in userData**. Puoi vedere queste informazioni in **userData** facilmente, per esempio nel seguente esempio (il nome del cluster era cluster-name):
|
||||
Nel mio caso, non ho trovato le info nei log di CloudWatch, ma le ho **trovate nei userData dei LaunchTemaplates** e anche **nelle macchine EC2 nei userData**. Puoi vedere queste info nei **userData** facilmente, per esempio nel prossimo esempio (il nome del cluster era 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
|
||||
### Da AWS a Kubernetes
|
||||
|
||||
Il **creator** del **EKS cluster** potrà **SEMPRE** accedere alla parte del cluster kubernetes del gruppo **`system:masters`** (k8s admin). Al momento della stesura non esiste **un modo diretto** per scoprire **chi ha creato** il cluster (puoi controllare CloudTrail). E non esiste **alcun modo** per **rimuovere** quel **privilegio**.
|
||||
Il **creator** del **cluster EKS** avrà **SEMPRE** la possibilità di accedere alla parte del cluster kubernetes del gruppo **`system:masters`** (k8s admin). Al momento in cui scriviamo **non esiste un modo diretto** per sapere **chi ha creato** il cluster (puoi controllare CloudTrail). E **non c'è modo** di **rimuovere** questo **privilege**.
|
||||
|
||||
Il modo per concedere **accesso a K8s a più AWS IAM users o roles** è usando la **configmap** **`aws-auth`**.
|
||||
#### Abusing configmap
|
||||
|
||||
Il modo tradizionale per concedere **accesso a over K8s a più utenti o ruoli AWS IAM** è usando la **configmap** **`aws-auth`**.
|
||||
|
||||
> [!WARNING]
|
||||
> Quindi, chiunque abbia **accesso in scrittura** alla config map **`aws-auth`** sarà in grado di **compromettere l'intero cluster**.
|
||||
> Quindi, chiunque abbia **write access** sulla config map **`aws-auth`** potrà **compromettere l'intero cluster**.
|
||||
|
||||
Per maggiori informazioni su come **concedere privilegi extra a IAM roles & users** nello **stesso o in un account diverso** e come **abusarne** per fare [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
Per maggiori informazioni su come **concedere privilegi extra a ruoli e utenti IAM** nello **stesso o diverso account** e su come **abusing** questo per [**privesc controlla questa pagina**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
|
||||
|
||||
Vedi anche[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post per capire come funziona l'autenticazione IAM -> Kubernetes**.
|
||||
Guarda anche[ **questo ottimo**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post per imparare come funziona l'autenticazione IAM -> Kubernetes**.
|
||||
|
||||
### From Kubernetes to AWS
|
||||
#### Abusing Access Entries
|
||||
|
||||
È possibile permettere un'autenticazione OpenID per i kubernetes service account per consentire loro di assumere ruoli in AWS. Scopri come [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
AWS implementa un modo aggiuntivo per concedere agli utenti IAM accesso al cluster Kubernetes tramite access entries. Se hai i permessi `eks:CreateAccessEntry` e `eks:AssociateAccessPolicy`, potresti anche essere in grado di assegnare un ruolo di amministratore Kubernetes al tuo utente o a un ruolo specifico.
|
||||
|
||||
### GET Api Server Endpoint from a JWT Token
|
||||
Per prima cosa, **crea un access entry per il tuo utente o ruolo**:
|
||||
```
|
||||
aws eks create-access-entry --cluster-name <cluster_name> --region <region> --principal-arn <arn_from_your_user_or_role> --type STANDARD
|
||||
```
|
||||
Con quella voce creata, ora potresti essere in grado di assegnarle direttamente una policy. Esiste una policy AWS integrata chiamata *AmazonEKSClusterAdminPolicy* che può essere usata direttamente. Tieni presente che, se il tuo ambiente ha altre policy personalizzate che concedono anche privilegi elevati in EKS, puoi modificare `--policy-arn` con una qualsiasi di quelle:
|
||||
```
|
||||
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
|
||||
```
|
||||
Puoi cercare questa policy nella documentazione ufficiale di AWS [**qui**](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html#access-policy-permissions-amazoneksclusteradminpolicy)
|
||||
|
||||
Decodificando il token JWT otteniamo il cluster id e anche la regione.  Sapendo che il formato standard per l'url EKS è
|
||||
Da questo punto in poi, potresti ora essere in grado di richiedere un token *k8s* e interagire con il cluster come amministratore:
|
||||
```
|
||||
aws eks get-token --cluster-name <cluster_name> --output json | jq -r '.status.token'
|
||||
```
|
||||
### Da Kubernetes a AWS
|
||||
|
||||
È possibile consentire un'autenticazione **OpenID per kubernetes service account** per permettere loro di assumere ruoli in AWS. Scopri come [**questo funziona in questa pagina**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
|
||||
|
||||
### GET Api Server Endpoint da un JWT Token
|
||||
|
||||
Decodificando il token JWT otteniamo l'id del cluster e anche la regione.  Sapendo che il formato standard per l'url EKS è
|
||||
```bash
|
||||
https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
|
||||
```
|
||||
Non ho trovato alcuna documentazione che spieghi i criteri per i 'due caratteri' e il 'numero'. Però, facendo alcuni test per mio conto, vedo ricorrere questi:
|
||||
Non ho trovato alcuna documentazione che spieghi i criteri per i 'two chars' e il 'number'. Ma facendo alcuni test da parte mia ne vedo ricorrenti questi:
|
||||
|
||||
- gr7
|
||||
- yl4
|
||||
|
||||
Comunque sono solo 3 caratteri: possiamo eseguire il bruteforce su di essi. Usa lo script qui sotto per generare la lista
|
||||
Comunque sono solo 3 chars, possiamo bruteforcarli. Usa lo script qui sotto per generare la lista
|
||||
```python
|
||||
from itertools import product
|
||||
from string import ascii_lowercase
|
||||
@@ -119,25 +139,25 @@ Poi con wfuzz
|
||||
wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
|
||||
```
|
||||
> [!WARNING]
|
||||
> Ricorda di sostituire & .
|
||||
> Remember to replace & .
|
||||
|
||||
### 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).
|
||||
Se un attacker ottiene le credenziali di un AWS con **permission over an EKS**. Se l'attacker configura il proprio **`kubeconfig`** (senza chiamare **`update-kubeconfig`**) come spiegato in precedenza, **`get-token`** non genera log in Cloudtrail perché non interagisce con l'API AWS (crea solo il token localmente).
|
||||
|
||||
So when the attacker talks with the EKS cluster, **cloudtrail won't log anything related to the user being stolen and accessing it**.
|
||||
Quindi, quando l'attacker comunica con il cluster EKS, **cloudtrail non registrerà nulla relativo all'utente rubato e al suo accesso**.
|
||||
|
||||
Note that the **EKS cluster might have logs enabled** that will log this access (although, by default, they are disabled).
|
||||
Nota che il cluster **EKS potrebbe avere i log abilitati** che registreranno questo accesso (anche se, per impostazione predefinita, sono disabilitati).
|
||||
|
||||
### EKS Ransom?
|
||||
|
||||
Di default lo **user or role that created** un cluster avrà **ALWAYS admin privileges** sul cluster. E questo è l'unico accesso "secure" che AWS avrà sul Kubernetes cluster.
|
||||
Per impostazione predefinita, l'**user or role that created** un cluster avrà **SEMPRE** privilegi admin sul cluster. Ed è l'unico accesso "secure" che AWS avrà sul cluster Kubernetes.
|
||||
|
||||
Quindi, se un **attacker compromette un cluster usando fargate** e **rimuove tutti gli altri admins** e **elimina lo AWS user/role che ha creato** il Cluster, ~~the attacker could have **ransomed the cluste**~~**r**.
|
||||
Quindi, se un **attacker compromette un cluster usando fargate** e **rimuove tutti gli altri admin** e d**elete the AWS user/role that created** il Cluster, ~~l'attacker potrebbe aver **ransomato il cluste**~~**r**.
|
||||
|
||||
> [!TIP]
|
||||
> Nota che se il cluster stava usando **EC2 VMs**, potrebbe essere possibile ottenere privilegi Admin dal **Node** e recuperare il cluster.
|
||||
> Nota che se il cluster usava **EC2 VMs**, potrebbe essere possibile ottenere privilegi Admin dal **Node** e recuperare il cluster.
|
||||
>
|
||||
> In realtà, se il cluster usa Fargate potresti creare EC2 nodes o spostare tutto su EC2 nel cluster e recuperarlo accedendo ai tokens nel node.
|
||||
> In realtà, se il cluster usa Fargate potresti usare nodi EC2 o spostare tutto su EC2 nel cluster e recuperarlo accedendo ai token nel node.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user