AWS - EKS Post Exploitation
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Para más información consulta
AWS - EKS EnumSi tienes el permiso eks:AccessKubernetesApi puedes ver objetos de Kubernetes a través de la consola de AWS EKS (Aprende más).
Forma fácil:
No es tan fácil:
Si puedes obtener un token con aws eks get-token --name <cluster_name> pero no tienes permisos para obtener información del clúster (describeCluster), podrías preparar tu propio ~/.kube/config. Sin embargo, teniendo el token, aún necesitas la url del endpoint para conectarte (si lograste obtener un token JWT de un pod lee aquí) y el nombre del clúster.
En mi caso, no encontré la información en los registros de CloudWatch, pero la encontré en LaunchTemplates userData y en máquinas EC2 en userData también. Puedes ver esta información en userData fácilmente, por ejemplo en el siguiente ejemplo (el nombre del clúster era cluster-name):
El creador del clúster EKS SIEMPRE podrá acceder a la parte del clúster de kubernetes del grupo system:masters (administrador de k8s). En el momento de escribir esto, no hay una forma directa de encontrar quién creó el clúster (puedes verificar CloudTrail). Y no hay forma de eliminar ese privilegio.
La forma de otorgar acceso a más usuarios o roles de AWS IAM sobre K8s es utilizando el configmap aws-auth.
Por lo tanto, cualquier persona con acceso de escritura sobre el config map aws-auth podrá comprometer todo el clúster.
Para más información sobre cómo otorgar privilegios adicionales a roles y usuarios de IAM en la misma o diferente cuenta y cómo abusar de esto, verifica esta página.
Consulta también esta increíble publicación para aprender cómo funciona la autenticación IAM -> Kubernetes.
Es posible permitir una autenticación OpenID para la cuenta de servicio de kubernetes para permitirles asumir roles en AWS. Aprende cómo esto funciona en esta página.
Decodificando el token JWT obtenemos el id del clúster y también la región. Sabiendo que el formato estándar para la URL de EKS es
No encontré ninguna documentación que explique los criterios para los 'dos caracteres' y el 'número'. Pero haciendo algunas pruebas por mi cuenta, veo que se repiten estos:
gr7
yl4
De todos modos, son solo 3 caracteres que podemos brute forcear. Usa el siguiente script para generar la lista.
Entonces con wfuzz
Recuerda reemplazar & .
Si un atacante obtiene credenciales de un AWS con permiso sobre un EKS. Si el atacante configura su propio kubeconfig (sin llamar a update-kubeconfig) como se explicó anteriormente, el get-token no genera registros en Cloudtrail porque no interactúa con la API de AWS (solo crea el token localmente).
Así que cuando el atacante se comunica con el clúster EKS, cloudtrail no registrará nada relacionado con el usuario que fue robado y accediendo a él.
Ten en cuenta que el clúster EKS podría tener registros habilitados que registrarán este acceso (aunque, por defecto, están deshabilitados).
Por defecto, el usuario o rol que creó un clúster SIEMPRE tendrá privilegios de administrador sobre el clúster. Y ese es el único acceso "seguro" que AWS tendrá sobre el clúster de Kubernetes.
Así que, si un atacante compromete un clúster usando fargate y elimina a todos los demás administradores y elimina el usuario/rol de AWS que creó el clúster, el atacante podría haber secuestrado el clúster.
Ten en cuenta que si el clúster estaba usando EC2 VMs, podría ser posible obtener privilegios de administrador desde el Nodo y recuperar el clúster.
De hecho, si el clúster está usando Fargate, podrías EC2 nodes o mover todo a EC2 al clúster y recuperarlo accediendo a los tokens en el nodo.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
