Se detecta malware con temática Shai-Hulud en la biblioteca de entrenamiento de IA PyTorch Lightning

• Las versiones 2.6.2 y 2.6.3 del framework de deep learning lightning fueron usadas en un ataque a la cadena de suministro; con solo ejecutar pip install lightning, se ejecutaba automáticamente una carga útil de JavaScript ofuscada desde el directorio oculto _runtime
• Como es un framework ampliamente usado para construir clasificadores de imágenes, hacer fine-tuning de LLM, modelos de difusión y pronóstico de series temporales, es muy probable que ya esté incluido en el árbol de dependencias de muchos equipos de IA/ML
• Cuando el malware se ejecuta, escanea más de 80 rutas en el sistema de archivos local para robar tokens de GitHub (ghp_, gho_), tokens de npm (npm_), variables de entorno y secretos de la nube, procesando hasta 5 MB por archivo
• Enumera y extrae secretos de los tres principales proveedores de nube, incluyendo AWS (archivos de credenciales, IMDSv2, ECS, Secrets Manager, SSM), Azure (Key Vault) y GCP (Secret Manager)
• En entornos de GitHub Actions, usa el Python integrado para volcar la memoria del proceso Runner.Worker y extraer todos los secretos marcados como "isSecret":true, junto con información del repositorio y del workflow
• El punto de entrada es PyPI (Python), pero la propagación tipo gusano se expande a través de npm (JavaScript): con los tokens de npm robados, inyecta un dropper (setup.mjs) y el malware (router_runtime.js) en todos los paquetes que puede publicar, sube la versión patch y los vuelve a publicar, encadenando la infección hasta las máquinas de desarrolladores que instalen esos paquetes
• La exfiltración de datos usa 4 canales paralelos al mismo tiempo para evitar que se bloquee con una sola ruta: ① envío al servidor C2 por HTTPS POST, ② dead drop usando la API de búsqueda de commits de GitHub (insertando el token con doble codificación Base64 en el mensaje del commit), ③ commit como results-<timestamp>.json en un repositorio público de GitHub con nombres del universo de Dune, ④ push directo al repositorio de la víctima
• Después de infiltrarse en un repositorio, siembra hooks de persistencia en herramientas de desarrollo para garantizar la reinfección: escribe un hook SessionStart en .claude/settings.json de Claude Code para ejecutarse automáticamente al iniciar la sesión, y coloca una tarea con runOn: folderOpen en .vscode/tasks.json de VS Code para ejecutarse cada vez que se abra la carpeta
  • Ambos hooks llaman al dropper autocontenido setup.mjs; si el runtime de Bun no está presente, lo descarga silenciosamente desde GitHub y ejecuta la carga útil router_runtime.js de 14.8 MB
• Si obtiene un token de GitHub con permisos de escritura, hace push de un workflow camuflado llamado Formatter al repositorio de la víctima: en cada push, vuelca los secretos del repositorio con ${{ toJSON(secrets) }} y los sube como artifact de Actions
• Todas las máquinas que hayan instalado esas versiones durante el período afectado deben considerarse completamente comprometidas; se deben rotar de inmediato los tokens de GitHub, credenciales de nube y API keys, y auditar los directorios .claude/ y .vscode/ en busca de archivos inesperados
• Indicadores de ataque: el prefijo EveryBoiWeBuildIsAWormyBoi en mensajes de commit, la descripción del repositorio "A Mini Shai-Hulud has Appeared" y la presencia del directorio _runtime/ en el repositorio, todo ello verificable directamente con búsquedas en GitHub

[picopress]

Ahora ya no habrá que actualizar...

[GN⁺]

Comentarios de Hacker News

