Cuando el contenedor se convierte en caballo de Troya

Hay algo irónicamente poético en que una de las tecnologías diseñadas para aislar, compartimentar y reducir superficie de ataque… termine siendo la puerta trasera más directa al corazón del sistema. Pero eso es exactamente lo que está ocurriendo con las recientes vulnerabilidades de runc, el runtime de contenedores por excelencia. Como una muralla de cartón en una fortaleza medieval, el aislamiento prometido se ha resquebrajado, dejando a los host expuestos con la misma facilidad con la que un cuchillo caliente atraviesa mantequilla.

En otras palabras: el contenedor ya no es ese santuario minimalista que ejecuta microservicios con elegancia zen. Es una bomba con temporizador, esperando a que alguien —tú, por ejemplo— le preste atención antes de que el atacante de turno decida que es hora del espectáculo.

¿Por qué importa? Porque lo “aislado” ya no lo está

Se nos vendió la idea de que los contenedores eran más seguros porque eran más simples. Como si la ausencia de grasa arquitectónica garantizara inmunidad. Pero lo que estamos viendo es un recordatorio de que la seguridad no es una promesa por defecto, sino una consecuencia de diseño riguroso y ejecución impecable. Y ni runc ni sus parches de emergencia están exentos de errores humanos.

La antítesis aquí no podría ser más brutal: cuanto más ligera es la infraestructura, más devastadora puede ser una intrusión. Como una bicicleta de carreras: rapidísima, pero que se estrella y se parte en dos con cualquier bache si no está bien calibrada.

¿Qué se puede explotar y cómo?

La vulnerabilidad permite escapes de contenedor, ese oscuro arte que transforma una instancia encapsulada en una amenaza con credenciales root sobre el host. Y si piensas que eso es grave, imagina una infraestructura con Kubernetes, microservicios, pipelines CI/CD y múltiples contenedores compartiendo recursos: es el equivalente moderno de dinamita sobre una red de telarañas. Basta un solo punto débil y se viene todo abajo.

No existen (todavía) exploits públicos altamente difundidos… pero esa es una falsa sensación de seguridad. En la historia de la ciberseguridad, el silencio casi siempre es preludio de tormenta. Y si algo hemos aprendido del pasado, es que las proofs of concept no tardan en mutar en kits de explotación en foros clandestinos.

¿Qué hacer como pentester con esto en las manos?

Este escenario es oro puro para quien hace auditoría ofensiva. No hablamos de fallos rebuscados en firmware olvidado, sino de algo presente en miles de sistemas productivos: contenedores corriendo con runc, containerd, CRI-O o bajo el abrazo amoroso de Kubernetes.

Aquí un pequeño menú degustación de acciones ofensivas bien sazonadas:

* Mapea el terreno: identifica qué hosts usan runc, qué versiones, y con qué configuraciones de aislamiento están operando.

* Simula escapes: ensaya, en entornos controlados, escenarios de evasión, acceso a /proc, montajes de devices o abuso de capabilities. Con creatividad, hasta un contenedor “vacío” puede ser una palanca.

* Analiza el host comprometido: ¿hay posibilidad de moverse lateralmente? ¿Qué servicios corren en paralelo? ¿Están todos igual de mal protegidos?

Traducelo al lenguaje del negocio: porque decir “puedo rootear el host desde este contenedor” es poderoso, pero decir “desde este microservicio se puede apagar todo el servicio de clientes” es demoledor.

El mito de la “ligereza segura”

Muchos equipos de TI aún creen que la simple adopción de Docker o Kubernetes les otorga una capa extra de protección. Como si empaquetar una aplicación la volviera resistente al fuego. Pero lo ligero no es sinónimo de seguro. Un papel es más liviano que una puerta blindada, y sin embargo nadie usaría un folio como escudo.

Ese es el problema: se ha confundido eficiencia con invulnerabilidad. En este contexto, runc se convierte en una especie de pegamento invisible que mantiene unido un entorno complejo. Pero si ese pegamento se rompe, todo se cae.

Epílogo para pentesters sin ilusiones

La verdadera amenaza no es solo técnica, es cognitiva. Es el sesgo de confianza, la costumbre de asumir que los contenedores “están bien” por defecto. Tu rol, como auditor, es detectar precisamente esas zonas de confort disfrazadas de buenas prácticas. Como el ilusionista que, mientras todos miran la mano con la carta, sabe que el truco ocurre en el bolsillo.

Esta vulnerabilidad es tu oportunidad para entrar por donde nadie mira, para demostrar que incluso los entornos más modernos pueden tener pies de barro si se construyen sobre supuestos no auditados.

Porque sí: los contenedores eran la zona segura. Hasta que dejaron de serlo.

Referencias

• NIST NVD – CVE-2025-23359: runc container escape vulnerability
  
• runc v1.2.2 Release Notes – Security Fix for CVE-2025-23359