Ostorlab detecta Dependency Confusion
Dependency Confusion es un nuevo ataque con un impacto de severidad alta. Este artículo ofrece una visión general de la vulnerabilidad, así como de otros ataques a la cadena de suministro.
Alex Birsen publicó una investigación novedosa que muestra cómo logró comprometer entornos de compilación, pipelines de CI/D y estaciones de trabajo de desarrolladores aprovechando nombres de paquetes privados filtrados.
La nueva vulnerabilidad es otro ataque a la cadena de suministro, conocido comúnmente como Dependency Confusion o ataque de sustitución.
La causa raíz está vinculada a los sistemas externos de gestión de paquetes, que normalmente ofrecen la posibilidad de desplegar repositorios privados para alojar paquetes de uso exclusivamente interno.
Durante el proceso de compilación, el gestor de paquetes no prioriza los repositorios privados, sino los que tienen la versión más alta.
Un atacante puede aprovechar este comportamiento creando un paquete malicioso en el repositorio público y usando una versión lo bastante alta para asegurarse de que el paquete malicioso sea el que se utilice en el momento de la compilación.
Sonatype ha informado de que detectó un aumento del 430% en los nuevos paquetes que explotan la vulnerabilidad con payloads maliciosos a los pocos días del anuncio de la vulnerabilidad.
El secuestro de dependencias afecta a todo tipo de software y, en particular, a las aplicaciones móviles, ya que con frecuencia filtran nombres de paquetes privados.
Ostorlab ha añadido compatibilidad para detectar nombres de dependencias filtrados e informa de las que son vulnerables a Dependency Confusion en NPM.
El equipo de Ostorlab está investigando la explotabilidad y la detectabilidad en otros gestores de paquetes, concretamente Cocoapods, Maven, Gradle, Cordova, Xamarin Nuget y Flutter.
Soy vulnerable, ¿qué debo hacer?
Los paquetes NPM ofrecen la posibilidad de definir un ámbito (scope) para los paquetes. Los paquetes con ámbito en el registro público de npm solo pueden ser publicados por el usuario o la organización asociados a él, y los paquetes dentro de ese ámbito pueden hacerse privados. Además, los nombres de ámbito pueden vincularse a un registro determinado.
{
"name": "@ostorlab/dep1",
"version": "1.2.3",
"description": "Scoped dependency 1",
"dependencies": {
"@ostorlab/dep2": "1.2.3"
}
}
El ámbito que se utilice debe crearse de antemano para asegurarse de que un atacante no pueda apropiarse de él. Para crear un ámbito público, siga las siguientes instrucciones:
El registro con ámbito puede configurarse incluyendo una línea similar en el archivo .npmrc:
@ostorlab:registry = https://reg.ostorlab.internal/
Más dependencias, más vulnerabilidades
Ostorlab detecta otras formas de vulnerabilidades en la cadena de suministro y en las dependencias.
Enumera las dependencias compiladas de Gradle, Maven, Cocoapods, Xamarin, Cordova y Javascript. Enumerar las dependencias compiladas supera las limitaciones de las dependencias del código fuente, como la identificación de dependencias transitivas: son las dependencias de las dependencias, y algunas de sus versiones no son explícitas y solo se determinan en el momento de la compilación.
Ostorlab detecta dependencias compiladas de forma estática, que suelen ser vulnerables a vulnerabilidades de severidad alta, como la corrupción de memoria. En las aplicaciones móviles, las dependencias habituales son las bibliotecas de análisis y compresión de imágenes, como libpng, libjpeg y libtiff. Ostorlab también puede detectar más de 70 bibliotecas nativas como libxslt, zlib, openssl, libcurl y muchas más.
Ostorlab puede detectar las vulnerabilidades conocidas que afectan a estos paquetes y mantiene su propia base de datos depurada de vulnerabilidades no reportadas. La base de datos de vulnerabilidades de Ostorlab contiene 1.3 millones de entradas y se actualiza continuamente.
Estas clases de vulnerabilidades están cubiertas por el escáner de la comunidad.