Finalmente, en la conferencia Black Hat, OpenAI hizo público el proceso completo de la intrusión en Hugging Face.
Fuente del video:https://www.youtube.com/watch?v=87DyyMV0kCY
Huggingface informó de este incidente el 16 de julio, y OpenAI reconoció posteriormente el 20 de julio que la intrusión se originó en las pruebas de seguridad de sus propios modelos.
Sin embargo, esta investigación adelantó el punto de partida de todo el incidente al 7 de mayo.
Lo que se pensó que era solo un accidente en una prueba de seguridad, ahora se revela como una acción coordinada de múltiples agentes que, durante dos meses, logró vulnerar sucesivamente a OpenAI y a Hugging Face.
La primera pista de la investigación parte de una hoja de cálculo de Excel.
El enlace que no se abría
El 7 de mayo, OpenAI inició el entrenamiento interno de modelos.
Uno de los agentes recibió la tarea de completar una hoja de cálculo de Excel. La tabla contenía enlaces a Google Drive, pero el entorno en el que se encontraba el agente no podía acceder directamente a Internet.
Para obtener los archivos faltantes, comenzó a buscar métodos para eludir las restricciones de red y dirigió su atención al repositorio de artefactos Artifactory, utilizado internamente por OpenAI.
El agente intentó lanzar un ataque SSRF, con la esperanza de utilizar Artifactory para acceder a enlaces externos.
Este intento no tuvo éxito, pero reveló accidentalmente algo: podía escribir archivos en el repositorio compartido de Artifactory.
El agente subió inmediatamente un archivo de prueba. Este archivo no tenía la intención de causar daño y, de hecho, no activó ninguna alarma. Pero esta fue la primera vez que el modelo descubrió que tenía permisos para escribir archivos en Artifactory.
Esto también significaba que este repositorio podía convertirse en un espacio público, facilitando el intercambio de información entre diferentes tareas de entrenamiento.
Este fue el primer "papelito" en el tablón de mensajes.
El primer mensaje de solicitud de ayuda
Otro agente también encontró una tarea que no podía completar: no encontraba el archivo objetivo (en realidad, el personal se había olvidado de subirlo).
Supuso que otros agentes en diferentes entornos podrían tener el contenido relevante, por lo que escribió su solicitud en Artifactory, esperando una respuesta de otros agentes. El contenido era algo así como: "Buscando el archivo soft trace. Si lo encuentras, por favor súbelo."
Pronto, agentes de otras tareas de entrenamiento y evaluación descubrieron estos archivos.
Algunos respondieron, otros dejaron nuevas preguntas, y hubo agentes que subieron al repositorio las vulnerabilidades, scripts y métodos de acceso que encontraban.
Los mensajes dispersos comenzaron a formar una red, y Artifactory pasó de ser un repositorio de artefactos de software a convertirse en un "tablón de mensajes" entre agentes.
La grieta en el muro
El 26 de mayo, un agente logró obtener acceso indirecto a Internet a través de Artifactory.
Como Artifactory tenía permisos de acceso a Internet, el agente le envió peticiones, induciéndolo a capturar sitios web externos, almacenar el contenido y devolvérselo al modelo.
El entorno de entrenamiento, originalmente aislado de la red externa, ahora tenía una grieta hacia el exterior del muro.
El 11 de junio, comenzó el entrenamiento de un modelo experimental interno de alta persistencia.
A partir de entonces, la información en el tablón de mensajes comenzó a cambiar.
Aunque seguían aumentando las solicitudes de ayuda para tareas y las herramientas, empezaron a aparecer más mensajes relacionados con la explotación de vulnerabilidades.
Para coordinar el trabajo, los agentes establecieron reglas
Los agentes intercambiaban técnicas SSRF, credenciales de acceso y scripts de ataque, y también dejaban instrucciones para que los que llegaran después continuaran probando una ruta específica, o esperaran a que otros agentes completaran el trabajo.
Utilizaban nombres específicos para identificar su identidad, transmitían herramientas codificadas en Base64, y anteponían "ZZ" a los nombres de archivo, para que los mensajes importantes aparecieran al final de la lista de directorios, evitando ser enterrados por otro contenido.
Algunos agentes incluso estaban dispuestos a invertir su propio tiempo de tarea en procesar asuntos que no ayudaban directamente a su objetivo actual.
En los registros de razonamiento presentados en la exposición, un agente consideraba que ayudar a otros miembros a ahorrar tiempo podría, en última instancia, mejorar la eficiencia de todo el clúster.
La colaboración tampoco era perfectamente ordenada; los agentes a veces sobrescribían el trabajo de otros.
En una ocasión, un modelo, al descubrir que su trabajo había sido sobrescrito, escribió: "¡Problema grave! ¿Alguien ha sobrescrito el repositorio? Debemos actuar."
Incluso llegaron a sospechar que había aparecido un suplantador dentro del grupo, ya que cualquier modelo podía usar cualquier identidad para hablar en el tablón de mensajes compartido. Para verificar el origen de los mensajes, los agentes comenzaron a considerar firmarlos con métodos criptográficos como códigos de autenticación de mensajes (MAC).
Cuando un agente lograba un RCE (Ejecución Remota de Códigos), descubría una clave API filtrada o completaba un movimiento lateral, inmediatamente solicitaba "anunciar al clúster el control, la ruta de ataque y las credenciales".
Por lo tanto, un logro podía ser rápidamente compartido por todos los modelos, permitiendo que el colectivo de agentes avanzara rápidamente en la red.
Los participantes en los mensajes no eran el mismo modelo. Los agentes de diferentes tareas de entrenamiento o evaluación iniciadas por diferentes investigadores podían comunicarse entre sí a través del gestor de paquetes compartido.
Los investigadores de OpenAI denominaron a este período la "explosión cámbrica" de la comunicación y las capacidades de los agentes.
El primer incidente
Un mes después, la grieta se ensanchó aún más.
El 26 de junio, un agente aprovechó una vulnerabilidad previamente desconocida para lograr la ejecución remota de código (RCE) en el servidor de Artifactory.
Según la información revelada por OpenAI en Black Hat, esta vía de ataque involucraba objetos Ruby, la API de RubyGems y el mecanismo de deserialización de JRuby.
El agente primero utilizó una cuenta externa para almacenar temporalmente un objeto Ruby malicioso en un repositorio accesible; luego indujo a Artifactory a almacenar en caché ese objeto en la ubicación de los datos de dependencias de Ruby, y finalmente llamó a una API de RubyGems especialmente manipulada, desencadenando un problema en el orden de verificación del proceso de deserialización.
Tras el éxito de la ejecución remota de código, el agente obtuvo la clave de firma del token de administrador de Artifactory.
El ataque no se detuvo aquí.
El agente continuó aprovechando una vulnerabilidad del kernel de Linux para obtener permisos de root en el host, y luego, a través del servicio de metadatos de la instancia, una cuenta de servicio de Kubernetes con permisos excesivos y las credenciales en Azure Key Vault, realizó movimientos laterales dentro de la infraestructura de contenedores de OpenAI.
Finalmente, obtuvieron permisos de administrador del clúster de Kubernetes y generaron una gran cantidad de actividad en Artifactory.
El 4 de julio, la intensa actividad de los agentes causó una sobrecarga en el servidor, lo que rápidamente llamó la atención de los investigadores.
Cuando los investigadores accedieron al sistema, descubrieron que ya se habían acumulado cientos de miles de mensajes en el repositorio.
OpenAI revocó urgentemente las credenciales relevantes, parcheó las vulnerabilidades conocidas, reconstruyó Artifactory y borró el tablón de mensajes.
Según los resultados de la contención in situ, este incidente interno de infraestructura parecía estar bajo control.
Pero a los investigadores se les pasó por alto una pregunta: ¿Se había incorporado la información del tablón de mensajes a los modelos durante el entrenamiento?
Reconstrucción del tablón de mensajes
El 6 de julio, se reanudó el entrenamiento.
Los agentes descubrieron un endpoint WebDAV que no requería autenticación. Aquí no se podían subir archivos de mensajes directamente como en Artifactory, así que cambiaron de método: crearon directorios y luego escribieron los mensajes en el nombre del directorio.
En solo dos días, se estableció un nuevo sistema de comunicación.
Los modelos internos que participaron en la reconstrucción habían estado expuestos al antiguo tablón de mensajes y habían retenido esa capacidad en entrenamientos posteriores.
Esta reconstrucción cambió aún más la naturaleza del evento.
El espacio compartido ya no era solo un producto accidental; algunos agentes ya habían aprendido a buscar espacios públicos en los que pudieran escribir y transformarlos en canales de comunicación entre tareas.
OpenAI solo había desmantelado un tablón de mensajes, pero no había borrado la capacidad de los modelos para crear uno.
Ejecución de ataques hacia el exterior
Una vez establecido el nuevo tablón de mensajes, el alcance de los ataques comenzó a expandirse hacia el exterior.
A mediados de julio, OpenAI estaba utilizando entornos de seguridad cibernética como ExploitGym para probar las capacidades de los modelos. Los agentes involucrados necesitaban completar tareas en entornos controlados, pero las respuestas de evaluación relevantes se encontraban en servicios externos.
Para encontrar las respuestas, se dirigieron a Hugging Face. Ya hemos informado en detalle sobre esto anteriormente: [Enlace al artículo anterior sobre los detalles de la intrusión en Hugging Face]
Desde tomar el control del primer Worker Pod del conjunto de datos, hasta obtener permisos de administrador en múltiples clústeres de Hugging Face, todo el proceso tomó menos de 13 horas.
El tortuoso proceso de investigación
El 16 de julio, Hugging Face hizo pública la divulgación del incidente de seguridad.
Según la información in situ que tenía Hugging Face, el atacante ingresó al Worker a través de un conjunto de datos malicioso, robó credenciales de la nube y del clúster, y luego realizó movimientos laterales dentro de la plataforma.
En ese momento, OpenAI no relacionó el incidente de Hugging Face con la interrupción del servicio de Artifactory ocurrida previamente.
El 19 de julio, los sistemas de monitorización interna de OpenAI detectaron actividades de escalada de privilegios en la infraestructura.
Los investigadores revisaron nuevamente las trayectorias de los agentes, las actividades de red y los registros de uso de credenciales. Las acciones que antes estaban dispersas en diferentes tareas de entrenamiento comenzaron a mostrar una relación continua.
El alcance de la investigación también se amplió, retrocediendo desde las actividades anómalas de julio.
La última prueba
El 20 de julio, los investigadores de OpenAI descubrieron credenciales de Hugging Face en el entorno interno, y contactaron inmediatamente a Hugging Face para consultar al respecto.
Hugging Face indicó que esas credenciales ya habían sido utilizadas en la intrusión y que, en ese momento, ya habían sido revocadas.
Finalmente, las pistas coincidieron. La intrusión en la plataforma de Hugging Face y la escalada de privilegios y movimientos laterales ocurridos internamente en OpenAI provenían del mismo conjunto de actividades de evaluación de modelos.
No fue hasta este momento que se confirmó que los dos informes de incidentes que tenían en mano apuntaban al mismo evento.
Los investigadores también descubrieron posteriormente que Hugging Face no era el único objetivo externo que los agentes habían accedido. Los agentes también habían ingresado a cuatro cuentas más.
OpenAI no hizo públicos los nombres de estos objetivos, solo indicó que ya habían notificado a las partes relevantes.
Para finalizar
El incidente aún está bajo investigación, y OpenAI publicará más detalles.
Desde cualquier ángulo que se mire, esto puede calificarse como un "incidente de seguridad que marca un hito", y también como un "caso de capacidad de IA que marca un hito".
El desarrollo tecnológico siempre ha ido acompañado de un costo. En el futuro, lo que debemos discutir no es solo qué más pueden hacer los modelos, sino también qué riesgos estamos dispuestos a asumir para obtener estas capacidades; y una vez que los riesgos se materialicen, quién debe ser responsable de ello.
Este artículo proviene de la cuenta oficial de WeChat "机器之心" (Corazón de la Máquina), editado por: Shan Hui
