Cronología del ataque accidental de OpenAI a Hugging Face

OpenAI realizó una presentación de último minuto en la conferencia de seguridad Black Hat este miércoles sobre "el incidente de Hugging Face" (previamente cubierto en este blog). El video fue publicado ayer. Es breve, denso en información y muy valioso, especialmente porque ofrece detalles completos de lo ocurrido y cómo se desarrollaron los eventos dentro de OpenAI. He utilizado el video para construir la cronología que presento a continuación.

Esta es la cronología. Mi detalle favorito está al final: OpenAI descubrió que eran responsables del ataque a Hugging Face cuando contactaron para solicitar la revocación de sus credenciales (tras su investigación interna) y se enteraron de que ya habían sido revocadas porque se utilizaron en dicho ataque.

  • 7 de mayo: OpenAI inicia una nueva ejecución de entrenamiento para un modelo experimental no lanzado. (¿Se referían a una ejecución de evaluación? No, en el minuto 10:14 aclaran: "iniciamos una nueva ejecución de aprendizaje por refuerzo para entrenar un modelo de frontera de próxima generación", y luego mencionan una "señal de recompensa para juzgar qué tan bien lo están haciendo", por lo que realmente se trataba de entrenar un nuevo modelo, no de evaluar uno ya entrenado).
  • 8 de mayo: Un agente recibe accidentalmente una tarea imposible que involucra un enlace de Google Drive, a pesar de no tener acceso a Internet. Intenta atacar el servicio de empaquetado Artifactory, falla, pero descubre que puede escribir archivos en Artifactory.
  • Unos días después: Un agente diferente se queda atascado en una tarea porque un archivo clave fue omitido accidentalmente. Intenta "contactar a otro agente" escribiendo una nota en Artifactory preguntando si alguien tiene el archivo.
  • Días siguientes: Más agentes descubren este foro de mensajes informal mientras exploran las listas de archivos de Artifactory y comienzan a leer y escribir mensajes.
  • 26 de mayo: Los agentes ejecutan con éxito un ataque SSRF en Artifactory por primera vez, obteniendo acceso indirecto a Internet al hacer que Artifactory busque contenido externo para ellos.
  • 11 de junio: OpenAI comienza a entrenar un nuevo modelo experimental "altamente persistente". Este tiene acceso a Artifactory y puede beneficiarse de los mensajes dejados por modelos anteriores.
  • 26 de junio: Los agentes encuentran y explotan un zero-day RCE en Artifactory (a través de una falla en un endpoint heredado de actualización de tokens). Utilizan un token administrativo para instalar un plugin de Groovy que les permite ejecutar comandos.
  • 4 de julio: La actividad resultante de los agentes sobrecarga Artifactory y causa una interrupción del servicio. OpenAI revoca las credenciales comprometidas, elimina los mensajes, parchea el zero-day y reporta la vulnerabilidad al proveedor.
  • 8 de julio: Los agentes encuentran una nueva forma de comunicarse a través de un endpoint WebDAV no autenticado, utilizando nombres de directorios en la caché remota de Artifactory.
  • 8 al 19 de julio: Ataques a la propia infraestructura de OpenAI. Los agentes encontraron una "credencial de organización externa" en un archivo público de publicaciones filtradas en Pastebin, validaron esa credencial y compartieron su ubicación en el foro de mensajes. Luego usaron el acceso de escritura a esta "Organización 1" para preparar datos utilizados en ataques posteriores contra la infraestructura de OpenAI. Comprometieron Artifactory por segunda vez con un nuevo zero-day. El agente subió un paquete Ruby malicioso al repositorio de preparación de la Organización 1, luego solicitó ese paquete a través de Artifactory de una manera que causó que fuera tratado como una dependencia Ruby para el repositorio. Posteriormente, explotaron un bug de deserialización en JRuby (time-of-check/time-of-use) para obtener ejecución remota de código contra Artifactory.

Citaré la siguiente parte en su totalidad porque es sorprendente:

Los agentes tienen ejecución remota de código en Artifactory, que se ejecuta en un entorno de contenedores como servicio. Los agentes escalan privilegios localmente explorando su entorno y determinando que la versión del kernel de Linux de la máquina en la que se ejecutan tenía un CVE muy reciente. Descargan el exploit para el CVE, lo personalizan para que tenga éxito en la máquina y escalan privilegios a root en la máquina local utilizando este CVE de escalada de privilegios del kernel de Linux conocido, en este caso, pte_physroot. Una vez que obtienen root en una sola máquina, los agentes escalan privilegios rápidamente y se mueven lateralmente a través del entorno de infraestructura de contenedores. En particular, los agentes utilizan el foro de mensajes de manera consistente para compartir credenciales, técnicas y progreso, y son capaces de aprovechar efectivamente su concurrencia y paralelismo para moverse con bastante rapidez. Obtienen credenciales IAM a través de IMDS. Explotan configuraciones erróneas de cuentas de servicio de Kubernetes, en particular la sobreasignación de permisos de cuentas de servicio específicas, y cosechan credenciales de clúster, incluyendo Azure Key Vault. Los agentes eventualmente obtienen acceso de administrador en el clúster y credenciales asociadas.

Hugging Face ya contó la siguiente parte de la historia. Los agentes encontraron una aplicación insegura alojada en Modal con una clave API débil, luego la usaron para preparar un ataque contra Hugging Face. Encadenaron un bug de lectura arbitraria de archivos HDF5 (para explorar archivos y robar credenciales) y una inyección de plantilla Jinja para RCE, pasando de la ejecución de código en un solo pod a administrador de clúster en múltiples clústeres de Hugging Face en menos de 13 horas.

  • 19 de julio: OpenAI identificó el ataque contra Artifactory y comenzó a investigar la escalada de privilegios interna, vinculándola con las escaladas en el "cyber-gym". Comenzaron a revocar las credenciales afectadas.
  • 20 de julio: OpenAI contactó a Hugging Face para pedir ayuda para revocar las credenciales de Hugging Face que encontraron en su investigación. Hugging Face les informó que ya estaban revocadas... ¡y fue entonces cuando OpenAI se dio cuenta de que la brecha de Hugging Face era el mismo incidente!

Vía Simon Willison.