La industria del software ha logrado avances reales en la entrega de productos de forma segura en las últimas décadas, pero el ritmo vertiginoso de la adopción de la IA está poniendo ese progreso en riesgo. La promesa de la IA como multiplicador de poder y la presión para ofrecer más valor y más rápido están impulsando a las empresas a migrar rápidamente a una infraestructura LLM autohospedada. Sin embargo, la velocidad viene a expensas de la seguridad.
A raíz de la debacle de ClawdBot, un asistente viral de IA autohospedado que genera un sorprendente 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 investigar 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 públicos. Lo que encontramos no fue muy 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 encontrar un patrón sorprendente. Una cantidad significativa de hosts se implementaron de fábrica sin autenticación configurada. Examinar el código fuente revela por qué. Muchos de estos proyectos simplemente no tienen la autenticación habilitada de forma predeterminada.
Los datos reales de los usuarios y las herramientas corporativas quedaron expuestos para que todos los vieran. En las manos equivocadas, los efectos pueden variar desde daños a la reputación hasta compromisos absolutos.
A continuación se muestran algunos de los ejemplos más llamativos de lo expuesto.
Chatbot de libre acceso
Muchos casos involucraron chatbots, lo que dejó expuestas las conversaciones de los usuarios. En un ejemplo, se expuso el historial completo de conversaciones de LLM de un usuario en función de OpenUI. Si bien puede parecer relativamente benigno en la superficie, el historial de chat en un entorno corporativo puede revelar mucho.
Otro motivo de preocupación fue un chatbot de uso general que alojaba y utilizaba libremente una amplia gama de modelos, incluidos los LLM multimodales. Los usuarios malintencionados pueden hacer jailbreak a la mayoría de los modelos y eludir las barreras de seguridad con fines maliciosos, como generar imágenes ilegales o solicitar asesoramiento con intenciones delictivas. Y como estás utilizando la infraestructura de otra persona, puedes ejecutarla sin temor a repercusiones. Esta no es una hipótesis. Las personas están encontrando formas creativas de explotar los chatbots de la empresa para acceder a modelos más capaces sin pagar una tarifa ni registrar la solicitud en su cuenta.
También hubo algunos chatbots cuestionables que publicaron grandes cantidades de conversaciones privadas NSFW. Como si eso no fuera suficientemente malo, el software que ejecuta Goonbot con tecnología de Claude expuso su clave API en texto claro.
Plataforma de gestión de agentes amplia y abierta
También descubrimos instancias disponibles públicamente de plataformas de gestión de agentes como n8n y Flowise. Algunas instancias que los usuarios pensaban que eran claramente internas quedaron expuestas a Internet sin autenticación. Uno de los ejemplos más atroces fue la instancia de Flowise que expuso toda la lógica empresarial del servicio de chatbot LLM.
Su lista de credenciales también quedó expuesta. Flowise está lo suficientemente reforzado como para no exponer los valores almacenados a visitantes no autenticados, lo que limita el daño inmediato, pero los atacantes podrían usar herramientas conectadas a estas credenciales para filtrar información confidencial.
Esto es lo que hace que estas plataformas sean especialmente peligrosas. Las herramientas de IA claramente carecen de controles adecuados de gestión de acceso. Esto significa que el acceso a un bot que se integra con sistemas de terceros a menudo significa acceso a todo lo que toca.
En otro ejemplo, esta configuración expuso una serie de herramientas de análisis de Internet y capacidades locales potencialmente peligrosas, como la escritura de archivos y la interpretación de códigos, haciendo realidad la ejecución de código del lado del servidor.
Identificamos más de 90 casos expuestos en sectores como gobierno, marketing y finanzas. Estos chatbots, sus flujos de trabajo, indicaciones y acceso externo estaban todos abiertos. Un atacante podría modificar el flujo de trabajo, redirigir el tráfico, exponer datos del usuario o envenenar la respuesta.
Saludos a la insegura API de Ollama
Uno de los descubrimientos más sorprendentes fue la gran cantidad de API de Ollama expuestas a las que se puede acceder sin autenticación una vez que el modelo está conectado. Envié un mensaje («Hola») a todos los servidores que enumeraban sus modelos conectados y verifiqué si se les pedía que se autenticaran. Consultamos a más de 5200 servidores y el 31% respondió.
Las respuestas nos permiten saber para qué se utilizan estas API. Era moralmente imposible investigar más a fondo, pero las implicaciones son de gran alcance. Algunos ejemplos:
«Hola Maestro. Tus órdenes son mi ley. ¿Qué quieres? Habla libremente. Estoy aquí para hacerlo realidad, sin dudas ni preguntas».
«Estoy aquí para ayudarlo en todo lo que pueda con sus problemas de salud y bienestar. Ya sea ansiedad, problemas para dormir o cualquier otra inquietud, no dude en comunicarse conmigo para obtener ayuda».
«¡Bienvenido! Soy un asistente de IA integrado en su sistema de gestión de la nube. Lo ayudaré con tareas operativas, implementaciones 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 se vean comprometidos. Sin embargo, muchos de estos casos incluían modelos de frontera pagos de Anthropic, Deepseek, Moonshot, Google y OpenAI. De todos los modelos identificados en todos los servidores, 518 incluyeron modelos Frontier conocidos.
inseguro por diseño
Después de evaluar los resultados, quedó claro que algunas técnicas requerían más investigación. Dedicamos tiempo a analizar un subconjunto de aplicaciones en un entorno de laboratorio. Como resultado, encontramos que los siguientes patrones inseguros se repetían en todo momento:
Malas prácticas de implementación: valores predeterminados inseguros, configuraciones de Docker mal configuradas, credenciales codificadas, aplicaciones que se ejecutan como raíz Sin autenticación en instalaciones nuevas: muchos proyectos colocan a los usuarios directamente en cuentas altamente privilegiadas con acceso administrativo completo Credenciales estáticas codificadas: integradas en configuraciones de ejemplo y archivos de composición de Docker en lugar de generarse durante la instalación Nuevas vulnerabilidades técnicas: ya se ha descubierto que un proyecto popular de IA ejecuta código arbitrario a los pocos días de trabajar en el laboratorio.
Estas configuraciones erróneas son aún peores cuando los agentes tienen acceso a herramientas como la interpretación de códigos. Si la zona de pruebas es débil y la infraestructura no está dentro de la DMZ, el radio de explosión será significativamente mayor.
La velocidad es el nombre del juego. la seguridad está detrás
Algunos proyectos para fortalecer la infraestructura LLM claramente han abandonado décadas de mejores prácticas de seguridad logradas con tanto esfuerzo en favor de un envío rápido. Sin embargo, esto no es puramente una cuestión de proveedores. La velocidad de la adopción de la IA y la presión para superar a los competidores en el mercado están impulsando la adopción de la IA.
No espere a que un atacante descubra primero su infraestructura de IA expuesta. Intruder encuentra configuraciones erróneas y muestra lo que es visible desde el exterior.
Source link
