Análisis posterior al ataque a la cadena de suministro de Tinycolor

(sigh.dev)

3 puntos por GN⁺ 2025-09-20 | Aún no hay comentarios. | Compartir por WhatsApp

Se produjo un incidente en el que múltiples paquetes de npm que incluían el paquete de código abierto @ctrl/tinycolor quedaron infectados con versiones maliciosas; la causa fue el robo de un token de npm a través de un workflow de GitHub Actions en un repositorio compartido
El atacante usó un token de npm con permisos amplios para publicar código malicioso en aproximadamente 20 paquetes; entre ellos, @ctrl/tinycolor tenía un gran impacto por alcanzar 2 millones de descargas semanales
Las versiones infectadas ejecutaban una carga maliciosa en la etapa de postinstall, y los equipos de seguridad de GitHub y npm respondieron rápidamente con medidas de eliminación y limpieza
El autor preparó un plan de seguridad reforzado para evitar reincidencias, incluyendo la migración a Trusted Publishing (OIDC), minimización de permisos de tokens, obligatoriedad de 2FA y uso de funciones de pnpm
Este incidente muestra la fragilidad de la seguridad en la cadena de suministro de software y evidencia la necesidad de mejorar las funciones de seguridad y las prácticas de seguridad en todo el ecosistema de npm

TL;DR

Un workflow malicioso de GitHub Actions fue enviado a un repositorio compartido y robó un token de npm
Con ese token, el atacante publicó versiones maliciosas de 20 paquetes, y entre ellos @ctrl/tinycolor tuvo mayor alcance por su alto volumen de descargas
Ni la cuenta personal ni los repositorios fueron comprometidos directamente, y tampoco hubo phishing ni instalación local de malware
Gracias a la rápida respuesta de los equipos de seguridad de GitHub y npm, las versiones maliciosas fueron eliminadas y luego se volvieron a publicar versiones limpias para depurar la caché

En la tarde del 15 de septiembre, el miembro de la comunidad Wes Todd avisó del problema por DM en Bluesky
Para entonces, los equipos de seguridad de GitHub y npm ya estaban organizando la lista de paquetes afectados e iniciando las medidas de eliminación
Como pista inicial, se compartió el nombre de una rama maliciosa, 'Shai-Hulud', tomado del nombre del gusano de arena del universo de Dune

En el repositorio de angulartics2, con el que se había colaborado hace mucho tiempo, todavía había un colaborador con permisos de administrador
El token de npm almacenado en ese repositorio fue robado por un workflow malicioso de GitHub Actions
Con ese token, el atacante publicó cerca de 20 paquetes, incluido @ctrl/tinycolor
Los equipos de seguridad de GitHub y npm eliminaron rápidamente las versiones maliciosas, y el autor volvió a publicar nuevas versiones confiables

Al instalar una versión maliciosa, se ejecutaba un script de postinstall, generando un riesgo de seguridad
Se recomienda a los usuarios afectados consultar la guía de respuesta inmediata de StepSecurity

Antes se realizaba la publicación automática con la combinación semantic-release + GitHub Actions
Aunque se usaba la función de provenance de npm, esta no podía detener a un atacante con un token válido
En adelante, se planea eliminar los tokens estáticos mediante la adopción de Trusted Publishing (OIDC)
Por ahora, se revocaron todos los tokens y se están aplicando medidas adicionales de seguridad como 2FA obligatoria, permitir solo tokens con permisos granulares y evaluar la función minimumReleaseAge de pnpm

Hace falta una opción a nivel de cuenta de npm para forzar Trusted Publishing basado en OIDC
Se necesita una función para bloquear publicaciones cuando falte provenance, así como soporte completo para la integración entre semantic-release y OIDC
Se desea que la interfaz de GitHub ofrezca una función de publicación con aprobación manual basada en 2FA
Debería ser posible usar protecciones al nivel de GitHub Environments incluso sin una suscripción Pro
En la página de paquetes de npm, debería mostrarse si existe un script de postinstall y hacerse público el motivo de las versiones eliminadas