Skip to main content

Qué es el typosquatting y cómo los ataques de typosquatting provocan la presencia de módulos maliciosos en npm

Escrito por
typosquatting attacks

12 de enero de 2021

0 minutos de lectura

Quizá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:

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:

Página de la base de datos de vulnerabilidades de Snyk que muestra una barra de búsqueda, filtros de paquetes y una lista de paquetes maliciosos de npm publicados el 17 de septiembre de 2017

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

Página de la base de datos de vulnerabilidades de Snyk que muestra una barra de búsqueda de vulnerabilidades, filtros de paquetes y una lista de paquetes npm maliciosos.

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:

babelcli: 42
cross-env.js: 43
crossenv: 679
d3.js: 72
fabric-js: 46
ffmepg: 44
gruntcli: 67
http-proxy.js: 41
jquery.js: 136
jquery.js: 136
mariadb: 92
mongose: 196
mssql-node: 46
mssql.js: 48
mysqljs: 77
node-fabric: 87
node-opencv: 94
node-opensl: 40
node-openssl: 29
node-sqlite: 61
node-tkinter: 39
nodecaffe: 40
nodefabric: 44
nodeffmpeg: 39
nodemailer-js: 40
nodemailer.js: 39
nodemssql: 44
noderequest: 40
nodesass: 66
nodesqlite: 45
opencv.js: 40
openssl.js: 43
proxy.js: 43
shadowsock: 40
smb: 40
sqlite.js: 48
sqliter: 45
sqlserver: 50
tkinter: 45

¿Cómo es un paquete malicioso como crossenv?

Para analizar el caso del paquete malicioso crossenv, empezaremos por el archivo package.json:

Fragmento de código que muestra la configuración de package.json del paquete cross-env, la versión 6.1.1, los scripts, el autor, la licencia y los detalles de las dependencias.

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.js y 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:

Código JavaScript que serializa variables de entorno y las envía en una solicitud POST a npm.hacktask.net/log.

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:

  1. ¿Qué información almacenamos en nuestras variables de entorno?

  2. ¿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?

  3. ¿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-scripts para 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.

Leer más

blog feature snyk container custom base recommendations
Blog

Presentamos Evo Agentic AppSec: seguridad al ritmo del desarrollo con IA

El desarrollo impulsado por IA supera el ritmo de los flujos de trabajo de seguridad tradicionales. Agentic AppSec de Snyk usa agentes de seguridad para encontrar, corregir y verificar vulnerabilidades de forma continua, mientras las personas definen el estándar.

blog feature ai violet
Blog

VulnBump: ¿Pueden los agentes de IA corregir dependencias vulnerables sin romper la compilación?

VulnBump prueba agentes de IA en 307 actualizaciones reales de dependencias. Una corrección cuenta solo si elimina la vulnerabilidad y mantiene en verde la compilación y las pruebas.

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.