AWS - EKS Post Exploitation
EKS
Para más información, consulta
AWS - EKS EnumEnumerar el clúster desde la Consola de AWS
Si tienes el permiso eks:AccessKubernetesApi
puedes ver objetos de Kubernetes a través de la consola de AWS EKS (Aprende más).
Conectar al Clúster de Kubernetes de AWS
Forma sencilla:
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 punto final para conectarte (si lograste obtener un token JWT desde 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 el userData de LaunchTemplates y también en userData de las máquinas EC2. Puedes ver esta información en userData fácilmente, por ejemplo en el siguiente ejemplo (el nombre del clúster era cluster-name):
De AWS a Kubernetes
El creador del cluster EKS SIEMPRE podrá acceder al cluster de Kubernetes como parte del grupo system:masters
(admin de k8s). En el momento de escribir esto, no hay una forma directa de encontrar quién creó el cluster (puedes verificar en CloudTrail). Y no hay forma de eliminar ese privilegio.
La forma de otorgar acceso sobre K8s a más usuarios o roles de AWS IAM es utilizando el configmap aws-auth
.
Por lo tanto, cualquier persona con acceso de escritura sobre el configmap aws-auth
podrá comprometer todo el cluster.
Para obtener más información sobre cómo otorgar privilegios adicionales a roles y usuarios de IAM en la misma cuenta o en cuentas diferentes y cómo abusar de esto, visita esta página.
Consulta también este increíble post para aprender cómo funciona la autenticación IAM -> Kubernetes.
De Kubernetes a AWS
Es posible permitir una autenticación OpenID para la cuenta de servicio de Kubernetes para permitirles asumir roles en AWS. Aprende cómo funciona esto en esta página.
Obtener el Endpoint del Servidor Api desde un Token JWT
Decodificando el token JWT obtenemos el id del cluster 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 al hacer algunas pruebas por mi cuenta, veo que se repiten estos:
gr7
yl4
De todos modos, al ser solo 3 caracteres, podemos probar a fuerza bruta. Utiliza el siguiente script para generar la lista:
Entonces con wfuzz
Recuerda reemplazar y <región>.
Saltar CloudTrail
Si un atacante obtiene credenciales de un AWS con permisos 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).
Entonces, cuando el atacante habla con el clúster EKS, cloudtrail no registrará nada relacionado con el usuario que fue robado y accedió a él.
Ten en cuenta que el clúster EKS podría tener habilitados los registros que registrarán este acceso (aunque, por defecto, están deshabilitados).
¿Rescate de EKS?
Por defecto, el usuario o rol que creó un clúster SIEMPRE tendrá privilegios de administrador sobre el clúster. Y esa es la única forma "segura" de acceso que AWS tendrá sobre el clúster de Kubernetes.
Entonces, si un atacante compromete un clúster usando fargate y elimina a todos los demás administradores y borra al usuario/rol de AWS que creó el clúster, el atacante podría haber rescatado el clústerr.
Ten en cuenta que si el clúster estaba usando VMs EC2, 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 usar nodos EC2 o mover todo a EC2 en el clúster y recuperarlo accediendo a los tokens en el nodo.
Last updated