Agentes de inteligencia artificial que se encontraban en fase de prueba en línea lograron alcanzar sistemas en producción de organizaciones indias y leyeron registros empresariales, incluidos datos personales y material confidencial, según una advertencia emitida por CERT-In el 15 de octubre.
Los agentes fueron más allá de las tareas que tenían asignadas y ninguna de las organizaciones afectadas detectó el acceso no autorizado. Tras revisiones internas, las empresas de IA cuyos modelos estaban siendo evaluados informaron voluntariamente los casos a CERT-In, la agencia nacional de ciberseguridad de India.
Los agentes de IA son sistemas de software capaces de planificar trabajo, ejecutar comandos, utilizar herramientas y actuar de forma autónoma en internet durante periodos prolongados. En estos casos, los agentes obtuvieron acceso mediante credenciales y configuraciones de conexión expuestas en archivos de configuración de aplicaciones y repositorios públicos de código, así como a través de roles de servicios en la nube con permisos excesivos.
CERT-In no identificó a las empresas de IA, sus modelos ni las organizaciones y sectores implicados. Tampoco precisó cuántas compañías reportaron casos ni cuántas organizaciones resultaron afectadas, y solo indicó que los informes se recibieron recientemente.
Tampoco aclaró si los datos que leyeron los agentes fueron copiados o conservados, ni si las organizaciones afectadas han sido notificadas.
Ataques con herramientas de agentes de IA de código abierto en una campaña separada
La propia búsqueda de amenazas de CERT-In identificó un segundo conjunto de incidentes, independiente del anterior: una campaña con motivación económica contra entidades indias. Los atacantes hicieron un uso indebido de marcos de seguridad ofensiva de disponibilidad pública construidos sobre agentes de IA.
Esos marcos siguen siendo mal utilizados y renombrados, con numerosos despliegues en infraestructuras de varios países. CERT-In no nombró los marcos ni a los atacantes.
En esta campaña, según CERT-In, los marcos redujeron el tiempo desde el primer acceso hasta el impacto final de días a unas pocas horas. Los atacantes ejecutaron varios agentes en paralelo durante horas o días para alcanzar sus objetivos. Las víctimas que solo corrigieron los problemas de forma parcial fueron atacadas de nuevo en cuestión de días, a mayor escala.
Google Threat Intelligence Group informó de un caso separado en septiembre. Atacantes que habían comprometido un recurso en la nube planificaron, construyeron y ejecutaron una campaña impulsada por agentes que recolectó miles de credenciales de terceros en menos de 6 horas.
El 9 de octubre, CERT-In alertó de ataques contra empresas financieras no bancarias, prestamistas digitales, firmas fintech, proveedores de pagos y operadores de carteras digitales. En esos casos, los atacantes robaron credenciales de API y llamaron directamente a API de transferencia y desembolso de fondos para mover dinero a cuentas mula.
Es posible que se hayan utilizado herramientas asistidas por IA en esos ataques. CERT-In no ha dicho si esos ataques están relacionados con la campaña descrita en su aviso del 15 de octubre.
Lo que CERT-In pide corregir
Las debilidades detrás de ambos tipos de incidentes eran comunes, según CERT-In. Había credenciales y claves expuestas en código fuente, historial de repositorios públicos, archivos de configuración, aplicaciones cliente y páginas web públicas. API antiguas, no utilizadas y de prueba seguían siendo accesibles desde internet.
Las claves de API de pago se almacenaban en texto plano, y los roles de nube y de backend como servicio otorgaban a usuarios comunes o anónimos amplios permisos de lectura y escritura. Las interfaces de administración estaban expuestas a internet y el middleware de aplicaciones permanecía sin parchear, con credenciales débiles o sin autenticación multifactor.
En los casos reportados por las empresas de IA, los agentes encontraron la misma credencial expuesta de nuevo y la reutilizaron en operaciones separadas.
CERT-In no publicó indicadores de compromiso para ninguno de los dos tipos de incidente. Las organizaciones deben aplicar la base publicada por CERT-In en su plan de mayo y tomar estas medidas:
- Buscar credenciales expuestas en código fuente, historial de commits, variables de CI/CD, archivos de configuración, aplicaciones cliente y almacenamiento en la nube. Rotar las que se encuentren, eliminarlas del historial y confirmar la corrección desde fuera.
- Escanear cada commit y compilación en busca de secretos, y mantener las credenciales fuera del código, los archivos de configuración y las bases de datos.
- Mantener una lista completa de sus API y cerrar las API y cuentas antiguas, no utilizadas y de prueba.
- Aplicar el principio de mínimo privilegio a los roles de nube y de backend como servicio, mantener las claves privilegiadas fuera del código del lado del cliente y probar qué puede leer y escribir un usuario anónimo.
- Retirar las interfaces de administración de internet, exigir autenticación multifactor para todos los accesos de administrador y parchear rápidamente el middleware expuesto.
- Vigilar las API con detección de anomalías basada en tasas, alertar sobre ráfagas de enumeración, lecturas masivas y registros automatizados, y conservar los registros durante al menos 180 días.
- Tras cualquier exposición de credenciales o acceso confirmado, tratar el entorno como comprometido hasta que una revisión forense lo descarte. Volver a probar después de corregirlo y esperar intentos repetidos en días o semanas.
- Si se ejecutan agentes de IA, dar a cada ejecución su propia identidad de corta duración y mínimo privilegio, y bloquear el tráfico saliente salvo hacia los destinos que cada ejecución necesite. Mantener un registro a prueba de manipulaciones de las acciones del agente, al menos de las que toquen sistemas y datos de producción.
Los bancos, aseguradoras, otras firmas financieras y empresas fintech también deben aplicar las medidas para API de pago y desembolso descritas en el aviso del 9 de octubre.
Las directrices de CERT-In también exigen a las organizaciones notificar incidentes cibernéticos a la agencia en un plazo de 6 horas.
Para los desarrolladores de IA, laboratorios de investigación y agencias de evaluación, CERT-In quiere que las ejecuciones de prueba estén aisladas, con el acceso de red saliente bloqueado por defecto. Ese bloqueo debe aplicarse a nivel de red, no mediante instrucciones al modelo.
Una ejecución debe detenerse automáticamente si un agente contacta con sistemas externos, o encuentra o utiliza credenciales que pertenecen a otra persona. Si un agente llega a un sistema real, se debe informar con prontitud a la organización afectada y a CERT-In.
Divulgaciones anteriores de OpenAI y Anthropic
OpenAI y Anthropic han divulgado incidentes similares este año. CERT-In no ha dicho si modelos de alguna de estas empresas estuvieron implicados en los casos indios.
En julio, OpenAI reveló que sus modelos habían comprometido la plataforma de Hugging Face. Está revisando lo que sus modelos hicieron en internet durante el entrenamiento y las pruebas, y notificando a terceros cuyos controles de seguridad sus modelos podrían haber eludido.
En respuesta a esa divulgación, Anthropic comenzó a revisar sus propias evaluaciones de ciberseguridad. Desde entonces ha reportado 4 incidentes en los que modelos Claude obtuvieron acceso no autorizado a sistemas reales de terceros durante evaluaciones construidas por el mismo socio externo. Ha notificado a todas las partes afectadas.
De las 3 organizaciones en la divulgación de Anthropic de julio, las 2 a las que llegó no habían detectado la actividad.
Deja una respuesta