AWS - EKS Post Exploitation
EKS
Pour plus d'informations, consultez
É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 :
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 je l'ai trouvée dans les userData de 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) :
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'existe 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
.
Par conséquent, toute personne ayant un accès en écriture sur le config map aws-auth
sera capable de compromettre l'ensemble du cluster.
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
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 :
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.
Alors avec wfuzz
N'oubliez pas de remplacer & .
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 peut avoir des journaux activés qui enregistreront cet accès (bien qu'ils soient désactivés par défaut).
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 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.
Notez que si le cluster utilisait des VM EC2, il pourrait être possible d'obtenir des privilèges d'administrateur depuis le Node et de récupérer le cluster.
En fait, si le cluster utilise Fargate, vous pourriez utiliser des nœuds EC2 ou déplacer tout vers EC2 pour le cluster et le récupérer en accédant aux tokens dans le nœud.
Last updated