GitLab descubre un ataque generalizado a la cadena de suministro de NPM

• En todo el ecosistema de npm se está propagando una variante de malware destructivo, detectada por el equipo de seguridad de GitLab
• El malware es una forma evolucionada de Shai-Hulud, con una estructura de propagación tipo gusano que infecta automáticamente otros paquetes del desarrollador comprometido
• Tras robar credenciales de GitHub, AWS, GCP y Azure, entre otros, exfiltra datos a repositorios de GitHub controlados por los atacantes
• Incluye un “dead man’s switch” que elimina de inmediato los datos del usuario si se bloquea al mismo tiempo el acceso a GitHub y npm
• GitLab confirmó que sus propios sistemas no fueron infectados y ofrece medidas de detección y respuesta mediante Dependency Scanning y GitLab Duo Chat

---

Resumen del ataque

• El equipo de Vulnerability Research de GitLab detectó un ataque masivo a la cadena de suministro dentro del ecosistema npm
  • Un sistema interno de monitoreo descubrió varios paquetes infectados
  • Se confirmó que el malware es una variante de Shai-Hulud
• El malware usa propagación tipo gusano para infectar automáticamente otros paquetes del desarrollador comprometido
• GitLab confirmó que no utilizó paquetes maliciosos en sus propios sistemas y compartió la información con la comunidad de seguridad

Estructura interna del ataque

• Los paquetes maliciosos de npm detectados por el sistema interno de monitoreo realizan las siguientes funciones
  • Recopilan credenciales de GitHub, npm, AWS, GCP y Azure
  • Envían los datos robados a repositorios de GitHub controlados por los atacantes
  • Infectan automáticamente otros paquetes de la víctima
  • Ejecutan una carga destructiva si se bloquea el acceso a la infraestructura
• Se han confirmado múltiples paquetes infectados y la investigación sigue en curso

Análisis técnico: cómo avanza el ataque

Vector de infección inicial

• El malware penetra en el sistema mediante un proceso de carga de varias etapas
  • Se agrega el script setup_bun.js al package.json del paquete infectado
  • A simple vista, se disfraza como si fuera para instalar el runtime de JavaScript Bun
  • En realidad ejecuta bun_environment.js (10 MB, carga útil ofuscada)
• Está compuesto por un archivo loader pequeño y una carga útil grande y ofuscada para evadir la detección

Recolección de credenciales

• Apenas se ejecuta, recopila tokens y secretos desde diversas fuentes
  • Tokens de GitHub (ghp_, gho_)
  • Credenciales de AWS, GCP y Azure
  • Tokens de npm (.npmrc y variables de entorno)
  • Usa la herramienta Trufflehog para escanear todo el directorio personal en busca de claves API, contraseñas e historial de Git

Red de exfiltración de datos

• Con los tokens robados de GitHub, crea repositorios públicos con la descripción “Sha1-Hulud: The Second Coming.”
  • Esos repositorios cumplen el rol de buzón de entrega de datos
  • Instala runners de GitHub Actions para asegurar persistencia
• Si no tiene permisos suficientes, busca otros repositorios con el mismo marcador para reutilizar tokens de otros sistemas
  • Así forma una red distribuida de intercambio de tokens

Propagación en la cadena de suministro

• Usa los tokens de npm robados para infectar todos los paquetes de la víctima
  1. Descarga el paquete original
  2. Inserta setup_bun.js como script de preinstall
  3. Agrega la carga útil bun_environment.js
  4. Incrementa el número de versión
  5. Vuelve a publicar el paquete infectado en npm

Dead man’s switch

• El malware monitorea de forma continua el acceso a GitHub (exfiltración de datos) y npm (propagación)
  • Si ambos canales quedan bloqueados, ejecuta de inmediato la destrucción de datos
• Windows: elimina archivos del usuario y sobrescribe sectores del disco
• Unix: sobrescribe archivos con el comando shred y luego los elimina
• Si se eliminan masivamente repositorios de GitHub o se revocan en masa tokens de npm, existe el riesgo de que los sistemas infectados borren datos al mismo tiempo

Indicadores de compromiso (IoC)

• Principales indicadores de detección
  • Archivo: bun_environment.js (script malicioso de post-install)
  • Directorios: .truffler-cache/, .truffler-cache/extract/
  • Procesos: del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
  • Comandos: curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"

Soporte de detección y respuesta de GitLab

