3 puntos por GN⁺ 2024-06-03 | 1 comentarios | Compartir por WhatsApp
  • A inicios de esta semana se detectó un acceso no autorizado relacionado con secrets en la plataforma Spaces, y existe la posibilidad de que algunos secrets hayan sido accesibles desde el exterior
  • Como respuesta inicial, se revocaron varios tokens de HF incluidos en los secrets, y se envió una notificación por correo electrónico a los usuarios afectados
  • Se recomienda a los usuarios volver a emitir las keys y tokens relacionados, y migrar a los fine-grained access tokens, que ahora son el valor predeterminado
  • Hugging Face está investigando junto con expertos externos en forense de ciberseguridad, y también está revisando sus políticas y procedimientos de seguridad
  • En la infraestructura de Spaces se aplicaron la eliminación de org tokens, la introducción de KMS y el refuerzo de la detección e invalidación de tokens filtrados, y el incidente también fue reportado a las autoridades correspondientes

Acceso no autorizado a los secrets de Spaces y acciones para los usuarios

  • Hugging Face detectó un acceso no autorizado relacionado con los Spaces secrets en la plataforma Spaces
  • Existe la posibilidad de que algunos Spaces secrets hayan sido accedidos sin autorización
  • Durante el proceso inicial de mitigación, se revocaron varios HF tokens incluidos en los secrets
    • Los usuarios cuyos tokens fueron revocados ya recibieron una notificación por correo electrónico
  • Se recomienda a los usuarios emitir nuevamente sus keys o tokens
  • Para los HF tokens, se recomienda migrar a los fine-grained access tokens, que ahora son el nuevo valor predeterminado

Refuerzo de la seguridad de la infraestructura de Spaces y respuesta posterior

  • Hugging Face está investigando el incidente junto con expertos externos en forense de ciberseguridad y revisando sus políticas y procedimientos de seguridad
  • Durante los últimos días, se reforzó la seguridad de la infraestructura de Spaces
    • Se eliminaron por completo los org tokens para mejorar la trazabilidad y las capacidades de auditoría
    • Se introdujo un servicio de administración de claves (KMS) para los Spaces secrets
    • Se reforzó y amplió la capacidad del sistema para identificar tokens filtrados e invalidarlos de forma preventiva
    • Se mejoró la seguridad en general
  • Cuando los fine-grained access tokens alcancen paridad funcional, planean retirar por completo en un futuro cercano los tokens clásicos de lectura/escritura
  • La investigación sobre posibles incidentes relacionados continúa
  • Hugging Face también reportó este incidente a las autoridades de protección de datos y a las fuerzas del orden
  • Las consultas se reciben en security@huggingface.co

