Ataques a la cadena de suministro en los repositorios de NPM

Utilizar paquetes de código abierto en los desarrollos de software es una gran alternativa para ahorrar en gastos y mantenimiento, y por supuesto en tiempos en lo que a desarrollo se refiere. Puesto que en lugar de encargarnos de desarrollar por nuestra cuenta ciertas funciones predeterminadas podemos apoyarnos del open source y emplear estar funciones previamente diseñadas.

Sin embargo, en los últimos años se ha producido un incremento en el número de ataques a la cadena de suministros de software open source específicamente la cadena de suministros de repositorios NPM.(NPM  es el sistema de gestión de paquetes por defecto para Node.js, una de las tecnologías más empleadas actualmente y principalmente en desarrollo web). Los atacantes usan varios métodos para infectar paquetes de código abierto y distribuir código malicioso, envenenando efectivamente el repositorio que alimenta a millones de otros programas.

Un estudio realizado por investigadores de la Universidad de Carolina del Norte y Microsoft ofrece un nuevo enfoque para proteger las cadenas de suministro de software,usando métodos empíricos basados ​​en datos para predecir qué paquetes de código abierto son más susceptibles de convertirse en el objetivo de los ataques. El estudio efectuado en 1,63 millones de paquetes en el repositorio de NPM, revela seis indicadores de debilidad en la cadena de suministro de software de código abierto.

 Actuar sobre estos hallazgos puede ayudar a los mantenedores de paquetes y a los usuarios a tomar mejores decisiones de seguridad y, por lo tanto, proteger su software contra posibles ataques a la cadena de suministro. En el estudio realizado se destacan los siguientes puntos débiles en la cadena de suministros de paquetes NPM, que son más susceptibles a verse comprometidos en un ataque:

‍

1. Había 2.818 mantenedores cuyos dominios habían expirado. Un atacante puede comprar un dominio vencido y utilizarlo para secuestrar las cuentas de los mantenedores a menos que esté protegido por autenticación de dos factores (2FA).

‍

‍

‍

‍

2. Alrededor del 2 % (33 000) de los paquetes incluían scripts de instalación. Los scripts de instalación se ejecutan automáticamente antes, durante o después de la instalación de un paquete. Si encuentran comprometidos, pueden permitir que los atacantes efectúen actividades maliciosas en los dispositivos host, como la transferencia de datos de usuarios, la descarga de cargas útiles maliciosas, la ejecución de shells inversos, la eliminación de archivos y directorios.

3. Alrededor del 59% de los paquetes no recibieron mantenimiento durante dos años. Además, el 44% de los mantenedores estuvieron inactivos durante dos años. Los paquetes sin mantenimiento tienen una mayor probabilidad de verse comprometidos sin ser detectados. Los mantenedores inactivos pueden ser objeto de ataques de secuestro de cuentas sin darse cuenta.

4. Un pequeño porcentaje de los paquetes tenía demasiados mantenedores, lo que aumenta las posibilidades de que al menos una de las cuentas de los mantenedores se vea comprometida.

5. Algunos paquetes tenían demasiados colaboradores, lo que dificultaba que los mantenedores controlaran todos los cambios. Un atacante puede utilizar la ingeniería social para convertirse en un contribuyente de confianza de dichos paquetes antes de infiltrar código malicioso.

6. El 1% de los mejores mantenedores estaba sobrecargado y poseía un promedio de 180 paquetes. Los atacantes tienen un mayor incentivo para apuntar a dichos mantenedores porque, en primer lugar, es más probable que pasen por alto los cambios en cualquier paquete en particular, en segundo lugar, si se ven comprometidas, sus cuentas pueden proporcionar acceso a muchos paquetes.

 De los puntos vistos anteriormente se puede resaltar el punto 3, puesto que en auditorias de seguridad es una de las vulnerabilidades encontradas con más frecuenta paquetes dependencias obsoletas, empleadas en aplicativos críticos. Por lo que instamos a ser conscientes de saber que dependencias usamos en nuestros aplicativos y velar porque se tengan las últimas actualizaciones y si dependemos de una tecnología con periodos de actualización muy largos, buscar otra alternativa con un mejor soporte.

‍