security credentials – Hack de ESLint reciente o ¿cómo podemos protegernos de la instalación de paquetes npm maliciosos?

Pregunta:

Recientemente, los eslint-scope y eslint-config-eslint fueron pirateados de una manera interesante : una de las cuentas del mantenedor fue comprometida por un atacante y se publicó una nueva versión de "parche" con el código malicioso en el registro de npm.

Este código malicioso se ejecutó como un script "posterior a la instalación" e intentó evaluar un cierto código JS de un sitio pastebin y robar el token de autenticación npm de un archivo npmrc local enviándolo a los histats y los puntos finales de statcounter dentro del encabezado Referer . Se pueden encontrar más detalles del ataque aquí . Curiosamente, este problema se descubrió debido al error de sintaxis que aparece en la implementación del código malicioso.

Teniendo en cuenta que el equipo de ESLint tardó unas horas en abordar el problema, se robaron muchos tokens de autenticación de npm, lo que significa que otros paquetes pueden contaminarse de la misma manera en el futuro.

¿Cómo podríamos, como usuarios de npm, protegernos de futuros ataques similares al instalar dependencias desde el registro de npm?

Respuesta:

Tres palabras: Gestión de la cadena de suministro . Excepto que en nuestro caso el "suministro" es dependencia o "bibliotecas de terceros".

Este no es un problema exclusivo de npm. Este es un problema general en el desarrollo de software. Es el equivalente a buscar en Google un fabricante de "tornillos", luego use el primer fabricante de "tornillos" que vea, no pregunte acerca de las especificaciones de los "tornillos", luego use estos "tornillos" y espere que hagan lo funciona bien y no se rompe, se erosiona / oxida demasiado rápido y puede soportar la tensión … sin haber verificado si esos tornillos han sido probados, tenga un control de calidad adecuado. Podemos hacer esto porque, por lo general, nadie muere si su software tiene errores o es vulnerable. Si una estructura colapsa porque el tornillo tiene errores … esa es una historia diferente. Ahí hay responsabilidad. No existe tal responsabilidad en el software … excepto cuando trabajas en algunas industrias donde las vidas están realmente en juego cuando ocurren errores de software o cuando una maquinaria enorme y costosa se rompe (y / o luego pone en peligro vidas) si tu software de control tiene errores. . Y lo digo en serio. No puede simplemente usar una biblioteca de terceros sin una verificación rigurosa en un dispositivo integrado que controle máquinas peligrosas si debe poder mantener la comunicación en tiempo real para controlar algún proceso en tiempo real y todo se dispara si la biblioteca de terceros que usa produce un Fallo de CPU porque tiene errores … porque entonces su máquina se dañará de verdad.

El problema con el desarrollo de software es que "buscamos en Google" "alguna biblioteca" que proporcione "alguna funcionalidad" y luego simplemente "npm install", "go get", "pip install" y estamos contentos. No hay proceso de verificación ahí. ¿Cómo sabe que el paquete proporciona lo que dice? ¿Sabes lo bien probado que está? ¿Sabes si todavía se mantiene activamente? ¿Sabes cuáles son las garantías de estabilidad de la API? Puede "ir a buscar" algún paquete y el paquete se rompe por completo una semana después porque incluso el código "oficial" que parece ir puede no tener ninguna garantía de estabilidad de la API.

¿Qué restricciones de versión usas? foo >= 1.5 . ¿Qué pasa si foo >= 1.6 introduce una puerta trasera? Alguien que compile su código con las versiones más recientes tendrá esta puerta trasera. ¿Qué pasa si usa foo == 1.5 pero hay diferentes espejos y el espejo que usa su colega para construir su software contiene una versión maliciosa del paquete? Y no olvide: ¿Si instala / usa un paquete / biblioteca? No solo necesita verificar ese paquete / biblioteca … debe verificar todo el árbol de dependencias .

Lo que necesitaríamos es un proceso de certificación. Una vez que una empresa / desarrollador cree que su paquete está listo, lo publica y luego las empresas independientes de revisión de código y seguridad revisan el paquete y una vez que hay un grado razonable de confianza de que este paquete es "seguro" de usar, lo firman. Entonces solo se le permite usar dependencias que están firmadas y usa hash además de versiones como foo == ("1.5", "abc734defef373f..") .

¿Cómo se aplica esto a npm?

No instale paquetes npm sin revisarlos. Quien es el autor ¿Cuál es la calidad general del código? ¿Cuándo se actualizó por última vez? ¿Cuáles fueron las últimas confirmaciones? ¿Qué hace su instalación? ¿Tiene las pruebas adecuadas? ¿Cuál es la cobertura del código / prueba? ¿Cuántas personas lo están usando? ¿Quién lo está usando?

El desarrollo de software se centra en proporcionar actualizaciones, cosas nuevas, actualizaciones, cosas nuevas. Las pruebas adecuadas y la adecuada "gestión de códigos de terceros" cuestan MUCHO y, por lo general, ni las empresas ni los consumidores están dispuestos a pagar ese precio. Después de todo, siempre es "riesgo vs costo". Si el costo de una vulnerabilidad de seguridad es que algunos usuarios han robado sus credenciales … a nadie le importa. No pueden demandarte … en el peor de los casos, te cuesta un poco en "imagen pública". Si lo peor es un software con errores que no funciona para algunos usuarios … puede permitirse el lujo de algunos usuarios enojados que estaban usando la versión gratuita de todos modos … Esto probablemente cambiaría si existiera algo como "garantía" para el software y la responsabilidad por los errores de software (que existe un poco para cuando le pagas a alguien para que escriba algo para ti), pero dado que una gran cantidad de software es de código abierto, viene con exactamente cero garantías / garantías (eso es en realidad un gran inconveniente de esto) o es software que está utilizando de forma gratuita, esto simplemente no sucederá para ese tipo de software.

Este problema también existe por el uso de javascript de terceros en su sitio web. La misma cosa. Los problemas son casi completamente los mismos independientemente del idioma, los marcos o la tecnología que utilice: si quiere estar seguro … necesita verificar el código de terceros.

Otra cosa:

Hay paquetes / bibliotecas que brindan solo una pequeña utilidad … cosas que podría haber escrito usted mismo en 3 horas … tal vez en un día. Esto no es un problema si no le importan más dependencias (y más dependencias complican su gestión de dependencias) pero si lo hace … a veces es menos esfuerzo simplemente no usar bibliotecas tan simples y escribir la funcionalidad usted mismo para que tiene control total sobre él y puede probarlo correctamente. La regla general es que si le toma más tiempo verificar el código de otra persona que escribirlo usted mismo … entonces escríbalo usted mismo. Esto también se aplica si solo necesita una o dos funciones de un marco completo. Es mucho más fácil verificar correctamente sus dos versiones de alguna función en lugar de incluir y verificar un marco completo porque los marcos en sí mismos tienen dependencias y tendrá que verificarlas también.

Aparte de eso: … podría bloquear el tráfico a sitios web que no están en la lista blanca durante el proceso de instalación, lo que significa que este ataque exactamente específico no funcionaría, pero eso no funciona contra scripts de instalación maliciosos que simplemente eliminan archivos aleatorios o insertan puertas traseras en archivos existentes o lo que sea. Deberá leer detenidamente los scripts de instalación.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım