AWS - EKS Post Exploitation

Reading time: 7 minutes

EKS

Pour plus d'informations, consultez

AWS - EKS Enum

Énumérer le cluster depuis la console AWS

Si vous avez la permission eks:AccessKubernetesApi, vous pouvez voir les objets Kubernetes via la console AWS EKS (En savoir plus).

Se connecter au cluster Kubernetes AWS

• Facile :

# Generate kubeconfig
aws eks update-kubeconfig --name aws-eks-dev

• Pas si facile :

Si vous pouvez obtenir un token avec aws eks get-token --name <cluster_name> mais que vous n'avez pas les permissions pour obtenir les informations du cluster (describeCluster), vous pourriez préparer votre propre ~/.kube/config. Cependant, avec le token, vous avez toujours besoin de l'url endpoint pour vous connecter (si vous avez réussi à obtenir un token JWT d'un pod lisez ici) et du nom du cluster.

Dans mon cas, je n'ai pas trouvé l'info dans les logs CloudWatch, mais j'ai trouvé dans les userData des LaunchTemplates et dans les machines EC2 dans userData aussi. Vous pouvez voir cette info dans userData facilement, par exemple dans l'exemple suivant (le nom du cluster était cluster-name) :

API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com

/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false

describe-cache-parametersapiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
contexts:
- context:
cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
kind: Config
preferences: {}
users:
- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args:
- --region
- us-west-2
- --profile
- <profile>
- eks
- get-token
- --cluster-name
- <cluster-name>
command: aws
env: null
interactiveMode: IfAvailable
provideClusterInfo: false

D'AWS à Kubernetes

Le créateur du cluster EKS sera TOUJOURS capable d'accéder à la partie du cluster kubernetes du groupe system:masters (admin k8s). Au moment de la rédaction de ce document, il n'y a aucun moyen direct de savoir qui a créé le cluster (vous pouvez vérifier CloudTrail). Et il n'y a aucun moyen de supprimer ce privilège.

La façon de donner accès à plus d'utilisateurs ou de rôles AWS IAM sur K8s est d'utiliser le configmap aws-auth.

Pour plus d'informations sur la façon de donner des privilèges supplémentaires aux rôles et utilisateurs IAM dans le même ou un autre compte et comment abuser de cela pour privesc, consultez cette page.

Vérifiez aussi ce post génial pour apprendre comment fonctionne l'authentification IAM -> Kubernetes.

De Kubernetes à AWS

Il est possible de permettre une authentification OpenID pour le compte de service kubernetes afin de leur permettre d'assumer des rôles dans AWS. Apprenez comment cela fonctionne sur cette page.

OBTENIR le point de terminaison de l'API Server à partir d'un jeton JWT

En décodant le jeton JWT, nous obtenons l'ID du cluster et aussi la région. Sachant que le format standard pour l'URL EKS est

https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com

Je n'ai trouvé aucune documentation qui explique les critères pour les 'deux caractères' et le 'nombre'. Mais en faisant quelques tests de mon côté, je vois que ceux-ci reviennent souvent :

• gr7
• yl4

Quoi qu'il en soit, ce ne sont que 3 caractères que nous pouvons brute-forcer. Utilisez le script ci-dessous pour générer la liste.

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))

Ensuite avec wfuzz

wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com

Contournement de CloudTrail

Si un attaquant obtient des identifiants d'un AWS avec permission sur un EKS. Si l'attaquant configure son propre kubeconfig (sans appeler update-kubeconfig) comme expliqué précédemment, le get-token ne génère pas de journaux dans Cloudtrail car il n'interagit pas avec l'API AWS (il crée simplement le token localement).

Ainsi, lorsque l'attaquant communique avec le cluster EKS, cloudtrail ne journalisera rien lié à l'utilisateur volé et y accédant.

Notez que le cluster EKS pourrait avoir des journaux activés qui enregistreront cet accès (bien que, par défaut, ils soient désactivés).

Rançon EKS ?

Par défaut, l'utilisateur ou le rôle qui a créé un cluster a TOUJOURS des privilèges d'administrateur sur le cluster. Et c'est le seul accès "sécurisé" qu'AWS aura sur le cluster Kubernetes.

Donc, si un attaquant compromet un cluster en utilisant fargate et supprime tous les autres administrateurs et supprime l'utilisateur/rôle AWS qui a créé le cluster, l'attaquant pourrait avoir rançonné le cluster.