Qué es el typosquatting y cómo los ataques de typosquatting provocan la presencia de módulos maliciosos en npm
12 de enero de 2021
0 minutos de lecturaQuizás hayas escuchado hablar de paquetes maliciosos en distintos contextos, como un contenedor Docker malicioso o un paquete malicioso de código abierto en un registro público de algún ecosistema. Snyk incluso publicó una investigación exhaustiva sobre malware en aplicaciones móviles, denominada SourMint.
En el pasado analizamos algunos de estos incidentes de seguridad, que abarcan más de un ecosistema:
Ejecución remota de código malicioso en los populares proyectos de gemas de Ruby bootstrap-sass y strong_password
Sin embargo, no todos los paquetes maliciosos son iguales y, en lo que respecta a los registros de los ecosistemas, podemos clasificarlos a grandes rasgos en una de las siguientes categorías:
Ataques de typosquatting: actores maliciosos publican paquetes maliciosos en un registro con la esperanza de engañar a los usuarios para que los instalen. Hemos visto este tipo de paquetes tanto en los registros de PyPI como de Node.js; el caso más notable es crossenv. Tenía un nombre similar al del popular paquete cross-env y envolvía la misma funcionalidad, pero también capturaba variables de entorno y las enviaba a un servidor remoto controlado por un atacante.
Cuentas comprometidas: es posible que los mantenedores de proyectos de código abierto no tengan necesariamente más conocimientos de seguridad que otros desarrolladores, lo que puede llevar a una gestión desafortunada e insegura de los secretos asociados con sus permisos de publicación. La situación se complica aún más cuando un proyecto tiene varios mantenedores y se deben aplicar las políticas del proyecto a todos los miembros. La falta de controles de autenticación adecuados en algunos registros también puede hacer que se comprometan cuentas. Sin embargo, las cuentas comprometidas pueden provocar graves incidentes de seguridad debido a la posible popularidad de los proyectos que mantienen y al efecto inmediato en ese ecosistema.
Ingeniería social en lugar de análisis del grafo de dependencias: el código abierto fomenta y acoge la colaboración. Sin embargo, mientras que una línea de código maliciosa en un pull request probablemente llame rápidamente la atención de muchas personas, la situación es distinta si se agrega una línea de código maliciosa a una dependencia de un proyecto.
Ataques de typosquatting
De los tipos de paquetes maliciosos y versiones publicados en repositorios que mencionamos antes, el typosquatting es uno de los más comunes, porque la barrera de entrada para los atacantes es muy baja y hay pocas medidas para contrarrestarlo.
¿Qué son los ataques de typosquatting?
Los ataques de typosquatting ocurren cuando actores maliciosos publican paquetes maliciosos en un registro con la esperanza de engañar a los usuarios para que los instalen. Los registros públicos de software, como npm o PyPI, son ejemplos de ecosistemas en los que ya hemos visto este tipo de intentos.
Esto es muy similar a los ataques de phishing en sitios web, que se aprovechan de los errores tipográficos de quienes pueden escribir por accidente una dirección incorrecta, como https://bankofamerca.com en lugar de https://bankofamerica.com. Si un atacante controlara el primer dominio, podría falsificar la apariencia de un sitio web para hacerse pasar por el verdadero y robar información financiera confidencial, como credenciales, cuentas bancarias y otros datos.
Ejemplos de módulos maliciosos producto del typosquatting que se encuentran en la base de datos de vulnerabilidades de Snyk, con casos que se remontan a 2017 y una serie de vulnerabilidades:

Y si crees que el typosquatting desapareció en 2020, piénsalo de nuevo:

La historia de crossenv
Un caso particularmente notable de ataque de typosquatting es crossenv. El atacante usó un nombre similar al del popular paquete cross-env e incluso envolvió exactamente la misma funcionalidad del módulo original para dar la impresión de que funcionaba como se esperaba. Sin embargo, en la práctica también capturaba variables de entorno y las enviaba a un servidor remoto controlado por un atacante.
El 19 de julio, el usuario de npm hacktask publicó crossenv como uno de más de 30 paquetes maliciosos que se usaron para robar variables de entorno de las víctimas que habían sido engañadas para instalarlos.
Como compartió C J Silverio en su blog, aquí está la lista completa de paquetes, junto con el total de descargas que tuvo cada uno durante el tiempo que estuvo disponible en el registro público de npm:
¿Cómo es un paquete malicioso como crossenv?
Para analizar el caso del paquete malicioso crossenv, empezaremos por el archivo package.json:

Veamos algunos aspectos que parecen fuera de lugar al revisar el archivo package.json:
Línea 2: el nombre del paquete es obviamente incorrecto, pero supongamos que pasó inadvertido.
Línea 13: incluye el paquete original cross-env, que, como puedes ver, también tiene una versión distinta (5.0.1) de la del módulo (6.1.1 en la línea 3).
Línea 8: aquí debería activarse la alerta de sospecha. ¿Qué contiene
package-setup.jsy qué tipo de configuración necesita este paquete?
Antes de profundizar en toda la historia detrás de node package-setup.js, hagamos una pausa y expliquemos por qué esa línea es tan importante. El script de ejecución llamado postinstall es uno de los hooks integrados del ciclo de vida de paquetes de npm y se ejecuta automáticamente cuando se instala un paquete.
Cualquier comando indicado en un script de ejecución postinstall se ejecutará como parte de una tarea npm install, independientemente de que hayas requerido el script en tu propio código o no.
Acto 1: la carga maliciosa del paquete de npm
A medida que avanzamos en la investigación y examinamos el contenido del archivo package-setup.js, se revela toda una trama maliciosa:

Como este script se ejecuta durante parte del proceso de instalación del paquete de npm, recopila todas las variables de entorno mediante process.env, las convierte en una carga codificada en base64 y las deja listas para enviarlas como una solicitud HTTP POST a un servidor remoto controlado por un atacante.
El acto malicioso se ejecuta una sola vez, durante la instalación. A partir de ese momento, el paquete crossenv sigue ofreciendo la funcionalidad para la que se instaló originalmente, al envolver el paquete real cross-env, por lo que pasa inadvertido.
Acto 2: reflexionemos sobre el impacto de los paquetes maliciosos
Es importante encontrar y dar a conocer esta vulnerabilidad de seguridad, pero no es suficiente. Para comprender el daño que podría haber causado y las consecuencias de sufrir este ataque, reflexionemos sobre algunas preguntas:
¿Qué información almacenamos en nuestras variables de entorno?
¿Qué habría pasado si un desarrollador hubiera integrado esto en una rama y se hubiera ejecutado en un servidor de CI? ¿Y qué ocurriría si luego se implementara en un servidor de producción?
¿Cómo te afectaría si el ataque no se limitara a leer las variables de entorno, sino que también llevara a cabo otras acciones maliciosas, como instalar puertas traseras, infectar entornos con gusanos autorreplicantes y provocar otras pesadillas similares?
Epílogo: ¿cómo descubrimos este paquete malicioso en npm?
Oscar Bolmsten, un ingeniero de software sueco, publicó un tuit sobre una posible actividad maliciosa del paquete crossenv. Al parecer, pasó inadvertida durante dos semanas:
https://twitter.com/o\_cee/status/892306836199800836?ref\_src=twsrc%5Etfw
¿Qué podemos hacer al respecto?
No almacenes información confidencial en variables de entorno.
Conecta tu repositorio a Snyk para que podamos monitorear las dependencias de tu proyecto a diario y avisarte si encontramos paquetes maliciosos u otras vulnerabilidades. Si encontramos una vulnerabilidad de seguridad que se pueda corregir, abriremos automáticamente un pull request (o merge request) en tu repositorio para solucionarla.
Consulta Snyk Advisor antes de instalar paquetes para conocer su estado general, popularidad, mantenimiento, seguridad y otras características.
Al instalar paquetes, usa la opción de la CLI de npm
--ignore-scriptspara evitar que se ejecuten scripts de paquetes de terceros durante la instalación.Considera usar npq para instalar paquetes de forma segura, ya que recopila información sobre su estado antes de que los instales.
Para conocer más prácticas recomendadas y consejos de seguridad para npm, te invito a echar un vistazo a la guía rápida de seguridad de npm.