• Puede que sea simplemente una ilusión de frecuencia, pero últimamente se ven bastantes ataques a la cadena de suministro muy sonados en paquetes importantes
  Incluso en las primeras páginas de HN ahora mismo hay varias publicaciones sobre casos distintos
  Al mirar atrás a left-pad hace 10 años, da la impresión de que hoy hay más ataques exitosos que antes, y probablemente sí sea así
  También debe haber aumentado claramente el valor de que un ataque tenga éxito, pero me pregunto si, como comunidad en general, realmente estamos mejorando en la capacidad de detectarlos antes del lanzamiento de paquetes
  Las empresas de software comercial deberían hacerlo mejor, pero todavía parece faltar una herramienta universal y sencilla para los casos en que algo empieza como código amateur o de hobby y termina siendo una dependencia de muchísimos proyectos
  Ya puse el mismo comentario en el hilo sobre el ataque a la cadena de suministro de SAP: https://news.ycombinator.com/item?id=47964003

  • Es un fenómeno real. A inicios de abril hubo 7 casos en los últimos 12 meses, y en los 20 años anteriores hubo 9: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
  • Como la gente mete código por todos lados en masa sin revisarlo bien, es natural que aumenten los ataques a la cadena de suministro
  • La razón es que las actualizaciones automáticas y las herramientas de CI ya alcanzaron masa crítica y todo el mundo las usa
    Antes era más común ejecutar npm install manualmente, y seguramente solo se hacía cuando se rompía el build o muy de vez en cuando
    Los ataques a la cadena de suministro dependen de que la gente, o más exactamente los pipelines, actualicen paquetes automáticamente en cuanto sale una nueva versión sin pensarlo mucho
  • Históricamente, el manejo de artefactos con verificaciones de seguridad adicionales era una opción enterprise de pago, y el lado menos seguro era por mucho la opción predeterminada menos engorrosa
    No sé si eso sea un buen modelo de negocio; probablemente no
  • left-pad no fue un ataque, fue un bug de NPM
    No debería haber sido posible borrar una versión de un paquete del que ya dependían otros paquetes públicos, y en cambio sí debería haber sido posible borrar una versión nueva específica de un paquete de la que nadie dependía
    Cuando el autor de left-pad intentó borrar todos sus datos con la intención de abandonar el servicio, NPM debió haber devuelto un código de error
    Según Wikipedia, cuando Koçulu se decepcionó de la decisión de npm, Inc. y dijo que no quería seguir siendo parte de la plataforma, Schlueter, creador de NPM, le proporcionó el comando para borrar los 273 módulos que había registrado

• Lo raro es que se abrieron 4 issues de seguridad y en todos el bot pl-ghost comentó automáticamente y los cerró [1][2][3][4]
  Al final, solo [4] se atendió correctamente y todos los comentarios del bot fueron eliminados
  En otro reporte [5] se puede ver el comentario del bot, y da más información que la publicación original
  [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [5] https://socket.dev/blog/lightning-pypi-package-compromised

  • Soy Andy de Lightning. Sí, las credenciales de PyPI fueron robadas a través de la cuenta comprometida del bot pl-ghost
    El atacante creó un nuevo workflow de Actions con esa cuenta y, desde ese workflow ejecutado, extrajo y se llevó los secretos de PyPI
    Después de publicar el paquete, usó esa misma cuenta para comentar y burlarse un poco de nosotros

• Ojalá llegue pronto el día en que no haya dependencias en absoluto
  Como ejemplo extremo, ahora cuando hago apps educativas interactivas para mi hija le pido a Opus que use solo JavaScript y HTML puros
  Desde péndulos dobles hasta simulaciones de fluidos, todo funciona de una sola vez, y antes eso implicaba cientos de dependencias
  Si el código tiene licencia MIT, puedo pedirle a Opus que extraiga exactamente las partes necesarias, las adapte a mi caso de uso y las incluya
  En proyectos de hobby me ha funcionado bien hasta ahora, y ojalá en el futuro también el software de producción pueda quedarse sin dependencias

  • Si haces eso, tendrás que gestionar tú mismo todos los cambios y una enorme cantidad de casos especiales
    Si Chrome cambia la forma de alguna API, tú mismo tendrás que encontrarlo y corregirlo; y si Marruecos cambia la fecha de inicio del horario de verano, también tendrás que actualizar por tu cuenta el código de fechas y horas
    Esas son cosas que las librerías nos resolvían y que dábamos por sentadas
    No es gran cosa para un simulador de péndulo doble del que tu hija perderá interés la próxima semana, pero sí es un problema para una empresa que construye algo que debe seguir funcionando indefinidamente
  • Ahora en realidad quedaste expuesto a la dependencia de verdad: el navegador
  • Claro, ¿vas a revisar con el mismo nivel de cuidado cada línea del código que generó Opus que el que esperas de un mantenedor de open source? ¿Verdad?
    Debería publicar algún código de acceso remoto con licencia MIT para que entre en los datos de entrenamiento de Opus
  • Me gusta más Rust que Go, así que me deja pensando. Incluso desde la perspectiva de los LLM, Rust sale mejor, pero la filosofía de dependencias de Rust es básicamente un agujero negro de seguridad, y Go es mucho mejor en eso
  • ¿Tienes algún repositorio o forge público que puedas compartir? Tengo un juego para deletrear animales de granja y me gustaría expandir mi librería y sacar más ideas

• Cuando tomé el curso de deep learning de Fast.AI, me sorprendió la cantidad de dependencias de Python que arrastra un proyecto de machine learning
  Siempre pensé que los proyectos de frontend web tenían muchas dependencias de terceros, pero a mí el ecosistema de machine learning me parece mucho más enredado
  Además, el desarrollo web siempre se ha considerado sensible a la seguridad, así que ha acumulado mucha sabiduría y prácticas al respecto, mientras que el desarrollo de ML parece mucho más improvisado y como que ni siquiera aplica muchas prácticas generales de ingeniería de software
  Por ejemplo, en ese momento una de las formas de desplegar modelos de ML era con Python pickle, que es básicamente un objeto ejecutable sin restricciones por defecto
  Un modelo en ese formato podía hacer cualquier cosa en la computadora que lo importara, y ese ecosistema tipo lejano oeste de los inicios puede facilitar mucho más las intrusiones de seguridad y los ataques a la cadena de suministro

  • En ese ecosistema hay mucha gente que originalmente no es ingeniera de software
    Algunos aprendieron algo de programación sobre la marcha, algunos son matemáticos, y otros son como desarrolladores intoxicados con la IA
    También existe la mentalidad de “el código ya no importa, mientras funcione”
    Para mucha gente, una gestión de dependencias adecuada no es más que trabajo tedioso del que no quiere ocuparse
    En muchos proyectos de machine learning se combinan todos esos factores, cuando en realidad los proyectos de ML deberían ser de los que más se enfocan en la reproducibilidad

• Busqué en repositorios y me salieron 2.2 mil repositorios creados en el último día que contienen el texto "A Mini Shai-Hulud has Appeared": https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

  • Los nombres de los repositorios parecen ser todos dos términos/palabras de Dune, como harkonen, mentat, ornithoptor, con números añadidos
    Eso parece indicar que se usaron para crear repositorios después de comprometer cuentas, probablemente tokens de autenticación de GitHub/Actions
  • Esta cuenta https://github.com/tinin46 parece tener muchísimas claves guardadas, aunque no me queda claro para qué
  • No entiendo por qué GitHub no responde de inmediato y bloquea los repositorios cuyo README coincida con la expresión regular
    Ya había pasado algo parecido antes, así que pensé que habrían aprendido la lección
    Este malware no se esforzó mucho, y Microsoft tampoco parece estar esforzándose mucho
  • ¿Qué demonios está pasando aquí?

• Para ser claro, nunca he usado pytorch y tampoco sé mucho de prácticas de seguridad de software
  Pero no se me ocurren muchos escenarios en los que pytorch necesite acceso a red
  Parece incorrecto que desde cualquier parte del código base se pueda importar cualquier módulo y usar esa API
  Da la impresión de que hacen falta restricciones adicionales de importación o análisis estático
  El lenguaje no parece tener la abstracción adecuada para tratar estos problemas
  En comparación, me gusta que en Rust puedas ver mutabilidad y lifetimes solo con la firma de una función, sin entender el código interno
  Siento que hace falta algo parecido para las dependencias
  Los desarrolladores deberían poder auditar fácilmente todas las dependencias sin meterse al código inferior y ver “ah, esta dependencia usa eval()” o “tiene acceso a red”
  Las apps móviles obligan a pedir permisos; uno pensaría que los desarrolladores también deberían poder poner en lista blanca solo ciertas capacidades, en lugar de tragarse bloques enormes de funcionalidad

  • El ecosistema de Python jamás permitiría algo así, pero ojalá este tema se entendiera y se aceptara mejor dentro de ese mundo
    No me gusta generalizar, pero parece que la comunidad de desarrollo de IA en particular prioriza la comodidad por encima de cualquier otra consideración
    Por ejemplo, ya casi es estándar que un proyecto descargue automáticamente un modelo grande en la primera ejecución
    Normalmente se puede desactivar, pero encontrar el parámetro correcto es un dolor terrible por las capas profundas de clases y código repartidas entre varias librerías
    Está bien que sea muy fácil empezar con cosas complejas, por lo general casi juguetes, pero este ambiente permisivo es bastante incómodo
    Siento que el primer paso para resolver cualquier problema siempre es “pip install …”, y algunos entornos, como MacOS, ni siquiera virtualizan bien el acceso a GPU
  • Hay casos en los que se entrena un modelo a través de varios nodos de cómputo. Ese es un gran ejemplo de algo que sí necesita acceso a red

• Esta semana me estaba preguntando si era buena idea usar uv para gestionar versiones de Python
  El sitio web [1] dice: “Como Python no ofrece binarios oficiales para distribución, uv usa distribuciones del proyecto Astral python-build-standalone”
  Apunta a este repositorio de GitHub https://github.com/astral-sh/python-build-standalone, y ahí luego menciona https://gregoryszorc.com/docs/python-build-standalone/main/r...
  Si lo entendí bien, parece que no toman directamente de python.org el código fuente para compilar Python, y no estoy seguro de qué tan seguro sea eso
  Tengo la misma preocupación con asdf [2], aunque asdf usa pyenv [3] y eso me suena más cercano a lo oficial
  ¿Alguien puede explicar cuál herramienta es mejor y más segura entre uv y asdf para instalar Python?
  [1] https://docs.astral.sh/uv/guides/install-python/
  [2] https://github.com/asdf-community/asdf-python
  [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

  • python-build-standalone sí obtiene el código fuente de CPython directamente de python.org[1]
    De hecho, ¿de dónde más lo sacaría?
    [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
  • uv y cpython no me preocupan demasiado. El proceso es sólido, responden rápido y ahora además tienen bastante financiamiento
    Lo que sí me preocupa es, por ejemplo, un formateador como mdformat, muy usado pero mantenido principalmente por una sola persona en su tiempo libre, o una dependencia súper específica que lleva años sin actualizarse y está tres niveles abajo en el árbol de dependencias
    No quiero fijar y aprobar manualmente todas las actualizaciones en una app desarrollada activamente, pero para una app seria eso ya empieza a parecer obligatorio
    Mientras tanto voy a sacar las claves API de archivos .env sin cifrar
    Si te pasa en una gran webapp de consumo da vergüenza, pero se entiende; perder cientos o miles de dólares por una dependencia indirecta de un repositorio demo de juguete que casualmente está en el mismo host y sistema duele muchísimo
    ¿Alguien sabe si OAI o Anthropic reembolsan cuando te roban claves de esta manera, o se considera error del usuario?
  • Al final, uv en sí ya es un binario que ejecutas en tu computadora para gestionar binarios de Python, paquetes, binarios dentro de esos paquetes y herramientas globales del sistema
    No sé cuánto cambia el riesgo si ellos compilan los binarios de Python o si los compila alguien más

• Últimamente la mayoría de mis pip install vienen de sugerencias de Claude Code, y yo solo aprieto Enter
  El modelo fue entrenado con datos de hace unos meses, así que no tiene forma de saber qué se comprometió esta semana
  Básicamente armé el peor filtro posible para decidir si “este paquete es seguro en este momento”

  • No deberías culpar al LLM por la flojera y la falta de diligencia
  • ¿A qué filtro te refieres?
    Dijiste que dejas que Claude Code recomiende software para instalar desde internet, y luego lo instalas tal cual
    Nunca he oído a nadie sugerir que Claude Code, ni ningún LLM, sea un filtro para decidir “si este paquete es seguro en este momento”, y por las razones que mencionaste parece una heurística pésima
  • Que los datos de entrenamiento estén desactualizados influye un poco, pero incluso un modelo al día no puede saber qué va a ejecutar setup.py en tu máquina
    Eso es porque no hay una inspección real del paquete antes de ejecutarlo
    Lo que hace falta es una herramienta que obtenga metadatos antes de ejecutar nada y verifique qué hooks existen
  • Se evita fácilmente si no presionas Enter
  • ¿Con “el peor filtro” te refieres a apretar Enter a todo lo que te diga Claude?

• Claude Code se actualiza casi todos los días, a veces varias veces por día
  Si algún día comprometen Anthropic, a todos nos va a ir muy mal

  • ¿Quiénes son “todos nosotros”?
  • No si lo ejecutas en una VM/contenedor sin privilegios y con acceso restringido a la red
    Pero hoy en día todo es YOLO
  • Seguro eso ya está descontado en el precio de Polymarket

• Vi este mensaje en GitHub del 20 de abril y me dejó algo confundido
  "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
  Si sabían del problema desde entonces y no advirtieron hasta ahora, eso sí me parecería muy mal
  Ojalá alguien que sepa más pueda aclararlo bien
  https://github.com/Lightning-AI/pytorch-lightning/issues/216...

  • Soy Andy de Lightning. El paquete malicioso se publicó en PyPI hoy a las 12:45 PM UTC
    Antes de eso no había distribuciones afectadas y no sabíamos de la filtración
    La release original en GitHub no tenía problema, pero la bajamos para evitar confusiones
  • Para quienes usan uv: https://docs.astral.sh/uv/reference/settings/#exclude-newer