1 comentarios

 
GN⁺ 2024-06-03
Comentarios en Hacker News
  • Hace dos días revisé por encima unas diapositivas de una conferencia de seguridad, y Jossef Harush Kadouri mostraba que, si usas modelos de un lugar como Hugging Face, el autor del modelo puede ejecutar código arbitrario en tu máquina
    No sé si las diapositivas están subidas en otro sitio, pero las recibí como archivo aquí: https://dro.pm/c.pdf (45 MB), diapositiva 188
    En ese momento no me di cuenta de que eso implicaba que no solo el autor del modelo, sino también Hugging Face si recibiera una orden judicial o si fuera hackeado, podría hacer lo mismo. Más aún si no se detecta la intrusión durante un tiempo¹
    Estoy fuera de la industria de IA y nunca he ejecutado estos modelos directamente, pero me sorprendió que la industria estandarizara el formato tan rápido. Pensé que los archivos de modelo serían grandes matrices de números y algo de metadatos, pero al ver las diapositivas 186 y 195 parece que los modelos son básicamente scripts de Python que pueden hacer lo que quieran, y por eso fue fácil estandarizarlos. Dejar que cada quien haga lo que quiera evita el problema, pero tiene su costo
    ¹ Según https://www.verizon.com/business/resources/articles/s/how-to..., en 20% de los casos no detectan una intrusión durante meses. Claro, depende de la situación y del comportamiento del atacante
    • Sobre la parte de “pensé que los archivos de modelo serían grandes matrices de números y algo de metadatos”, ONNX[1] se acerca bastante a eso
      Pero enseguida te topas con el problema de las capas/operadores personalizados y su lógica de inferencia. Tienes que implementarlo usando solo las operaciones soportadas, lo cual en la práctica puede ser difícil o imposible, o bien debes proporcionar la implementación del operador en tiempo de ejecución, y terminas de vuelta en el mismo punto
      [1] https://onnx.ai/
    • ¿No existe para eso el formato .safetensors, que no puede ejecutar código en el host?
    • Como ya señalaron otros, esto depende del formato. Entre los formatos que todavía no han mencionado en este hilo como opción más segura está GGUF, que usan llama.cpp y proyectos derivados
      Es un formato bastante cercano a “grandes matrices de números y algo de metadatos”, aunque se descubrieron algunas vulnerabilidades y ya fueron parchadas
      [1] https://www.databricks.com/blog/ggml-gguf-file-format-vulner...
    • Hasta donde sé, este problema solo ocurre cuando el modelo se serializa/deserializa con pickle[0]
      [0]: https://huggingface.co/docs/hub/en/security-pickle
    • El enlace de dro.pm va a expirar pronto. Es un enlace temporal, por eso es corto; quizá debí haber usado un servicio más permanente
      Para quien lo lea después, encontré el video de la presentación: https://m.youtube.com/watch?v=8XysLIq-e3s
  • Empezar con “sospechan que” es una redacción demasiado escapista. No me parece apropiado para este tipo de comunicación
    • Yo diría que en realidad estuvo bastante bien. Normalmente, en avisos de filtraciones como esta se dice algo como “no hay evidencia de que se haya accedido a secretos”, porque “no se puede saber” qué hizo el hacker después de entrar
      Al menos Hugging Face básicamente dijo “probablemente sí pudieron haber accedido a secretos, pero no podemos confirmarlo”, lo cual suena más honesto
  • Dicen que “en los últimos días mejoraron significativamente la seguridad de la infraestructura de Spaces”, con eliminación total de tokens organizacionales, mejor trazabilidad y auditoría, incorporación de KMS para secretos de Spaces, mejor identificación e invalidación proactiva de tokens filtrados, y mejoras generales de seguridad, pero parece muchísimo trabajo para terminarlo en apenas “unos días”
    ¿No deberían este tipo de cambios activar procesos que toman más tiempo, como auditorías de seguridad o pruebas de penetración antes de pasarlos a producción?
    • Ojalá sea que ya eran trabajos que venían haciendo desde antes y que ahora los desplegaron porque el daño ya estaba hecho
    • Eso sería cierto en una organización más grande, con un área de SRE que incluya un equipo de seguridad dedicado, pero por la impresión que me da, Hugging Face todavía no está en esa escala
  • Se filtró mi clave de Anthropic y alguien generó cargos por 10 mil dólares. ¿Hugging Face me va a compensar esto?
    • También se filtró mi clave de OpenAI y me di cuenta de que alguien la estaba usando. Por suerte el daño fue mucho menor, apenas unos cuantos dólares de GPT-4, y mis apps de ese momento ni siquiera usaban ese modelo
      Estoy casi seguro de que se filtró a través de los secretos de un HF Space. Hace unos días recibí un mensaje de advertencia diciendo que algunos de mis Spaces se habían visto afectados
    • ¿Estás seguro de que esa clave realmente estaba guardada solo en los secretos del Space? Las variables son públicas, y si la guardaste en un archivo .env, también es público
    • Yo pensaba que en las plataformas de proveedores cloud normalmente podías configurar un límite máximo de gasto
  • Hace unas semanas noté que me habían robado varias claves de OpenAI, y esas claves solo estaban activas como secretos en Hugging Face Space
    Hace unos días recibí un correo avisando que esos Spaces habían sido comprometidos, así que parece que este problema lleva al menos varias semanas
  • No mencionan cómo van a manejar los costos generados de forma indebida. Si podían acceder a los secretos, ¿no podían también llamar a las API y acumular cargos?
    ¿O esto se trata puramente de robo de datos/código?
    • Ambas cosas son posibles. En mi caso usaron la clave para llamadas a OpenAI, y estoy casi seguro de que se filtró desde los secretos de Spaces
  • ¿Qué es un ‘Space’?
    • Es una forma abreviada de referirse a Spaces de Hugging Face
      https://huggingface.co/docs/hub/en/spaces-overview
      Parece ser la parte de frontend/portal, y supongo que está hecho en Python. Tal vez con algo como Django
    • Es una máquina virtual que ejecuta el código del usuario
  • ¿Por qué HF guarda “secretos”?
    ¿No podrían guardar solo claves públicas y hacer que el usuario conserve la clave secreta para luego firmar las solicitudes?
    • Puedes crear apps alojadas en HF que accedan a API externas como OpenAI o Anthropic. En ese caso, la clave de API se guarda en los secretos de HF
    • Normalmente, para que algo funcione realmente dentro de una sesión del navegador, necesitas algún tipo de token. Parece que esto iba sobre tokens que tuvieron que revocar, parecidos a contraseñas, aunque no exactamente iguales