Brecha en Chainstack: una Grafana abierta fue la puerta

La brecha en Chainstack empezó por una Grafana de pruebas con la clave de administrador por defecto, abierta a internet desde julio. Sin forzar una sola falla de software, entró el 26 de octubre, alcanzó parte de la producción el 29 y llegó a una base de datos de clientes antes del corte del 31.

Chainstack opera nodos de cadenas de bloques para desarrolladores y empresas. Publicó su informe el 3 de noviembre y lo amplió el 10 con la ruta técnica. The Block informó hoy que trata las credenciales de nodo como expuestas y pide rotarlas.

El botín confirmado es concreto: nombres de organizaciones, titulares, correos de miembros y resúmenes de contraseñas, los llamados hashes. También tuvo acceso a los sistemas con las credenciales de nodo; no hay evidencia de lectura, pero Chainstack las da por expuestas. Los datos de pago quedaron fuera: no guarda números completos de tarjeta.

Una Grafana de pruebas y un servidor de IA sin llave

Grafana es una herramienta abierta de paneles de monitoreo. La copia instalada en un clúster de desarrollo con Kubernetes, el sistema que administra contenedores, quedó visible desde internet sin una capa previa de autenticación, y con la clave de fábrica. El 26 de octubre a las 19:26 UTC el atacante entró con esa clave.

Adentro usó el proxy de fuentes de datos de la propia Grafana como pasillo. Ese proxy reenvía peticiones a la dirección que pida un administrador, sin lista de destinos permitidos, y en dos horas tocó decenas de servicios internos: identidad, bases de datos, automatización y monitoreo.

Uno pesó más que el resto. A las 21:01 apareció un servidor de herramientas MCP, el Protocolo de Contexto de Modelo que permite a los agentes de inteligencia artificial ejecutar operaciones, sin autenticación y con permisos de administrador del clúster. Chainstack sostiene que ese servidor actuó como ejecutor de órdenes del intruso.

Con ese control creó usuarios administradores en el proveedor de identidad de desarrollo y reemplazó el código JavaScript de una aplicación web montando archivos propios sobre los originales.

El pase a producción ocurrió el 29. Entre las 17:03 y las 17:12 reescribió un flujo de automatización en su base de datos, lo disparó con un token válido y restauró el flujo para borrar el rastro. La maniobra le entregó una identidad de máquina de la puerta de acceso, y a las 17:49 esa identidad ya listaba secretos de producción.

La madrugada del 31 concentró el daño mayor. Entre la 01:40 y las 08:31 leyó en masa el gestor de secretos de producción, creó llaves y cuentas con token propio para volver a entrar, y corrió contenedores cortos con nombres que empezaban por artx.

Una llave privada de un par VPN de la red de bases de datos, guardada entre esos secretos, le abrió otra puerta. Desde las 03:39 se conectó con esa identidad, y como dos clientes presentaron el mismo par, el túnel osciló y una tubería de replicación falló. Esa falla, accidente del propio ataque, encendió la investigación.

Con la red abierta, consultó bases de producción y sacó resultados en fragmentos codificados en base64. En una instancia revisó la vista pg_shadow de PostgreSQL, donde viven los resúmenes de contraseña de los roles. La última credencial copiada se usó el 2 de noviembre a las 06:28, ya con las rutas cortadas.

ARTEX puso velocidad donde había descuidos viejos

La brecha en Chainstack lleva una firma conocida: el intruso usó ARTEX, un marco abierto que orquesta agentes de modelos grandes de lenguaje para automatizar intrusiones, y la empresa lo atribuye con confianza alta. La pista es una firma repetida: nombres artx y artex en cuentas y contenedores. La empresa atribuye la herramienta, no a la persona detrás, porque CrowdStrike y el grupo de inteligencia de amenazas de Google ligan ese marco a operadores distintos.

El patrón ya se había visto en los paneles ARTEX expuestos que dejaron 1.465 consolas sin contraseña y en la campaña contra entidades financieras de Corea del Sur que CrowdStrike contó el 7 de octubre. Un marco con agentes recorre en horas una cadena que a un operador humano le tomaría días, con reintentos sin pausa.

La lista de causas que Chainstack reconoce no trae ningún exploit nuevo: credenciales por defecto, funciones administrativas expuestas, autenticación ausente, permisos demasiado amplios y credenciales de larga duración que servían en desarrollo y en producción. Cada eslabón era conocido y barato de corregir.

Para los clientes, la instrucción tiene cuatro piezas: cambiar la contraseña, también donde se haya reutilizado; rotar las credenciales de nodo desde la consola, con los extremos actuales activos hasta completar el cambio; regenerar las claves de la interfaz de programación si se usan; y desconfiar de mensajes que pidan contraseñas o llaves, porque Chainstack afirma que jamás los solicita. Las sesiones de los clientes quedaron invalidadas.

La reparación apunta a que desarrollo no tenga camino a producción: identidades y secretos separados por ambiente, ninguna herramienta administrativa en internet sin capa extra de autenticación, listas de destinos para proxies como el de Grafana y servidores MCP con autenticación y sin permisos de administrador.

Chainstack verificó con registros de auditoría que los nodos de clientes, la consola y la interfaz pública no fueron modificados. El dato que todavía no suelta es el tamaño en cuentas: cuántas organizaciones aparecen en esa base sigue sin cifra pública.

Fuente: Chainstack