Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
En Kubernetes, se observa que un comportamiento predeterminado permite el establecimiento de conexiones entre todos los contenedores que residen en el mismo nodo. Esto se aplica independientemente de las distinciones de espacio de nombres. Tal conectividad se extiende hasta Capa 2 (Ethernet). En consecuencia, esta configuración expone potencialmente al sistema a vulnerabilidades. Específicamente, abre la posibilidad de que un contenedor malicioso ejecute un ataque de suplantación ARP contra otros contenedores situados en el mismo nodo. Durante tal ataque, el contenedor malicioso puede interceptar o modificar engañosamente el tráfico de red destinado a otros contenedores.
Los ataques de suplantación ARP implican que el atacante envía mensajes ARP falsificados (Protocolo de Resolución de Direcciones) a través de una red de área local. Esto resulta en la vinculación de la dirección MAC del atacante con la dirección IP de una computadora o servidor legítimo en la red. Después de la ejecución exitosa de tal ataque, el atacante puede interceptar, modificar o incluso detener datos en tránsito. El ataque se ejecuta en la Capa 2 del modelo OSI, razón por la cual la conectividad predeterminada en Kubernetes en esta capa plantea preocupaciones de seguridad.
En el escenario se van a crear 4 máquinas:
ubuntu-pe: Máquina privilegiada para escapar al nodo y verificar métricas (no necesaria para el ataque)
ubuntu-attack: Contenedor malicioso en el espacio de nombres predeterminado
ubuntu-victim: Máquina víctima en el espacio de nombres kube-system
mysql: Máquina víctima en el espacio de nombres predeterminado
Si deseas más detalles sobre los temas de redes introducidos aquí, consulta las referencias.
Hablando en términos generales, la red de pod a pod dentro del nodo está disponible a través de un puente que conecta todos los pods. Este puente se llama “cbr0”. (Algunos complementos de red instalarán su propio puente.) El cbr0 también puede manejar ARP (Protocolo de Resolución de Direcciones). Cuando un paquete entrante llega a cbr0, puede resolver la dirección MAC de destino utilizando ARP.
Este hecho implica que, por defecto, cada pod que se ejecuta en el mismo nodo podrá comunicarse con cualquier otro pod en el mismo nodo (independientemente del espacio de nombres) a nivel de ethernet (capa 2).
Por lo tanto, es posible realizar ataques de ARP Spoofing entre pods en el mismo nodo.
En entornos de kubernetes, generalmente encontrarás 1 (o más) servicios DNS en ejecución usualmente en el espacio de nombres kube-system:
En la información anterior puedes ver algo interesante, la IP del servicio es 10.96.0.10 pero la IP del pod que ejecuta el servicio es 172.17.0.2.
Si verificas la dirección DNS dentro de cualquier pod, encontrarás algo como esto:
Sin embargo, el pod no sabe cómo llegar a esa dirección porque el rango de pods en este caso es 172.17.0.10/26.
Por lo tanto, el pod enviará las solicitudes DNS a la dirección 10.96.0.10 que será traducida por el cbr0 a 172.17.0.2.
Esto significa que una solicitud DNS de un pod siempre va a ir al puente para traducir la IP del servicio a la IP del endpoint, incluso si el servidor DNS está en la misma subred que el pod.
Sabiendo esto, y sabiendo que los ataques ARP son posibles, un pod en un nodo podrá interceptar el tráfico entre cada pod en la subred y el puente y modificar las respuestas DNS del servidor DNS (DNS Spoofing).
Además, si el servidor DNS está en el mismo nodo que el atacante, el atacante puede interceptar todas las solicitudes DNS de cualquier pod en el clúster (entre el servidor DNS y el puente) y modificar las respuestas.
Nuestro objetivo es robar al menos la comunicación del ubuntu-victim al mysql.
Como ya se mencionó, si comprometes un pod en el mismo nodo del pod del servidor DNS, puedes MitM con ARPSpoofing el puente y el pod DNS y modificar todas las respuestas DNS.
Tienes una muy buena herramienta y tutorial para probar esto en https://github.com/danielsagi/kube-dnsspoof/
En nuestro escenario, descarga la herramienta en el pod atacante y crea un **archivo llamado hosts ** con los dominios que deseas spoof como:
Realiza el ataque a la máquina ubuntu-victim:
Si intentas crear tu propio script de suplantación de DNS, si solo modificas la respuesta de DNS eso no va a funcionar, porque la respuesta va a tener una IP de origen la dirección IP del pod malicioso y no será aceptada. Necesitas generar un nuevo paquete DNS con la IP de origen del DNS donde la víctima envía la solicitud DNS (que es algo como 172.16.0.2, no 10.96.0.10, esa es la IP del servicio DNS de K8s y no la IP del servidor DNS, más sobre esto en la introducción).
La herramienta Mizu es un simple pero poderoso visor de tráfico API para Kubernetes que te permite ver toda la comunicación API entre microservicios para ayudarte a depurar y solucionar regresiones. Instalará agentes en los pods seleccionados y recopilará su información de tráfico y te la mostrará en un servidor web. Sin embargo, necesitarás altos permisos de K8s para esto (y no es muy sigiloso).
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)
