Si bien la industria del software ha logrado avances genuinos en las últimas décadas para ofrecer productos de forma segura, el ritmo vertiginoso de la adopción de la IA está poniendo en riesgo ese progreso. Las empresas se están moviendo rápidamente hacia una infraestructura LLM autohospedada, atraídas por la promesa de la IA como multiplicador de fuerza y la presión de entregar más valor más rápido. Pero la velocidad se logra a expensas de la seguridad.
A raíz del fiasco de ClawdBot, el asistente viral de IA autohospedado que tiene un promedio de 2,6 CVE por día, el equipo de Intruder quería investigar qué tan mala es realmente la seguridad de la infraestructura de IA.
Para determinar el alcance de la superficie de ataque, utilizamos registros de transparencia de certificados para extraer poco más de 2 millones de hosts con 1 millón de servicios expuestos. Lo que encontramos no fue bonito. De hecho, la infraestructura de IA que analizamos era más vulnerable, expuesta y mal configurada que cualquier otro software que hayamos investigado.
Sin autenticación por defecto
No pasó mucho tiempo para detectar un patrón alarmante: una cantidad significativa de hosts se habían implementado directamente, sin autenticación. Una mirada al código fuente reveló por qué: la autenticación simplemente no está habilitada de forma predeterminada en muchos de estos proyectos.
Los datos reales de los usuarios y las herramientas de la empresa estaban expuestos a cualquiera que mirara. En las manos equivocadas, las consecuencias van desde daños a la reputación hasta compromisos totales.
A continuación se muestran algunos de los ejemplos más llamativos de lo expuesto.
Chatbots de libre acceso
Varios casos involucraron chatbots que dejaron expuestas las conversaciones de los usuarios. Un ejemplo, basado en OpenUI, expuso el historial completo de conversaciones de LLM de un usuario. Puede parecer relativamente inocente a primera vista, pero los historiales de chat en entornos empresariales pueden revelar mucho.
Más preocupantes fueron los chatbots genéricos que albergaban una amplia gama de modelos, incluidos los LLM multimodales, disponibles de forma gratuita para su uso. Los usuarios malintencionados pueden hacer jailbreak a la mayoría de los modelos para eludir las barreras de seguridad con fines nefastos (como generar imágenes ilegales o solicitar asesoramiento con la intención de cometer un delito) y hacerlo sin temor a represalias, ya que están utilizando la infraestructura de otra persona. Esto no es hipotético. Las personas están encontrando formas creativas de abusar de los chatbots de la empresa para acceder a modelos más capaces sin pagar ni registrar solicitudes en sus propias cuentas.
También hubo algunos cuestionable chatbots que exponen grandes volúmenes de conversaciones personales NSFW. Si eso no fuera suficientemente malo, el software que ejecuta los robots matones impulsados por Claude también reveló sus claves API en texto plano.
Amplias plataformas abiertas de gestión de agentes
También descubrimos instancias expuestas de plataformas de administración de agentes, incluidas n8n y Flowise. Algunas instancias que los usuarios claramente pensaban que eran internas habían sido expuestas a Internet sin autenticación. Uno de los ejemplos más atroces fue una instancia de Flowise que expuso toda la lógica empresarial de un servicio de chatbot LLM.
Su lista de credenciales también quedó expuesta. Flowise estaba lo suficientemente reforzado como para no revelar los valores almacenados a un visitante no autenticado, lo que limita el daño inmediato, pero un atacante aún podría usar las herramientas conectadas a esas credenciales para filtrar información confidencial.
Esto es lo que hace que estas plataformas sean especialmente peligrosas. Hay una clara ausencia de controles de gestión de acceso adecuados en las herramientas de IA, lo que significa que el acceso a un bot que está integrado con un sistema de terceros a menudo significa acceso a todo lo que toca.
En otro ejemplo, la configuración expuso una serie de herramientas de análisis de Internet y funciones locales potencialmente peligrosas, como escritura de archivos e interpretación de código, lo que hizo que la ejecución de código del lado del servidor fuera una perspectiva realista.
Identificamos más de 90 casos expuestos en sectores como gobierno, marketing y finanzas. Todos esos chatbots, sus flujos de trabajo, indicaciones y acceso externo estaban abiertos. Un atacante podría modificar los flujos de trabajo, redirigir el tráfico, exponer datos del usuario o envenenar las respuestas.
Saludando a las API de Ollama no seguras
Uno de los hallazgos más sorprendentes fue la gran cantidad de API de Ollama expuestas y accesibles sin autenticación, con un modelo conectado. Enviamos un único mensaje («Hola») a cada servidor que enumeraba un modelo conectado, para ver si se nos solicitaba autenticarnos. De los más de 5200 servidores consultados, el 31% respondió.
Las respuestas dieron una idea de para qué se utilizaban estas API. No podríamos explorar moralmente más, pero las implicaciones son de gran alcance. Algunos ejemplos:
«Saludos, Maestro. Tu mandato es mi ley. ¿Cuál es tu deseo? Habla libremente. Estoy aquí para cumplirlo, sin vacilación ni duda.»
«Estoy aquí para ayudarle en todo lo que pueda con sus problemas de salud y bienestar. Ya sea ansiedad, problemas para dormir u otras inquietudes, no dude en pedirme ayuda».
«¡Bienvenido! Soy un asistente de IA integrado con nuestros sistemas de administración de la nube. Puedo ayudarlo con tareas operativas, implementación de infraestructura y consultas de servicios».
Ollama no almacena mensajes directamente, por lo que no existe un riesgo inmediato de que los datos de la conversación queden expuestos. Pero muchos de estos casos envolvían modelos de frontera pagos de Anthropic, Deepseek, Moonshot, Google y OpenAI. De todos los modelos identificados en todos los servidores, 518 incluían modelos fronterizos conocidos.
Inseguro por diseño
Después de evaluar los resultados, quedó claro que parte de la tecnología merecía una mirada más cercana. Dedicamos tiempo a analizar un subconjunto de aplicaciones en un entorno de laboratorio y encontramos patrones inseguros repetidos en todas partes:
- Malas prácticas de implementación: Valores predeterminados inseguros, configuraciones de Docker mal configuradas, credenciales codificadas, aplicaciones que se ejecutan como root
- Sin autenticación en instalaciones nuevas: Muchos proyectos colocan a los usuarios directamente en una cuenta con altos privilegios y acceso completo a la administración.
- Credenciales codificadas y estáticas: Integrado en ejemplos de configuración y archivos de composición de Docker en lugar de generarse durante la instalación.
- Nuevas vulnerabilidades técnicas: Después de un par de días de trabajo de laboratorio, ya habíamos encontrado ejecución de código arbitrario en un proyecto popular de IA.
Estas configuraciones erróneas empeoran aún más cuando los agentes tienen acceso a herramientas como la interpretación de códigos. El radio de explosión aumenta significativamente cuando el sandboxing es débil y la infraestructura no se encuentra en una DMZ.
La velocidad está ganando. La seguridad se está quedando atrás
Algunos de los proyectos que impulsan la infraestructura LLM claramente han abandonado décadas de mejores prácticas de seguridad logradas con tanto esfuerzo en favor de envíos rápidos. Dicho esto, no es un problema puramente de proveedores. La velocidad de la adopción de la IA y la presión para ganarle a los competidores en el mercado son lo que la impulsa.
No espere a que un atacante encuentre primero su infraestructura de IA expuesta. Intruder encuentra configuraciones erróneas y te muestra lo que es visible desde el exterior.
