Ostorlab détecte la Dependency Confusion
La Dependency Confusion est une nouvelle attaque à fort impact en matière de sévérité. Cet article donne un aperçu de la vulnérabilité ainsi que d'autres attaques de la chaîne d'approvisionnement.
Alex Birsen a publié une recherche inédite montrant comment il pouvait compromettre des environnements de build, des pipelines CI/D et des postes de travail de développeurs en exploitant des noms de paquets privés divulgués.
Cette nouvelle vulnérabilité est une autre attaque de la chaîne d'approvisionnement, couramment appelée Dependency Confusion ou attaque par substitution.
La cause racine est liée aux systèmes externes de gestion de paquets, qui offrent généralement la possibilité de déployer des dépôts privés pour héberger des paquets à usage strictement interne.
Pendant le processus de build, le gestionnaire de paquets ne donne pas la priorité aux dépôts privés, mais à ceux qui ont la version la plus élevée.
Un attaquant peut tirer parti de ce comportement en créant un paquet malveillant sur le dépôt public avec un numéro de version suffisamment élevé pour garantir que ce soit le paquet malveillant qui soit utilisé au moment du build.
Sonatype a signalé avoir détecté une augmentation de 430 % du nombre de nouveaux paquets exploitant la vulnérabilité avec des payloads malveillants, dans les quelques jours suivant l'annonce de la vulnérabilité.
Le détournement de dépendances touche tous les types de logiciels, et en particulier les applications mobiles, car elles divulguent souvent des noms de paquets privés.
Ostorlab a ajouté la détection des noms de dépendances divulgués et signale ceux qui sont vulnérables à la Dependency Confusion sur NPM.
L'équipe d'Ostorlab étudie l'exploitabilité et la détectabilité de cette attaque sur d'autres gestionnaires de paquets, à savoir Cocoapods, Maven, Gradle, Cordova, Xamarin Nuget et Flutter.
Je suis vulnérable, que dois-je faire ?
Les paquets NPM offrent la possibilité de définir un scope. Les paquets avec scope sur le registre npm public ne peuvent être publiés que par l'utilisateur ou l'organisation qui y est associé, et les paquets de ce scope peuvent être rendus privés. De plus, les noms de scope peuvent être liés à un registre donné.
{
"name": "@ostorlab/dep1",
"version": "1.2.3",
"description": "Scoped dependency 1",
"dependencies": {
"@ostorlab/dep2": "1.2.3"
}
}
Le scope utilisé doit être créé au préalable pour garantir qu'un attaquant ne puisse pas le prendre. Pour créer un scope public, suivez les instructions suivantes :
Le registre associé au scope peut être configuré en incluant une ligne similaire dans le fichier .npmrc :
@ostorlab:registry = https://reg.ostorlab.internal/
Plus de dépendances, plus de vulnérabilités
Ostorlab détecte d'autres formes de vulnérabilités de la chaîne d'approvisionnement et des dépendances.
Il liste les dépendances compilées de Gradle, Maven, Cocoapods, Xamarin, Cordova et Javascript. Lister les dépendances compilées pallie les limites des dépendances du code source, comme l'identification des dépendances transitives : ce sont les dépendances des dépendances, dont certaines versions ne sont pas explicites et ne sont déterminées qu'au moment du build.
Ostorlab détecte les dépendances compilées statiquement, souvent exposées à des vulnérabilités de sévérité élevée, comme la corruption de mémoire. Pour les applications mobiles, les dépendances courantes sont des bibliothèques d'analyse et de compression d'images, comme libpng, libjpeg et libtiff. Ostorlab peut aussi détecter plus de 70 bibliothèques natives comme libxslt, zlib, openssl, libcurl et bien d'autres.
Ostorlab peut détecter les vulnérabilités connues affectant ces paquets et maintient sa propre base de données sélectionnée de vulnérabilités non signalées. La base de données de vulnérabilités d'Ostorlab contient 1,3 million d'entrées et est mise à jour en continu.
Toutes ces classes de vulnérabilités sont couvertes par le scanner communautaire.