Atención a los usuarios de Node.js: el ataque de confusión manifiesta abre la puerta al malware


05 de julio de 2023Ravie LakshmanánCadena de Suministro / Seguridad del Software

El registro npm para el entorno de tiempo de ejecución de JavaScript de Node.js es susceptible a lo que se denomina un confusión manifiesta ataque que potencialmente podría permitir a los actores de amenazas ocultar malware en las dependencias del proyecto o realizar la ejecución de scripts arbitrarios durante la instalación.

«El manifiesto de un paquete npm se publica independientemente de su tarball», Darcy Clarke, ex gerente de ingeniería de GitHub y npm, dicho en un artículo técnico publicado la semana pasada. «Los manifiestos nunca se validan por completo con el contenido del tarball».

«El ecosistema ha asumido en términos generales que el contenido del manifiesto y el tarball son consistentes», agregó Clarke.

El problema, en esencia, se deriva del hecho de que los metadatos del manifiesto y del paquete están desacoplados y que nunca se comparan entre sí, lo que genera un comportamiento inesperado y un mal uso cuando hay una falta de coincidencia.

Como resultado, un actor de amenazas podría explotar esta laguna para publicar un módulo con un archivo de manifiesto (paquete.json) que contiene dependencias ocultas y ejecutar scripts de instalación, lo que podría allanar el camino para un ataque a la cadena de suministro y el envenenamiento de un entorno de desarrollador.

«La confusión de manifiestos se vuelve problemática en entornos de desarrollo sin herramientas y flujos de trabajo efectivos de DevSecOps, especialmente cuando las aplicaciones confían ciegamente en los manifiestos de aplicaciones en lugar de los archivos reales (vulnerables o maliciosos) contenidos en los paquetes de código abierto», dijo el investigador y periodista de Sonatype, Ax Sharma. dicho.

El hallazgo subraya el hecho de que no se puede confiar en los metadatos contenidos en los archivos de manifiesto del paquete cuando se descarga un paquete del repositorio de código abierto, lo que requiere que los usuarios tomen medidas para escanear paquetes para cualquier característica anómala y exploits.

Ataque de confusión manifiesta

Se dice que GitHub, según Clarke, está al tanto del problema desde al menos principios de noviembre de 2022, y la subsidiaria de Microsoft afirma que planea abordarlo internamente a partir de marzo de 2023. Sin embargo, el problema sigue sin resolverse hasta la fecha.

A falta de una solución oficial, el investigador de seguridad Felix Pankratz ha puesto a disposición una secuencia de comandos de Python que se puede usar para probar discrepancias entre los manifiestos en los módulos npm.

El desarrollo también se produce cuando la empresa de seguridad para desarrolladores Snyk, en asociación con Redhunt Labs, examinó 11,900 repositorios de la las 1000 principales organizaciones de GitHub para dependencias inseguras, descubriendo 1,229,601 fallas en 15,584 archivos de dependencias vulnerables.

«Deserialización de datos no confiables fue el tipo de vulnerabilidad más prevalente con la friolera de 130.831 ocurrencias en los repositorios de Java, lo que lo convierte en el 40 por ciento del total de vulnerabilidades identificadas», el estudio dicho.

En proyectos basados ​​en JavaScript, prototipo de contaminación surgió como la principal deficiencia con 343.332 ocurrencias. Negación de servicio (DoS) las fallas contribuyeron más en los proyectos de Python y Ruby con 19,652 y 56,331 ocurrencias, respectivamente.

«La amenaza de que las dependencias vulnerables interrumpan el estado de seguridad de las cadenas de suministro de software llegó para quedarse», dijeron los investigadores de seguridad Umair Nehri y Vandana Verma Sehgal. «Por lo tanto, los desarrolladores deben tener cuidado con las dependencias que usan en sus proyectos y mantenerlas actualizadas para mantenerlas parcheadas de cualquier vulnerabilidad conocida».

¿Encontraste este artículo interesante? Siga con nosotros Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.





ttn-es-57