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)
Si has comprometido el acceso a una máquina, el usuario puede tener acceso a alguna plataforma de Kubernetes. El token generalmente se encuentra en un archivo señalado por la var env KUBECONFIG o dentro de ~/.kube.
En esta carpeta puedes encontrar archivos de configuración con tokens y configuraciones para conectarte al servidor API. En esta carpeta también puedes encontrar una carpeta de caché con información recuperada previamente.
Si has comprometido un pod dentro de un entorno de kubernetes, hay otros lugares donde puedes encontrar tokens e información sobre el entorno K8 actual:
Antes de continuar, si no sabes qué es un servicio en Kubernetes, te sugeriría que sigas este enlace y leas al menos la información sobre la arquitectura de Kubernetes.
Tomado de la documentación de Kubernetes:
“Cuando creas un pod, si no especificas una cuenta de servicio, se le asigna automáticamente la cuenta de servicio predeterminada en el mismo espacio de nombres.”
ServiceAccount es un objeto gestionado por Kubernetes y utilizado para proporcionar una identidad a los procesos que se ejecutan en un pod. Cada cuenta de servicio tiene un secreto relacionado y este secreto contiene un token portador. Este es un JSON Web Token (JWT), un método para representar reclamaciones de manera segura entre dos partes.
Generalmente uno de los directorios:
/run/secrets/kubernetes.io/serviceaccount
/var/run/secrets/kubernetes.io/serviceaccount
/secrets/kubernetes.io/serviceaccount
contiene los archivos:
ca.crt: Es el certificado ca para verificar las comunicaciones de kubernetes
namespace: Indica el espacio de nombres actual
token: Contiene el token de servicio del pod actual.
Ahora que tienes el token, puedes encontrar el servidor API dentro de la variable de entorno KUBECONFIG. Para más información ejecuta (env | set) | grep -i "kuber|kube"
El token de la cuenta de servicio está siendo firmado por la clave que reside en el archivo sa.key y validado por sa.pub.
Ubicación predeterminada en Kubernetes:
/etc/kubernetes/pki
Ubicación predeterminada en Minikube:
/var/lib/localkube/certs
Los pods calientes son pods que contienen un token de cuenta de servicio privilegiada. Un token de cuenta de servicio privilegiada es un token que tiene permiso para realizar tareas privilegiadas como listar secretos, crear pods, etc.
Si no sabes qué es RBAC, lee esta sección.
k9s: Una GUI que enumera un clúster de kubernetes desde la terminal. Revisa los comandos en https://k9scli.io/topics/commands/. Escribe :namespace y selecciona todo para luego buscar recursos en todos los espacios de nombres.
k8slens: Ofrece algunos días de prueba gratuita: https://k8slens.dev/
Para enumerar un entorno K8s necesitas un par de cosas:
Un token de autenticación válido. En la sección anterior vimos dónde buscar un token de usuario y un token de cuenta de servicio.
La dirección (https://host:port) del API de Kubernetes. Esto generalmente se puede encontrar en las variables de entorno y/o en el archivo de configuración kube.
Opcional: El ca.crt para verificar el servidor API. Esto se puede encontrar en los mismos lugares donde se puede encontrar el token. Esto es útil para verificar el certificado del servidor API, pero usando --insecure-skip-tls-verify con kubectl o -k con curl no necesitarás esto.
Con esos detalles puedes enumerar kubernetes. Si el API por alguna razón es accesible a través de Internet, puedes simplemente descargar esa información y enumerar la plataforma desde tu host.
Sin embargo, generalmente el servidor API está dentro de una red interna, por lo tanto necesitarás crear un túnel a través de la máquina comprometida para acceder a él desde tu máquina, o puedes subir el kubectl binario, o usar curl/wget/cualquier cosa para realizar solicitudes HTTP en bruto al servidor API.
list y getCon permisos de get puedes acceder a la información de activos específicos (opción describe en kubectl) API:
Si tienes el permiso list, se te permite ejecutar solicitudes API para listar un tipo de activo (opción get en kubectl):
Si tienes el permiso watch, se te permite ejecutar solicitudes API para monitorear activos:
Abren una conexión de streaming que te devuelve el manifiesto completo de un Deployment cada vez que cambia (o cuando se crea uno nuevo).
Los siguientes comandos de kubectl indican solo cómo listar los objetos. Si deseas acceder a los datos, necesitas usar describe en lugar de get
Desde dentro de un pod, puedes usar varias variables de entorno:
Por defecto, el pod puede acceder al servidor kube-api en el nombre de dominio kubernetes.default.svc y puedes ver la red kube en /etc/resolv.config ya que aquí encontrarás la dirección del servidor DNS de kubernetes (el ".1" del mismo rango es el punto final kube-api).
Teniendo el token y la dirección del servidor API, usas kubectl o curl para acceder a él como se indica aquí:
Por defecto, el APISERVER se comunica con el esquema https://
si no hay
https://en la URL, puede que obtengas un error como Bad Request.
Puedes encontrar un cheatsheet oficial de kubectl aquí. El objetivo de las siguientes secciones es presentar de manera ordenada diferentes opciones para enumerar y entender el nuevo K8s al que has obtenido acceso.
Para encontrar la solicitud HTTP que kubectl envía, puedes usar el parámetro -v=8
Si lograste robar las credenciales de algunos usuarios, puedes configurarlas localmente usando algo como:
Con esta información sabrás todos los servicios que puedes listar
Otra forma de verificar tus privilegios es utilizando la herramienta: https://github.com/corneliusweig/rakkess****
Puedes aprender más sobre Kubernetes RBAC en:
Kubernetes Role-Based Access Control(RBAC)Una vez que sepas qué privilegios tienes, revisa la siguiente página para averiguar si puedes abusar de ellos para escalar privilegios:
Abusing Roles/ClusterRoles in KubernetesKubernetes soporta múltiples clústeres virtuales respaldados por el mismo clúster físico. Estos clústeres virtuales se llaman namespaces.
Si puedes leer secretos, puedes usar las siguientes líneas para obtener los privilegios relacionados con cada token:
Como se discutió al principio de esta página cuando se ejecuta un pod, generalmente se le asigna una cuenta de servicio. Por lo tanto, listar las cuentas de servicio, sus permisos y dónde se están ejecutando puede permitir a un usuario escalar privilegios.
Los despliegues especifican los componentes que necesitan ser ejecutados.
Los Pods son los contenedores que se ejecutarán.
Kubernetes services se utilizan para exponer un servicio en un puerto e IP específicos (que actuará como balanceador de carga para los pods que realmente están ofreciendo el servicio). Esto es interesante para saber dónde puedes encontrar otros servicios para intentar atacar.
Obtén todos los nodos configurados dentro del clúster.
DaeamonSets permite asegurar que un pod específico esté en ejecución en todos los nodos del clúster (o en los seleccionados). Si eliminas el DaemonSet, los pods gestionados por él también serán eliminados.
Los cron jobs permiten programar utilizando una sintaxis similar a crontab el lanzamiento de un pod que realizará alguna acción.
configMap siempre contiene mucha información y archivos de configuración que proporcionan a las aplicaciones que se ejecutan en Kubernetes. Por lo general, puedes encontrar muchas contraseñas, secretos y tokens que se utilizan para conectarse y validar otros servicios internos/externos.
Si puedes crear nuevos pods, es posible que puedas escapar de ellos hacia el nodo. Para hacerlo, necesitas crear un nuevo pod utilizando un archivo yaml, cambiar al pod creado y luego chroot en el sistema del nodo. Puedes usar pods ya existentes como referencia para el archivo yaml, ya que muestran imágenes y rutas existentes.
si necesitas crear un pod en un nodo específico, puedes usar el siguiente comando para obtener las etiquetas en el nodo
k get nodes --show-labelsComúnmente, kubernetes.io/hostname y node-role.kubernetes.io/master son buenas etiquetas para seleccionar.
Luego creas tu archivo attack.yaml
Después de eso, creas el pod
Ahora puedes cambiar al pod creado de la siguiente manera
Y finalmente haces chroot en el sistema del nodo.
Información obtenida de: Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1 Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1
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)
