La historia de la seguridad de código abierto está repleta de ejemplos de fallos catastróficos y cuasi accidentes. Una campaña de criptomalware descubierta a principios de septiembre se sitúa en un punto intermedio entre ambos. Según (aqui)Un actor de amenazas no identificado comprometió una sola cuenta de mantenimiento de npm y, con ese acceso, implementó código malicioso en paquetes con más de dos mil millones de descargas semanales.

Ya se ha descrito como el mayor ataque a la cadena de suministro en la historia de npm, que a su vez es el registro de software más grande del mundo. Si esto es un presagio de lo que está por venir, ¿cómo se protegen los usuarios corporativos de código abierto del creciente riesgo cibernético?

¿Qué pasó con npm?

El 8 de septiembre, el desarrollador y mantenedor de código abierto Josh Junon (alias "qix") recurrió a redes sociales para revelar que su cuenta de npm había sido comprometida. Se enteró después de que dicha cuenta comenzara a publicar versiones troyanizadas de paquetes populares como chalk (300 millones de descargas semanales), debug (357 millones) y ansi-styles (371 millones).

El código malicioso “intercepta silenciosamente la actividad criptográfica y web3 en el navegador, manipula las interacciones de la billetera y reescribe los destinos de pago para que los fondos y las aprobaciones se redirijan a las cuentas controladas por el atacante sin ninguna señal obvia para el usuario”, según Aikido.

Se informó que Junon fue blanco de un sofisticado ataque de ingeniería social. Los atacantes registraron un dominio de typosquatting varios días antes y lo utilizaron para suplantar la identidad de administradores legítimos de npm en un correo electrónico para restablecer la autenticación de dos factores. Junon afirmó que "parecía muy legítimo".

¿Un escape afortunado?

Al final, la comunidad de código abierto se unió y, sorprendentemente, todas las versiones maliciosas del paquete fueron eliminadas menos de cuatro horas después.

“Todos trabajan juntos. La información se puede compartir. La cantidad de personas que trabajan en esto ahora no solo supera a su equipo de seguridad, sino a su empresa”, dijo Anchore, vicepresidente de seguridad. Josh Bressers. Los informes de la época sugirieron que los actores de la amenaza habían logrado robar menos de $1000 de las billeteras de criptomonedas de las víctimas, a pesar del alcance potencialmente enorme de la campaña.

Sin embargo, ese no fue el final de la historia. Incluso en el breve periodo de tiempo en que los paquetes estuvieron circulando libremente, se propagaron ampliamente. Según el proveedor de seguridad Wiz, el 10 % de los entornos en la nube... fueron impactados.

“Durante el breve período de dos horas en que las versiones estuvieron disponibles para su descarga, si se incorporaron a las compilaciones frontend y se enviaron como activos web, cualquier navegador que cargara el sitio web afectado ejecutaría una carga maliciosa que intercepta las API de red y billetera para reescribir silenciosamente los destinatarios/aprobaciones de criptomonedas antes de firmar, de modo que las transacciones se desviarían a billeteras controladas por los atacantes”, afirmó el proveedor.

Posteriormente se supo que los actores de amenazas también atacaron a otros mantenedores y paquetes, como duckdb, proto-tinker-wc, prebid-universal-creative, prebid y prebid.js. Si bien es una suerte que la carga maliciosa fuera solo malware para robar criptomonedas, en lugar de algo más grave, sin duda es una advertencia para el futuro.

Mantenedores en la mira

No hay vuelta atrás con el genio del código abierto. En 2024 se descargaron más de 6.6 billones de componentes de código abierto, y npm representó 4.5 billones de solicitudes, según SonatipoPero es preocupante que los encargados del mantenimiento de paquetes enormemente populares, a menudo con recursos insuficientes y sobrecargados, estén siendo atacados en mayor número. El vicepresidente regional de Sonatype, Mitun Zavery, compara esta última campaña con la apuntando a xz Utils el año pasado.

Hemos observado un patrón claro en el que los actores de amenazas atacan a los encargados del mantenimiento de proyectos ampliamente utilizados, pero con recursos limitados. El reciente ataque a paquetes npm como chalk y debug refleja lo que observamos con el intento de puerta trasera de xZ Utils. En ambos casos, el adversario se ganó la confianza con paciencia para obtener el control, lo que demuestra que la ingeniería social es ahora una etapa clave en el ataque a la cadena de suministro», declara a ISMS.online.

La industria debe reconocer que los mantenedores de código abierto forman parte de nuestra infraestructura crítica y comenzar a dotarlos de los recursos necesarios, incluyendo financiación, herramientas de seguridad y redes de soporte. Nuestro trabajo en xz Utils demostró que la alerta temprana colaborativa y la respuesta rápida en todo el ecosistema pueden detener estos ataques antes de que se propaguen.

Asumir un compromiso

Sachar Menashe, vicepresidente de investigación de seguridad de JFrog, sostiene que el desafío con este tipo de ataques es su velocidad.

Una vez que un paquete confiable se ve comprometido, puede propagarse rápidamente a través de los canales de CI/CD y entre proyectos. Un enfoque de confianza cero es fundamental: no se debe confiar en ningún paquete solo por su popularidad —comenta a ISMS.online—. Para mitigar estos ataques, las organizaciones deberían exigir la autenticación de dos factores. Esto ya se aplica en npm y PyPI, pero no en otros repositorios como Maven y NuGet.

Lo ideal sería que los paquetes fueran examinados antes de ingresar a una organización, con reglas definidas y análisis de dependencias directas y transitivas en contexto, continúa Menashe.

Retrasar las actualizaciones también ayuda. De hecho, nuestra investigación demuestra que esperar al menos 14 días antes de implementar nuevas versiones de paquetes ofrece una sólida protección, ya que los paquetes pirateados casi siempre se detectan y eliminan dentro de este plazo, afirma.

Zavery, de Sonatype, sostiene que la visibilidad de los componentes y paquetes de código abierto también es clave.

“Las organizaciones deben asumir que es posible una vulneración y estar preparadas para responder mediante el mantenimiento de listas de materiales de software (SBOM) precisas, la supervisión de cambios sospechosos en las dependencias y el aislamiento de las compilaciones”, explica. “Cuando investigamos el incidente de xz Utils, vimos cómo esta visibilidad permitió identificar y eliminar rápidamente los componentes dañados”.

Los estándares de seguridad también podrían ayudar a las organizaciones, argumenta Zavery.

“Marcos como la norma ISO 27001 pueden ayudar a implementar procesos rigurosos de gestión de riesgos, control de acceso y respuesta a incidentes, pero deben aplicarse desde una perspectiva de cadena de suministro”, concluye. “Integrar controles de seguridad de código abierto en estas normas puede hacer que las organizaciones sean más resilientes ante el tipo de robo de cuentas que acabamos de ver”.

Una cosa es segura: estos ataques volverán con más fuerza cada vez. Apenas unos días después del inicio de esta campaña, El primer malware gusanoble de la historia Ataque al ecosistema NPM. Pase lo que pase, los CISO no pueden permitirse tener un punto ciego en la seguridad del código abierto en su organización.