• Los usuarios de GitLab Ultimate pueden verificar de inmediato su nivel de exposición con funciones de seguridad integradas
  • Si Dependency Scanning está activado, detecta automáticamente paquetes infectados dentro de package-lock.json o yarn.lock
  • Muestra una alerta cuando una merge request incluye paquetes infectados
• También permite detección rápida basada en consultas mediante integración con GitLab Duo Chat
  • Ejemplo: “¿Hay dependencias afectadas por la campaña Shai-Hulud v2?”
  • El Security Analyst Agent consulta los datos de vulnerabilidades del proyecto y responde al instante
• Para equipos que administran múltiples repositorios, se recomienda combinar detección automatizada basada en CI/CD con respuesta rápida basada en agentes

Perspectivas a futuro

• Este ataque se evalúa como una nueva forma de ataque a la cadena de suministro que usa la destrucción de datos de las víctimas para proteger la infraestructura del atacante
• GitLab está colaborando con la comunidad para desarrollar estrategias de recuperación seguras y sigue monitoreando variantes con sistemas automáticos de detección
• El objetivo es prevenir daños secundarios causados por el dead man’s switch mediante el intercambio temprano de información

[GN⁺]

Opiniones de Hacker News

• Hace como un mes necesité hacer una tarea fastidiosa y busqué un paquete de NPM
  Ejecuté brew install npm y se vino una cascada de dependencias; me detuve un momento a pensar en los riesgos y beneficios, y al final di marcha atrás con brew uninstall npm
  En su lugar lo resolví con un viejo pipeline de utilidades Unix y awk, y viéndolo ahora, fue la mejor decisión

  • La lección es clara: no hay que usar tecnologías web para scripting local
    NPM es una herramienta creada para resolver problemas de compatibilidad de navegadores, así que en un entorno sin navegador introduce complejidad innecesaria
  • Por eso hacen falta la containerización o la virtualización
    Si ejecutas directamente en tu sistema principal código de ecosistemas con muchas dependencias, como Node o Python, te expones a ataques a la cadena de suministro
    Por eso yo ni siquiera instalo intérpretes de Python o JS en mi sistema base
  • Yo antes también corría npm solo dentro de contenedores Docker, pero en los foros a menudo se burlaban de eso
    Al final lo dejé, pero ahora parece que sí era lo correcto
  • Tuve una experiencia parecida. Vi cuántas dependencias quería traer artillery y lo descarté de inmediato
  • Irónicamente, los desarrolladores siempre dicen que el sentido común es la mejor seguridad, pero luego instalan montones de paquetes no verificados con un comando de una sola línea

• Alguien dijo que “si GitHub elimina en masa repositorios maliciosos, miles de sistemas podrían destruir datos de usuarios al mismo tiempo”,
  suena como una toma de rehenes, y por eso salió la broma de “dispárenle al rehén”

  • Pero el rehén (el usuario) se metió solo en el peligro, así que al final es consecuencia de su propia decisión

• Yo también fui víctima de este ataque de npm
  Me impactó enterarme de que GitHub CLI guarda tokens OAuth en texto plano en el directorio HOME
  Si el atacante accedía, podía hacer casi cualquier cosa con mi cuenta

  • En realidad, GitHub CLI solo guarda el token en texto plano cuando no hay keyring
    En macOS se guarda de forma segura en el llavero del sistema: discusión relacionada
  • Sí, pero los archivos de cookies del navegador tienen un problema parecido
    Chrome usa protecciones del sistema operativo, pero Firefox todavía no
    Al final, la solución de fondo es el control de acceso basado en sandbox
  • Todos los tokens deberían estar en un llavero protegido
    Pero no existe una solución consistente entre plataformas, y ni siquiera en MacOS hay una forma perfecta
  • Yo también fui víctima. Me infecté después de instalar Backstage
    Se creó el directorio ~/.dev-env y mi laptop se convirtió en un runner de GitHub
    Tal vez el sistema de archivos de solo lectura de Bluefin Linux ayudó a limitar el daño

• Todos culpan solo a npm, pero GitHub también tiene responsabilidad
  No detectó con rapidez los repositorios maliciosos, y el problema de los repositorios con malware ya es grave

  • Aun así, gracias a que se subió a GitHub, hubo gente que detectó el daño rápidamente
    Si se hubiera enviado en secreto a un servidor externo, habría sido mucho peor
  • Microsoft no puede filtrar todo
    Hacen falta herramientas y prácticas a nivel comunidad
  • Como GitHub es de Microsoft, también está vinculado con el repositorio de paquetes de GoLang
    Si aparecen regulaciones comerciales o restricciones en los flujos de build, eso podría llevar a problemas grandes
  • No se puede negar que ambas empresas tienen un nivel de seguridad bastante normalito
  • Este malware crea repositorios con el mismo patrón, así que probablemente se podía detectar incluso con reglas simples

