Las vulnerabilidades de ReDoS en npm aumentan un 143% y el XSS sigue creciendo

Te damos la bienvenida al informe anual de Snyk sobre el estado de la seguridad del código abierto de 2019. Este informe se divide en varias publicaciones:

• Los paquetes de Maven Central se duplican; se indexa un cuarto de millón de paquetes nuevos en npm

• Las vulnerabilidades en bibliotecas de aplicaciones aumentan un 88% en dos años

• El 81% cree que los desarrolladores deberían hacerse cargo de la seguridad, pero no cuentan con las herramientas adecuadas

• Los responsables del mantenimiento del código abierto quieren protegerlo, pero al 70% le faltan conocimientos

• Las diez imágenes de Docker más populares contienen al menos 30 vulnerabilidades cada una

• Las vulnerabilidades de ReDoS en npm aumentan un 143% y el XSS sigue creciendo

• El 78% de las vulnerabilidades se encuentra en dependencias indirectas, lo que complica su corrección

También puedes descargar nuestro atractivo informe en PDF, elaborado a mano, que reúne toda esta información y mucho más.

Descarga el informe de 2019 sobre el estado de la seguridad del código abierto

Denegación de servicio mediante expresiones regulares

El entorno de ejecución de Node.js tiene muchas fortalezas, pero una de ellas —el bucle de eventos de un solo hilo— también puede ser su punto más débil si no se usa correctamente. Esto sucede con más frecuencia de lo que podrías pensar.

Los ataques de denegación de servicio mediante expresiones regulares (ReDoS) aprovechan las vulnerabilidades de complejidad no lineal en el peor de los casos que pueden provocar algunos patrones regex. Esto puede ser devastador para un entorno de ejecución de un solo hilo y es la razón por la que Node.js se ve considerablemente afectado por este tipo de vulnerabilidad.

Descubrimos que las vulnerabilidades de ReDoS divulgadas aumentaron durante los últimos tres años, con un incremento del 143% solo en 2018.

Vulnerabilidades de XSS

Los ataques de cross-site scripting (XSS) son un problema cada vez mayor para las aplicaciones web, y observamos que las vulnerabilidades de XSS se dispararon en 2018 en todos los ecosistemas que Snyk monitorea. 

Las vulnerabilidades de XSS en bibliotecas de código abierto siguen aumentando, pese a ser una de las principales preocupaciones de OWASP desde hace más de 15 años

En estos ecosistemas, detectamos que npm registró la mayor cantidad de vulnerabilidades de XSS, con 225 en total; le siguieron el repositorio Maven Central, con 167, y PyPI, con 163 vulnerabilidades de cross-site scripting en total. En 2018, el ecosistema PHP Packagist divulgó la mayor cantidad, con 56 vulnerabilidades de XSS, seguido de npm, con 54, y Maven Central, con 29.

Recorrido de directorios

Las vulnerabilidades de recorrido de rutas y directorios sobresalen en el ecosistema npm, con cifras récord de 146 y 143 divulgaciones en 2017 y 2018, respectivamente. Los demás ecosistemas están muy por detrás, ¡lo cual es una buena noticia!

Podría suponerse que esto se debe a la gran cantidad de servidores web estáticos y dinámicos creados con Node.js para entornos de producción y desarrollo, por lo que hay muchos más paquetes donde también podrían encontrarse estas vulnerabilidades.

Vulnerabilidades de inyección SQL

Otro vector de ataque común que aparece constantemente en la lista de los 10 principales riesgos de OWASP desde hace una década es CWE-89, más conocido como inyección SQL.

Al analizar los últimos tres años, vemos que cada uno de los tres principales ecosistemas que revisamos tuvo su pico en un año distinto. Las bibliotecas de Maven encabezaron la cantidad de vulnerabilidades de inyección SQL divulgadas en 2016 y 2017; las bibliotecas de PHP Packagist ocuparon el primer lugar en 2018.

Exposición de información confidencial

Al analizar los registros Maven Central y PHP Packagist, descubrimos que tenían la mayor cantidad de vulnerabilidades relacionadas con la exposición de información, con un pico en 2018 en ambos ecosistemas.

La exposición de información suele ocurrir sin querer. Se produce cuando un programa o sistema divulga información potencialmente confidencial, como nombres y valores de variables de entorno. También puede ocurrir «por diseño», por ejemplo, cuando se incluyen datos confidenciales en los parámetros de una URL.

