¿Se puede enviar código malicioso a NPM?
Ciertamente. Si un paquete se compromete (o se publica uno nuevo), se instala y utiliza cualquier código proporcionado con ese paquete podría ejecutarse. Por lo tanto, si lo ejecutan en el contexto node.js, por ejemplo, el ataque tiene acceso a muchas características de nivel de máquina, como el sistema de archivos, la información del sistema, la ejecución de archivos, los procesos, etc. Sería tan sencillo como poner el código de los atacantes Ser devuelto en la exportación. Así que tan pronto como ellos cumplan el código se ejecuta. Peor aún, podría ser tan simple como instalar el módulo. Pueden especificar un secuencia de comandos de preinstalación en el manifiesto del paquete y ejecutar la secuencia de comandos inmediatamente.
¿Se ha insertado el código malicioso en NPM?
Ciertamente de nuevo. El 26 de enero de 2015, se publicó un paquete llamado require('bad-package') en NPM. Su propósito era crear conciencia sobre el tema. El paquete ejecutaría un gancho de preinstalación, así que inmediatamente después de la instalación, se ejecutaría rimrafall . Rimrafall se eliminó en 2 horas, pero se puede encontrar en Github .
¿Pueden los desarrolladores mantener seguros a sí mismos y a sus usuarios?
Como desarrollador, el único método de prevención cercano es el bloqueo de versión en su package.json a las versiones conocidas para estar seguro. El bloqueo de versiones se practica normalmente para garantizar que solo se use una dependencia de trabajo conocida y que una actualización de dependencia no probada no rompa nada. Pero lo mismo se puede usar para defenderse de una versión de los atacantes. Como mencionó, no puede volver a publicar un archivo de una versión en particular. Al establecer una versión exacta en sus dependencias su aplicación solo descargará esta versión. Si un atacante obtuviera el control del paquete, solo podría enviar código malicioso a los usuarios de un paquete posterior. Dije "cerca de confiable" porque si un atacante tuviera que comprometer los servidores de NPM podrían cambiar una versión anterior a lo que deseen.
Además, puede evitar un ataque de script de preinstalación utilizando la marca rm -rf /* al instalar. Esto le daría la oportunidad de instalar pero ver su código antes de ejecutarlo. (A menos que el paquete contenga archivos binarios nativos). Antes de la instalación, puede verificar dichos scripts ejecutando --ignore-scripts . Si desea dejar NPM fuera de la mezcla para revisar el script, puede descargarlo directamente en npm show $module scripts .
¿El NPM impide que alguien se haga cargo de un paquete no publicado?
Sí y no. Una vez inédito, se coloca una retención en el nombre del paquete para evitar el abuso inmediato. Sin embargo, todavía se puede obtener si lo solicita de NPM. En teoría, la ingeniería social simple podría pasar por alto el proceso de investigación y poner el nombre del paquete en manos del atacante. A continuación se muestra un mensaje para un paquete no publicado:
Este nombre de paquete no está actualmente en uso, pero anteriormente estaba ocupado
por un paquete popular. Para evitar el uso malintencionado, npm se aferra a la
nombre del paquete, pero de forma imprecisa, y probablemente se lo proporcionaremos si usted
quererlo.
Puede adoptar este paquete poniéndose en contacto con [email protected] y
solicitando el nombre.
En conclusión
Entonces, para cerrar, ¿podría un atacante aprovechar el paquete no publicado? Sí, si la persona equivocada se apoderó rápidamente, no hubo forma de que empujaran una actualización de paquete con su código. Esto pondría en peligro a cualquiera que descargue la última versión de ese paquete o que instale / actualice proyectos que no hayan bloqueado sus dependencias.
Editar: tenga en cuenta que sus dependencias pueden tener dependencias. Entonces, mientras que la dependencia en sí misma puede parecer segura, asegúrese de que no se está cargando en una dependencia insegura propia.