• Me preguntaba por qué solo NPM parece ser objetivo de ataques
  Python o Java también son muy populares, pero últimamente han estado más tranquilos

  • NPM permite ejecutar comandos arbitrarios con post-install hook,
    y la cultura de dependencias con rangos de versión hace que la infección se propague rápido
    En Java es más común fijar versiones específicas, así que esto pasa menos
  • Node tiene una biblioteca estándar pequeña y alta dependencia de la comunidad
    Por eso un solo paquete arrastra decenas de subdependencias
  • JS es el lenguaje más popular en GitHub, así que la superficie de ataque es amplia,
    y como hay muchos desarrolladores con poca experiencia, la seguridad suele ser más débil
  • La comunidad de JS tiene una fuerte obsesión con usar la versión más reciente
    Otros ecosistemas actualizan después de validar, pero en JS hacen upgrade de inmediato
  • NPM tiene fronteras de seguridad débiles
    Durante la instalación puede ejecutar scripts libremente, y ni la JVM ni Python funcionan así

• Si agregas esto a .npmrc

  ignore-scripts=true
  

  puedes reducir el vector de ataque
  Artículo relacionado

  • Me pregunto si hay alguna forma de revisar de antemano si un paquete tiene hooks preinstall/postinstall antes de instalarlo
  • Si “ignore scripts” es tan seguro, entonces por qué existe esa opción,
    y también queda la duda de si desactivarlo puede romper dependencias
  • Pero al final, si ejecutas JS en un entorno Node, no puedes impedir el acceso a variables de entorno o archivos
  • O simplemente puedes usar pnpm

• Lo que más preocupa en este ataque es el robo de credenciales
  Si instalaste un paquete infectado, puede que se hayan filtrado variables de entorno o tokens de .npmrc
  Hay que rotar de inmediato los tokens y las API keys
  La rotación periódica no es una respuesta posterior a una intrusión, sino una medida preventiva

  • Si un desarrollador reutiliza contraseñas, entonces sí estamos ante un problema gravísimo
    Las credenciales no deberían guardarse en variables de entorno ni en archivos; hay que usar llaves de seguridad o archivos cifrados
  • Si no sabes si hubo infección, primero hay que seguir el orden detectar la infección → limpiar → rotar tokens
  • Este ataque no es solo una infección simple, sino una forma de tomar de rehén a todo el ecosistema, así que es más peligroso
    Es como incrustar transacciones maliciosas en un libro mayor distribuido
  • Los secretos deben guardarse siempre en un secret locker
    El problema es que muchos servicios todavía dejan el almacenamiento en texto plano como valor predeterminado
  • Y además este malware intenta destruir datos cuando deja de propagarse

• Me pregunto por qué, con estos ataques repitiéndose, no funcionan los sistemas de detección basados en IA
  Microsoft habla tanto de IA, pero parece que no la usa realmente en la seguridad de GitHub

  • Pero decir “la IA detectó el ataque” ya se volvió un lugar común del marketing de seguridad
    Igual que cuando todo intento bloqueado por un firewall se clasificaba como ataque, el término ya perdió fuerza
  • En nuestra empresa usamos SonaType Lifecycle, y dicen que bloquea este tipo de ataques con IA
    Internamente eso lo soporta SonaType IQ Server
  • La “IA” actual son modelos generativos, así que están más enfocados en generar que en evaluar
    De hecho, el proyecto curl ha sufrido spam de reportes de seguridad generados por IA

• Me pregunto si todavía hay alguna razón para seguir permitiendo scripts postinstall
  Quizá sería mejor preguntarle al usuario si quiere ejecutarlos

  • Pero la mayoría de los usuarios va a hacer clic en “sí”,
    y en los servidores de CI se necesita instalación no interactiva, así que en la práctica parece difícil

• El artículo fue muy perspicaz, pero me decepcionó que al final terminara como promoción de funciones de seguridad de GitLab

  • Para usuarios de GitLab quizá sí fue útil
  • Aun así, eso no le quita valor a la perspectiva del artículo