Algunos ejemplos de vulnerabilidades de exposición de información en el registro Maven Central son los paquetes apache spark, jenkins core y keyclock-saml-core. Por ejemplo, el complemento de CI jenkins ssh-agent filtró la clave privada SSH en los registros de compilación, donde podía verla cualquier persona con permisos de lectura.

El registro PyPI también tiene una cantidad considerable de vulnerabilidades en bibliotecas, incluidas vulnerabilidades de exposición de información. Paquetes como django mostraban el hash de la contraseña de un usuario a usuarios administradores que solo tenían permisos de visualización. El paquete djangorestframework-api-key guardaba las claves de API en texto sin cifrar.

Transmisión de información confidencial en texto sin cifrar

Por último, otra vulnerabilidad particular que vale la pena mencionar en el ecosistema npm es CWE-319, también conocida como transmisión de información confidencial en texto sin cifrar, que ocurre cuando se accede a recursos mediante protocolos inseguros. Encontramos 44 nuevas vulnerabilidades divulgadas en paquetes de 2016; esta cifra aumentó a un total considerable de 110 paquetes en 2017, un incremento del 250%. 

En primer plano: paquetes maliciosos

Es posible que hayas oído hablar de paquetes maliciosos en distintos contextos, como un contenedor Docker malicioso o un paquete malicioso en un registro público de algún ecosistema. También hemos hablado en otros contextos sobre los desarrolladores como medio para distribuir malware, como el malware Induc, que infectó compiladores Delphi, y XCodeGhost, que apuntó a desarrolladores de iOS y OS X.

Sin embargo, no todos los paquetes maliciosos son iguales. En el caso de los registros de ecosistemas, podemos clasificarlos, en términos generales, de la siguiente manera:

• un ataque de typosquatting en el que un paquete malicioso usa un nombre muy parecido al de un paquete más popular

• la vulneración de la cuenta de CI o del registro de un responsable de mantenimiento, que da lugar a la publicación de una versión maliciosa, o un paquete malicioso alojado en la lista de dependencias de un proyecto

• la inclusión de un paquete malicioso (o que se volverá malicioso después de incluirse) en la lista de dependencias de un proyecto mediante ingeniería social

En 2018 observamos todos estos tipos de paquetes maliciosos en el ecosistema npm, conocido por ser uno de los registros más afectados por paquetes maliciosos. El paquete que apareció en las noticias en diciembre de 2018 fue event-stream. Dependía de una dependencia maliciosa que se incorporó mediante un aparente intento inofensivo de contribuir a un proyecto de código abierto.

Este ataque afectó a la asombrosa cifra de 8 millones de descargas del paquete malicioso en solo dos meses. Otro ejemplo de 2018 es el paquete ESLint-scope, cuya cuenta de responsable de mantenimiento fue vulnerada. También observamos un total de 11 ataques de typosquatting para publicar paquetes maliciosos en el registro npm durante 2018. 

En 2018, un paquete malicioso alcanzó la cifra récord de 8 millones de descargas. Fue uno de los 25 ataques de typosquatting en npm y PyPI

Además de los intentos habituales de typosquatting que habíamos visto en el pasado, también observamos intentos de ataque más sofisticados contra el ecosistema npm que en años anteriores, como el ataque a ESLint-scope. El incidente de event-stream, mucho más sofisticado, reveló un alto nivel de experiencia y ataques dirigidos, algo que no habíamos visto hasta entonces en otros intentos maliciosos dentro del ecosistema.

A diferencia del registro npm, los únicos otros registros donde identificamos paquetes maliciosos fueron RubyGems, con un solo paquete malicioso en 2018, y Python, con diez paquetes maliciosos en 2017 y trece en 2018.

Sigue leyendo:

• Los paquetes de Maven Central se duplican; se indexa un cuarto de millón de paquetes nuevos en npm

• Las vulnerabilidades en bibliotecas de aplicaciones aumentan un 88% en dos años

• El 81% cree que los desarrolladores deberían hacerse cargo de la seguridad, pero no cuentan con las herramientas adecuadas

• Los responsables del mantenimiento del código abierto quieren protegerlo, pero al 70% le faltan conocimientos

• Las diez imágenes de Docker más populares contienen al menos 30 vulnerabilidades cada una

• Las vulnerabilidades de ReDoS en npm aumentan un 143% y el XSS sigue creciendo

• El 78% de las vulnerabilidades se encuentra en dependencias indirectas, lo que complica su corrección