Detectan paquetes npm maliciosos en varios servicios de Red Hat Cloud Services

 (github.com/RedHatInsights)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El issue está abierto y, al momento del texto, no hay responsable, milestone, ni ramas o PR vinculados
  • Se registró como un issue de seguridad porque se detectaron versiones maliciosas en varios releases de npm dentro del alcance de @redhat-cloud-services/
  • Como material de referencia se presentan el análisis de StepSecurity y los resultados de búsqueda de OSS Security Feed
  • La lista de impacto actualizada incluye 32 paquetes, entre ellos @redhat-cloud-services/chrome, frontend-components, rbac-client, types y vulnerabilities-client
  • La mayoría de las versiones comprometidas que aparecen en la tabla son 3 por paquete, mientras que @redhat-cloud-services/vulnerabilities-client incluye solo las versiones 2.1.9 y 2.1.11
  • Tomando como base toda la tabla, se pueden contabilizar 95 versiones comprometidas, y el título de un PR externo mencionado por separado también apunta a 95 versions
  • También se incluyen la familia @redhat-cloud-services/frontend-components-* y varios paquetes *-client, por lo que no se trata de un solo paquete sino de un problema de releases en todo el mismo scope
  • En los comentarios, ante la pregunta “What are these?”, respondieron “all that module is pwned”, dejando claro que se entiende que toda la lista fue comprometida
  • DanielRuf dejó constancia de que añadió este incidente a supply-chain-incidents
  • En la actividad de GitHub se ven un resumen de contenido que referencia este issue y un PR relacionado con la detección, pero en el texto todavía no se presentan el diagnóstico de Red Hat, medidas de mitigación, eliminación ni versiones corregidas

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • Espero que esté bien retomar el hilo para hablar de la configuración de cooldown. Axios, TanStack, @redhat-cloud-services y varios ataques recientes a la cadena de suministro de npm se habrían podido evitar con un cooldown
    Si usas Artifactory/Nexus, probablemente ya lo tengas, y aunque no, es fácil de configurar. La mayoría de los compromisos de npm o PyPI se dieron de baja en cuestión de horas, así que basta con ignorar paquetes con menos de N días desde su publicación. Incluso 1 día ayuda, 3 días está bien y 7 días es algo excesivo, pero funciona
    Las versiones recientes de pnpm ya incluyen por defecto un cooldown de 1 día: https://pnpm.io/supply-chain-security
    Si quieres resolverlo con un clic, puedes usar https://depsguard.com. Es un CLI que agrega cooldown y configuraciones recomendadas para npm, pnpm, yarn, bun, uv y dependabot; yo soy su mantenedor
    También está https://cooldowns.dev, más enfocado en cooldowns, y tiene scripts para ayudar con la configuración local. Todo es open source/gratis
    Si sabes editar directamente ~/.npmrc y similares, realmente no lo necesitas, pero si conoces gente a la que solo le hace falta un arreglo de un clic, podría ayudarles a evitar el próximo ataque
    Eso sí, cuando haya que parchear un CVE crítico nuevo, hay que poder saltarse el cooldown, y cada herramienta tiene su forma de hacerlo. No tengo cifras exactas de los últimos meses, pero incluso en esta era de descubrimiento de vulnerabilidades al estilo Mythos, el riesgo parece mayor por ataques a la cadena de suministro de software como la distribución de versiones maliciosas que por CVE zero-day nuevos

    • Como desarrollador de sistemas embebidos, estoy acostumbrado a fijar el toolchain y las dependencias por años, así que la cultura del desarrollo web me parece impactante en muchos sentidos
    • Hay un repositorio de GitHub de un amigo que reúne formas más sensatas y un poco más seguras de configurar esto: https://github.com/jordanconway/package-manager-hardening
    • ¿Habrá alguna forma razonable de aplicar cooldown también al pull de imágenes de Docker/Podman?
    • Incluso siendo alguien que puede abrir el archivo ~/.npmrc y agregar una línea, los casos en que se necesita un arreglo de un clic me parecen un grupo muy pequeño
    • Además del cooldown, estaría bien que más gestores de paquetes trataran de forma distinta los parches de seguridad y los lanzamientos normales (corrección de bugs/mejoras de rendimiento/nuevas funciones)
      Es perfectamente razonable decir: “un parche de seguridad solo debe incluir cambios de seguridad y no meter otras funciones”. Eso hace que tanto para investigadores de seguridad como para las herramientas sea más fácil auditar
      A los lanzamientos normales se les puede aplicar cooldown, y a los parches de seguridad se les puede quitar o poner uno mucho más corto
      Vale la pena tomar como referencia esquemas como Debian, con servidores muy estables y la posibilidad de configurar unattended upgrades para que solo aplique parches de seguridad. Este tipo de nuevos lanzamientos de paquetes también son más fáciles de auditar para investigadores de seguridad

  • En cada hilo como este hay muchos comentarios que actúan como si este tipo de ataque existiera solo en npm, o se burlan como si no se hubiera hecho nada, pero no me parece justo.
    También hay muchos comentarios que mencionan buenas funciones introducidas para proteger a los consumidores de paquetes, como delay line y pnpm.
    De lo que se habla menos es de las herramientas para mantenedores de paquetes. MFA para publicación: https://docs.npmjs.com/requiring-2fa-for-package-publishing-..., y trusted publishers, disponible desde hace cerca de un año: https://docs.npmjs.com/trusted-publishers
    Recientemente también apareció staged publishing, que combina las ventajas de ambas funciones: https://docs.npmjs.com/staged-publishing
    Ahora se puede publicar desde CI sin credenciales estáticas y exigir que el mantenedor lo apruebe con MFA antes de que realmente se haga público en el registro. Si se quiere, también se pueden exigir aprobaciones múltiples o retrasos de tiempo del lado de CI con la protección de GitHub Actions Environments.
    Hay que alentar a la comunidad a adoptar este tipo de protecciones para la publicación; de lo contrario, este problema va a seguir.

    • Según [1], “todos los paquetes afectados fueron publicados desde el repositorio RedHatInsights/javascript-clients mediante GitHub Actions OIDC, lo que indica que el propio pipeline upstream de CI/CD fue comprometido”.
      Entonces los paquetes maliciosos también habrían recibido la estrellita verde y habrían tranquilizado a los usuarios con eso de que “fueron compilados y firmados con prueba de procedencia”.
      [1] https://lwn.net/Articles/1075742/
    • Da risa porque sigue pasando. Los ataques en npm ya son tan frecuentes que se pueden marcar en el calendario, y alguien hasta hizo una parodia en versión npm del clásico artículo de The Onion “no hay forma de evitarlo”.
      Es excelente que se esté trabajando para frenarlo, pero igual sigue pasando. Da risa en el sentido de “ah, otra vez esto”.
    • Cuando lo vuelvan obligatorio para todos, recién ahí habrán hecho algo.
    • No me impresionan mucho los cambios mecánicos, y parece que hay un grupo que ve este problema como un problema cultural.
      Desde afuera, el desarrollo web tiene una energía de Lejano Oeste caótico. Hay mutabilidad, tipado dinámico, estándares y frameworks que cambian todo el tiempo, despliegue continuo, CDN, campañas A/B en tiempo real, muchas dependencias y datos sensibles de usuarios dispersos por varias infraestructuras.
      No digo que esta mirada sea correcta ni que la actitud de “ya ves” sea la adecuada, pero entiendo de dónde viene.
    • Yo creo que ambas son soluciones de maquillaje. Al final todo es una variante de “hagamos que los releases sean más difíciles de desplegar”, y eso solo va a enseñarles a las personas cómo saltarse las reglas.
      En particular, ninguna de las dos habría impedido que el backdoor de xz-utils entrara en la distribución del paquete. xz-utils sigue siendo el punto de referencia de un compromiso upstream sofisticado.
      El error aquí no es que debamos autenticar mejor a un upstream en el que ya confiábamos, sino que no se puede confiar en upstream como fuente única de seguridad. Upstream es un grupo de hackers a los que les interesa poco la ingeniería de releases robusta y tampoco son muy buenos en eso.
      Pero sí hay gente que lo hace bien. La solución del mundo Linux, y la forma en que nos salvó en xz-utils, es que existe una segunda capa humana que revisa, audita, empaqueta y personaliza para los usuarios el upstream hecho por hackers.
      Esa gente tiene otros ojos, otras necesidades de los consumidores y otros estándares de calidad, y detecta bugs y malas intenciones que upstream no está preparado para detectar.
      NPM, cargo, PyPI y compañía siguen pensando que pueden esquivar la necesidad de ese trabajo humano, pero no pueden. En el ecosistema de NPM esto se ve con más frecuencia que en Python o Rust, sobre todo porque hay muchos desarrolladores web acostumbrados a releases muy rápidos, requisitos de compatibilidad laxos y reutilización extrema.

  • En nuestra empresa usamos yarn 4, y hay una opción para bloquear la instalación de paquetes de npm durante los primeros días después de que se publican. Parece que la mayoría de estos ataques se detectan dentro de ese periodo (1 a 3 días)
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

  • Hay algunas propuestas. Un cooldown de dependencias de 1 a 2 días parece muy efectivo sin perjudicar la capacidad de aplicar parches de CVE
    Todos los lugares donde se ejecuta código, como npm install y npm test, deberían correr en entornos sin privilegios. En GitHub Actions es relativamente sencillo separar los trabajos que construyen y prueban artefactos de los trabajos que hacen despliegue, firmado, etc. Si usas IA, basta con agregar una skill/guía que fuerce este patrón
    Si usas GitHub Actions, instalar la versión más reciente de zizmor mejora mucho la postura de seguridad
    La segunda medida hace que ya no pueda “propagarse como un gusano”, lo que reduce una gran parte del problema actual. La primera les da a las empresas tiempo para responder a los ataques. También vale la pena evaluar algunos proveedores en esta área

    • ¿Y qué pasa si zizmor es comprometido?
      Dio risa como chiste, justo después de decir que hay que retrasar los paquetes nuevos
    • En vez de estos cooldowns, ¿no bastaría con ejecutar los builds en un contexto aislado?
      Corremos un proxy local de Maven, y todos los builds se hacen dentro de contenedores. Python, npm y Go solo usan repositorios públicos, así que estos builds también se hacen en contenedores, pero sin necesidad de proxy de repositorio
    • Si se trata de todos los lugares donde se ejecuta código, parece que los orquestadores tipo agente como codex y claude-code ya hacen eso por defecto

  • Justo el mismo día en que Red Hat e IBM anunciaron Project Lightwell para ayudar a detectar y corregir vulnerabilidades de la cadena de suministro
    https://www.redhat.com/en/lightwell

  • Hace unos días vi este rant interesante: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    Tiene algo de razón la idea de que la forma correcta es hacer fork de todas las dependencias que usas e instalarlas desde tu propio repositorio, revisando y fusionando cambios de upstream cuando haga falta. Aunque suena increíblemente tedioso

    • No es algo imposible de automatizar. En el mundo de Go esto podría llamarse vendoring: https://go.dev/ref/mod#vendoring
      Sirve para reducir o eliminar la dependencia de proveedores externos de hosting de dependencias, meter las dependencias dentro de tu propia herramienta de revisión de código y garantizar builds reproducibles a largo plazo
    • El problema es que están las dependencias de tus dependencias, y luego varios niveles más hacia abajo
    • Hice Packj para auditar dependencias fácilmente desde la CLI
      Packj(https://github.com/ossillate-inc/packj) detecta dependencias maliciosas en PyPI/NPM/Ruby/PHP y otros mediante análisis de comportamiento. Escanea indicadores de compromiso como ejecución de shell, uso de claves SSH, comunicación de red y uso de decode+eval con análisis estático y dinámico de código. También revisa varias propiedades de metadatos para encontrar actores maliciosos, como typosquatting
    • Puede que cambies las probabilidades, pero si no haces forks con disciplina y luego aplicas monkeypatches a todas las vulnerabilidades futuras, podrías terminar distribuyendo para siempre un fork comprometido
    • ¿No habría que no solo mantener los paquetes actualizados, sino también restringir los números de versión?

  • Hace como una semana borré Node de mi laptop y me sentí bien
    Incluso si me toca un exploit por mala suerte, estoy tratando de hacer todo dentro de contenedores de desarrollo u otros sandboxes para reducir el radio de daño. El atacante podría robarse un token de Claude, pero no va a poder escaparse del contenedor tan fácilmente para husmear en mi directorio home
    Los cooldowns y las allowlists de scripts de instalación son capas extra útiles para defensa en profundidad, especialmente en CI. Pero, en el fondo, creo que lo que tiene que cambiar es el modelo de permisos del sistema operativo. El valor por defecto de confiar en software de terceros con todos los permisos del usuario ya no funciona

    • Me da curiosidad si usas algo como Bubblewrap/Firejail/Flatpak, o cómo se vería una configuración así. Llevo tiempo pensando en una idea parecida, pero todavía no la he implementado

  • Supongo que debería poner el link de la publicación original
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • Sí. Y además hasta escribieron mal Red Hat en el título

  • Ahora ya tengo la costumbre de usar la bandera --before=2026-05-30 al instalar paquetes. Hace que elija versiones publicadas antes de la fecha indicada, y normalmente pongo unos 5 días antes

  • NPM está roto desde el diseño, y el síndrome NIH tan extendido en la comunidad impide incluso tomar medidas simples

    • No entendí muy bien la segunda frase. ¿No será que npm tiene el problema opuesto a “no fue inventado aquí”?
      Como se adoptan muchos paquetes externos en vez de desarrollar internamente, los proyectos de npm tienden a tener árboles de dependencias grandes y complejos. Desde hace tiempo hay quejas de que paquetes como https://www.npmjs.com/package/is-windows crean vulnerabilidades potenciales y dolores de cabeza de mantenimiento, aunque sería facilísimo escribir ese mismo código directamente
    • Un error común del lado NIH es pensar que recrear el paquete X tomaría mucho tiempo
      Pero obviamente no hace falta reimplementar toda la funcionalidad, solo la que necesitas
      Además, cuando codificas una sola función, tampoco necesitas crear abstracciones ni interfaces extra. Así que sale más barato y probablemente se integra mejor
      Otro error es pensar que vas a introducir bugs y vulnerabilidades. Si eres mal programador, puede pasar, pero sí puedes evitar toda una categoría de vulnerabilidades que aparece en los límites de integración entre dos librerías que no fueron diseñadas para encajar exactamente entre sí. Y eso pasa mucho