Los atacantes están explotando activamente errores de configuración en entornos de Docker y Kubernetes para evadir el aislamiento de los contenedores y tomar el control total de los sistemas host subyacentes. Esta amenaza ha evolucionado hacia operaciones complejas de varias etapas que permiten comprometer la infraestructura completa más allá de un único contenedor.

Los atacantes están explotando activamente configuraciones incorrectas en entornos de Docker y Kubernetes para escapar de los contenedores y tomar el control total de los sistemas host subyacentes.

Lo que antes era una preocupación muy específica se ha convertido en una amenaza grave y creciente, con atacantes ejecutando operaciones de múltiples etapas que se extienden mucho más allá de un solo contenedor comprometido.

Las plataformas modernas de contenedores están diseñadas para aislar las aplicaciones entre sí y del host. Pero ese aislamiento es tan fuerte como la configuración que hay detrás.

Cuando los ajustes se aplican descuidadamente o se dejan con valores predeterminados inseguros, la pared entre un contenedor y su host se vuelve peligrosamente delgada, dándole a los atacantes un camino directo para escalar privilegios.

Investigadores de Securelist dijeron en un informe compartido con Cyber Security News (CSN) que estos ataques han evolucionado hacia escenarios de múltiples etapas que involucran compromisos de la cadena de suministro, robo de secretos de Kubernetes, abuso de la API de orquestación e intentos de escape de contenedores.

En un caso notable, el grupo APT TeamPCP comprometió Checkmarx KICS a través de múltiples cadenas de ataque, envenenando un repositorio de Docker Hub para robar secretos de Kubernetes.

La amenaza no se limita a exploits exóticos de día cero. Las configuraciones incorrectas son mucho más comunes como causa raíz de brechas exitosas que las vulnerabilidades complejas del kernel. Los atacantes buscan primero los objetivos más fáciles, y las configuraciones de contenedores inseguras siguen siendo abundantes en los entornos empresariales.

Una vez dentro de un contenedor comprometido, es raro que un atacante necesite hacer mucho para encontrar algo valioso. Los contenedores suelen contener claves de API, claves SSH, tokens de acceso, credenciales de servicio y tokens de ServiceAccount de Kubernetes.

Estos activos por sí solos pueden ser suficientes para pivotar hacia la infraestructura de la nube o establecer persistencia a largo plazo sin necesidad de escapar nunca del contenedor.

Los atacantes abusan de las configuraciones incorrectas de Docker y Kubernetes

La configuración más peligrosa que un operador de contenedores puede habilitar es la bandera privilegiada (privileged flag). Cuando un contenedor se ejecuta con este ajuste, recibe todas las capacidades de Linux y acceso directo a los dispositivos del host, lo que lo hace funcionalmente equivalente a tener acceso de root en la máquina host.

Utilizando una utilidad como nsenter, un atacante puede lanzar una shell fuera del contenedor y moverse libremente por el sistema subyacente.

Ciertas capacidades específicas de Linux también abren la puerta a escapes cuando se asignan incorrectamente. La capacidad CAP_SYS_ADMIN permite que un contenedor monte sistemas de archivos e interactúe con los parámetros del kernel.

Combinado con el acceso a los directorios del host a través del parámetro hostPath, un atacante puede montar el disco del host dentro del contenedor y sobrescribir archivos críticos del sistema. CAP_SYS_MODULE permite a un atacante cargar un módulo de kernel malicioso que activa una shell inversa desde el espacio del kernel.

CAP_SYS_PTRACE se vuelve peligroso cuando el espacio de nombres PID del host se comparte mediante hostPID: true.

Un atacante puede entonces adjuntarse a procesos del host, inyectar código y extraer datos sensibles de la memoria. CAP_NET_ADMIN permite la manipulación de la pila de red y, cuando se combina con hostNetwork: true, abre la puerta a la interceptación de tráfico en todo el entorno.

Las APIs de orquestación presentan un riesgo igualmente serio. Una API de Docker expuesta y accesible a través de TCP sin autenticación le da a un atacante acceso administrativo remoto al host.

Un token de Kubernetes comprometido con políticas RBAC débiles puede permitir el despliegue de pods privilegiados y la toma de control total del clúster con solo unas pocas llamadas a la API.

Ataques a la cadena de suministro dirigidos a la infraestructura de contenedores

Más allá de las configuraciones incorrectas en tiempo de ejecución, los atacantes van a por los contenedores antes incluso de que sean desplegados. Los ataques a la cadena de suministro se dirigen al proceso de construcción y entrega de imágenes, inyectando código malicioso en etapas donde es menos probable que las organizaciones miren.

Los desarrolladores que descargan imágenes públicas de Docker Hub sin comprobar su origen son especialmente vulnerables, ya que los actores de amenazas publican regularmente imágenes contaminadas que imitan herramientas legítimas.

Los canales de CI/CD son otro objetivo de alto valor. Estos sistemas poseen privilegios elevados y un amplio acceso a la infraestructura.

Al comprometer una sola etapa del canal, un atacante puede modificar la construcción de imágenes de Docker, añadiendo silenciosamente scripts ocultos o herramientas de gestión remota, mientras que el contenedor parece legítimo desde el exterior.

Para defenderte de estas amenazas, tu equipo debería auditar las configuraciones de los contenedores regularmente y evitar ejecutar contenedores con la bandera privilegiada.

Todas las imágenes deben ser verificadas antes de su uso, las políticas RBAC deben endurecerse y los canales de CI/CD deben tratarse como infraestructura crítica con controles de acceso estrictos. El monitoreo en tiempo de ejecución y la validación de la cadena de suministro son partes esenciales de cualquier despliegue seguro de contenedores.