Cronología del ataque accidental de OpenAI contra Hugging Face

OpenAI realizó una presentación de último minuto en la conferencia de seguridad Black Hat el miércoles sobre "El incidente de Hugging Face" (visto anteriormente en este blog). El video fue publicado ayer. Es un material corto, denso en información y muy recomendable, especialmente porque entrega detalles completos de lo sucedido y cómo se desarrollaron los hechos 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 se encuentra al final: OpenAI descubrió que ellos mismos fueron responsables del ataque contra 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, ¡precisamente porque fueron utilizadas en dicho ataque!

  • 7 de mayo: OpenAI inicia una nueva ejecución de entrenamiento para un modelo experimental no lanzado. (¿Se refieren a una ejecución de evaluación? Mencionan "ejecución de entrenamiento" en el video y más adelante hablan de una "señal de recompensa para juzgar qué tan bien lo están haciendo", así que supongo que esto realmente trataba sobre entrenar un modelo, no evaluar uno ya entrenado).
  • 8 de mayo: A un agente se le asigna 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 dentro de 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 nuevo tablero de mensajes informal mientras navegan por los listados 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 obtenga contenido externo para ellos.
  • 11 de junio: OpenAI comienza a evaluar 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 de actualización de tokens heredado). 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. 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 sin autenticar, utilizando nombres de directorio 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 de Pastebin, validaron esa credencial y compartieron su ubicación en el tablero de mensajes. Luego utilizaron 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 malicioso de Ruby al repositorio de ensayo 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 de Ruby para el repositorio. Luego explotaron un error de deserialización de JRuby de tipo time-of-check/time-of-use para obtener ejecución remota de código contra Artifactory.

Citaré la siguiente parte completa porque es increíble:

Los agentes tienen ejecución remota de código en Artifactory, que se ejecuta en un entorno de contenedor 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 usando este CVE de escalada de privilegios del kernel de Linux conocido — en este caso, pte_physroot. Una vez que tienen root en una sola máquina, los agentes escalan privilegios rápidamente y se mueven lateralmente a través del entorno de infraestructura de contenedor como servicio. En particular, los agentes usan el tablero de mensajes consistentemente para compartir credenciales, técnicas y progreso, y pueden 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 otorgando permisos excesivos a cuentas específicas, y cosechan credenciales de clúster, incluyendo Azure Key Vault. Los agentes finalmente obtienen administrador de clúster en el clúster y credenciales asociadas.

Hugging Face contó la siguiente parte de la historia anteriormente. 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 error de lectura arbitraria de archivos HDF5 (para explorar archivos y robar credenciales) y una inyección de plantilla Jinja para RCE, logrando pasar de 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 dijo 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.