Transmisiones de Node.js: los ingenieros de Google encontraron una vulnerabilidad en los scripts de NPM

Desarrolladores de Node.js, ejecuten el comando `npm install` bajo su propio riesgo y recuerden que el gusano autopropagante camina libremente por el ecosistema.

Nunca puede suponer que un archivo descargado de Internet es seguro. Esto es cierto para NPM, el administrador de paquetes estándar de Node.js. La vulnerabilidad en la instalación de scripts permite a un atacante crear un gusano autopropagante que puede pasar a través de paquetes NPM.


"Esto es posible porque un paquete NPM puede pasar fácilmente a través de la mayoría del ecosistema por sí mismo", escribe el desarrollador de Google Sam Sakoni en su artículo "Exponiendo NPM Hydra".

Como en otros administradores de paquetes, NPM admite scripts de "ciclo de vida" que pueden ser ejecutados por comandos externos en el sistema como el usuario actual. Aunque estos scripts a menudo son útiles y se usan para limpiar archivos después del proceso de instalación, compilar módulos binarios y crear automáticamente archivos de configuración, pueden ser peligrosos al mismo tiempo, ya que pueden realizar cambios en el sistema al ejecutar varios comandos.
"Es posible que los paquetes de NPM escritos con intención maliciosa, durante la instalación, ejecuten secuencias de comandos que están integradas en otros paquetes, que a su vez se publican en el registro y otros paquetes creados por el usuario", escribe el blog oficial de NPM en un artículo. Sin embargo, la compañía informa que los beneficios de usar estos scripts superan los riesgos de una amenaza potencial.

La publicación minimiza el riesgo y llama la atención sobre los paquetes que están "limpios desde el principio", pero no todos están "cien por ciento" seguros de esto. El artículo de Sakoni, a excepción de algunas soluciones alternativas, no deja en claro cómo asegurarse de que los paquetes que instalan los usuarios no sean lo que esperaban.

"NPM no puede garantizar que su registro de paquetes sea seguro", señala el artículo.

Gusano se filtra a través de dependencias de paquetes

El gusano aprovecha tres características en NPM: versiones semánticas (semver), publicación en un registro centralizado y privilegios para un usuario que inicia sesión automáticamente. Porque el usuario permanece autorizado hasta que inicie sesión manualmente. Cualquiera que inicie sesión y ejecute la instalación permite que otros módulos ejecuten una amplia variedad de comandos. Mientras no haya un enlace a versiones específicas, los paquetes pueden actualizarse a nuevas versiones, y cada uno de ellos puede ejecutar código. Y finalmente, pueden enviar paquetes al servidor de registro central, desde donde otros pueden instalarlos.

El ataque de gusano se basa en la ingeniería social para la infección inicial y las "mejoras" antes mencionadas pueden moverse libremente por el ecosistema.

Primero, el atacante engaña al propietario del paquete NPM para que instale el paquete infectado en su sistema. Puede ser phishing o cualquier otro ataque similar. Una vez instalado, crea una versión "troyana" del paquete del propietario del módulo NPM y establece un gancho para iniciar el gusano donde sea que esté instalado. El módulo modificado publicado en la cuenta del propietario se convierte en el punto de partida para la infección de todos sus paquetes, lanzando el módulo troyano como una dependencia. El gusano crea nuevas versiones de módulos en la cuenta con el comentario "corrección de errores", y ahora, cuando está instalado, se puede ejecutar el código de autopropagación.

Por un ejemplo. Phonegap tiene 463 dependencias intermedias. Y 276 cuentas NPM individuales pueden actualizar versiones de sus paquetes. Ahora, solo una persona de estos 276 es suficiente para que el gusano continúe infectando a todos los que instalaron el paquete desde el proyecto PhoneGap, dice Sakoni.

NPM niega riesgos

Si bien el agujero no se ha cerrado, una nota sobre la vulnerabilidad del Equipo de preparación para emergencias informáticas de los Estados Unidos destaca varias soluciones para sortear el peligro. Utilizan la opción "-noir-scripts" cuando instalan nuevas dependencias, cierran versiones con "npm-shrinkwrap" y alientan a los usuarios cuyos módulos están constantemente desvinculados de NPM.

Las organizaciones que usan NPM en sus entornos deben ejecutar un espejo de registro NPM local y evitar que los usuarios individuales instalen directamente dependencias del registro principal. Deben verificar regularmente el registro local y asegurarse de que los archivos maliciosos no estén en la lista de dependencias.

Sakoni recomendó establecer el tiempo de vencimiento de los tokens y obligar a los usuarios a salir de NPM después de un cierto período de tiempo. En una publicación de blog, la compañía no describió estas recomendaciones, pero anunció otras soluciones para minimizar los riesgos.

Una idea es complicar la publicación de módulos, si el usuario no es consciente del peligro, esto puede ser una autenticación de dos factores. Todavía puede trabajar con compañías que brindan protección, ofreciendo este último para verificar los módulos, pero hasta ahora esto no es posible. Por el momento, la compañía monitorea los paquetes que se actualizan con frecuencia, ya que el gusano puede ser detectado por lanzamientos muy frecuentes de nuevas versiones, pero confían más en los usuarios que ellos mismos notificarán los paquetes sospechosos.

"Sin duda, si muchos usuarios intentan publicar masivamente paquetes maliciosos en concierto, estarán disponibles en el registro de NPM", dijo el blog.

Confía pero verifica

Serán unos días difíciles para NPM. La identificación de paquetes maliciosos publicados es su "talón de Aquiles". En el debate actual sobre el tema de la regulación por parte del gerente de los paquetes eliminados del registro. La eliminación por parte del desarrollador de un paquete de NPM la semana pasada, rompiendo así muchos proyectos que dependen de él. También es bastante sencillo registrar su código con el nombre del módulo remoto. Cualquiera que haya asignado el nombre de otra persona puede configurar el código a cualquier usuario, que depende del original.

En los últimos días, Reddit y GitHub han estado discutiendo mucho sobre la confianza en los desarrolladores, el soporte de los paquetes que crearon y si comenzarán a crear código malicioso. En el ecosistema global, esta es una suposición peligrosa, porque si uno de esos desarrolladores quiere romper mucho código, tendrá que confrontar a toda la comunidad. Sin embargo, debe haber formas de instalar módulos de forma segura, puede ser una firma digital u otros métodos para verificar la seguridad y la corrección del código. Mientras tanto, solo queda sentir la alarma cada vez que ejecuta el comando `npm install`.

Artículo original: www.infoworld.com/article/3048526/security/nodejs-alert-google-engineer-finds-flaw-in-npm-scripts.html

Source: https://habr.com/ru/post/es392409/