En 10 minutos y con permisos de administrador: hackers usaron IA para atacar la nube de Amazon (¿qué tiene que ver el idioma serbio?)

En 10 minutos y con permisos de administrador: hackers usaron IA para atacar la nube de Amazon (¿qué tiene que ver el idioma serbio?)

Amazon se pronuncia tras el hackeo del entorno en la nube de un cliente.

image

Un atacante vulneró el entorno en la nube de Amazon Web Services y en solo diez minutos obtuvo privilegios de administrador. Según los investigadores, la inteligencia artificial aceleró el ataque y se utilizó en casi todas las fases de la intrusión.

El equipo de investigación de amenazas de la empresa Sysdig registró el incidente el 28 de noviembre. Los especialistas llamaron la atención no solo por la rapidez, sino también por las señales de automatización. Según su evaluación, el atacante empleó modelos de lenguaje a gran escala para reconocimiento, escalado de privilegios, movimiento lateral dentro de la infraestructura y generación de código malicioso. También se observó un intento de secuestro de modelos de lenguaje, cuando una cuenta comprometida se usa para acceder a modelos y recursos de cómputo en la nube.

Los investigadores informaron que el atacante obtuvo privilegios administrativos en menos de 10 minutos, comprometió 19 identificadores en la nube y utilizó servicios de modelos generativos y aceleradores gráficos. El código malicioso contenía comentarios en serbio, identificadores de cuentas ficticios y enlaces a repositorios de código inexistentes. Esto indica que el código probablemente fue creado con ayuda de inteligencia artificial.

El punto de entrada inicial fueron credenciales de prueba encontradas en depósitos públicos Amazon S3. Esos datos pertenecían a un usuario del sistema de gestión de acceso con permisos de lectura y escritura para funciones en la nube y acceso limitado al servicio de modelos de lenguaje. En el mismo depósito había datos para el ajuste fino de modelos, que luego se utilizaron en el ataque. Los especialistas recuerdan que las claves de acceso no deben guardarse en depósitos públicos; las credenciales temporales son más seguras que las permanentes. Si se usan claves permanentes, deben rotarse con regularidad.

Al principio el atacante intentó obtener permisos elevados usando nombres de cuentas de administrador típicos, pero sin éxito. Luego realizó una inyección de código en una función en la nube y aprovechó permisos para actualizar el código y la configuración. El código de la función se reescribió varias veces en intentos de alcanzar al usuario objetivo. Al final se comprometió la cuenta de administrador.

El script malicioso enumeraba usuarios y claves de acceso, creaba nuevas claves y exploraba depósitos y su contenido. Tenía un manejo de errores elaborado y se aumentó el tiempo de ejecución de la función, lo que también sugiere el uso de un modelo generativo. Desde el robo de credenciales hasta la ejecución de la función transcurrió muy poco tiempo.

A continuación el atacante recopiló identificadores de cuentas e intentó obtener acceso a roles en todos los entornos detectados. Entre ellos había identificadores claramente inventados con números de plantilla. Los investigadores consideran esto un rasgo característico de las "alucinaciones" de la inteligencia artificial, cuando el modelo añade datos verosímiles pero incorrectos.

Con acceso ampliado, el delincuente descargó secretos del gestor de secretos, parámetros de sistemas de gestión, registros de eventos, código fuente de funciones y datos de depósitos. Después pasó a usar modelos de lenguaje en la nube a través del servicio Bedrock y llamó a distintos modelos que el propietario de la cuenta no solía usar. Los expertos califican esas llamadas como una señal de alarma y recomiendan limitar la lista de modelos permitidos a nivel de la política de la organización.

Luego el atacante trabajó con máquinas virtuales para tareas de aprendizaje automático, usó el almacenamiento en la nube para alojar scripts e intentó poner en marcha un entorno de entrenamiento de modelos. Uno de los scripts referenciaba un repositorio de código inexistente, lo que vuelve a indicar generación por modelo. El script también levantó un servidor público de entorno de cálculo en el puerto 8888, que podría servir como una puerta oculta sin credenciales en la nube. No obstante, la instancia creada fue detenida al cabo de cinco minutos.

En Sysdig señalan que cada vez más ataques se realizan con ayuda de inteligencia artificial, y la automatización completa de intrusiones es cuestión de tiempo. Las principales medidas de protección están relacionadas con el control estricto de cuentas y permisos de acceso. Se recomienda aplicar el principio de los mínimos privilegios, limitar la posibilidad de modificar el código de funciones en la nube y el traspaso de roles, cerrar el acceso público a depósitos con datos sensibles e habilitar el registro de accesos a los modelos.

En Amazon afirmaron que la propia infraestructura de los servicios no fue vulnerable y funcionó con normalidad. El incidente está relacionado con un depósito público del cliente mal configurado. La compañía aconseja no abrir acceso público a los depósitos, aplicar los mínimos privilegios, proteger las credenciales y utilizar servicios de monitorización para reducir el riesgo de acciones no autorizadas.