Qu'est-ce que la confusion de dépendances ?

Comment fonctionne une attaque par confusion de dépendances

1. Trouver un nom interne. Les noms de paquets privés fuitent par le code public, les bundles JavaScript, les messages d'erreur et les manifestes laissés dans les dépôts.
2. Publier le même nom publiquement. L'attaquant l'enregistre sur npm, PyPI ou un autre registre public, avec un numéro de version très élevé.
3. Attendre un build. Un gestionnaire de paquets configuré pour consulter à la fois le registre interne et le registre public trouve deux candidats, et préfère la version la plus élevée.
4. S'exécuter dans l'entreprise. Le script d'installation du paquet s'exécute sur la machine d'un développeur ou sur un runner CI, avec accès à tout ce qui s'y trouve.

La recherche qui lui a donné son nom

En février 2021, le chercheur en sécurité Alex Birsan a publié la technique. Il s'en était servi pour exécuter du code au sein de plus de 35 organisations, dont Apple, Microsoft et PayPal, dans le cadre de programmes de bug bounty ou avec leur autorisation. Elle a fonctionné dans les trois langages qu'il a testés, et des attaquants ont commencé à la copier dans les jours qui ont suivi la publication.

Pourquoi cela se produit

La cause profonde est un gestionnaire de paquets qui traite plusieurs registres sur un pied d'égalité. L'exemple classique est Python : l'option --extra-index-url de pip ajoute une deuxième source à côté de PyPI, et pip peut installer le paquet public s'il en trouve un du même nom.

# Unsafe for private packages: both indexes are candidates
pip install --extra-index-url https://pypi.internal.example/simple my-internal-lib

# Safer: one index you control, which proxies public packages
pip install --index-url https://pypi.internal.example/simple my-internal-lib

npm a le même problème avec les noms internes sans scope, tandis qu'un scope lié à votre registre l'évite.

# .npmrc: everything under @acme comes only from your registry
@acme:registry=https://npm.internal.example/

Comment prévenir la confusion de dépendances

• Utilisez une source de vérité unique. Faites pointer les builds vers un seul registre interne qui sert de proxy aux paquets publics, et configurez-le pour que les noms internes ne soient jamais résolus publiquement.
• Utilisez des scopes ou des espaces de noms. Possédez un scope tel que @acme sur le registre public, et associez-le à votre registre privé.
• Réservez vos noms. Enregistrez vos noms de paquets internes sur les registres publics, afin que personne d'autre ne puisse le faire.
• Verrouillez et vérifiez. Commitez un lockfile et utilisez la vérification des hashs, comme --require-hashes de pip, afin qu'un paquet différent fasse échouer l'installation. Voir ce qu'un lockfile fait et ne fait pas.
• Limitez les destinations de connexion des builds. Si un build ne peut atteindre que votre registre, il ne peut pas du tout récupérer le paquet de l'attaquant. Voir la politique de trafic sortant GitHub Actions.
• Vérifiez ce qui fuite. Recherchez vos noms de paquets internes dans le code public et les bundles côté client.

Confusion de dépendances vs typosquatting

Le typosquatting repose sur une personne qui saisit mal le nom d'un paquet public. La confusion de dépendances utilise le nom exact d'un paquet privé et repose sur la configuration du build. Les deux mènent au même point : du code d'attaquant qui s'exécute dans votre build. Consultez qu'est-ce qu'une attaque de la chaîne d'approvisionnement pour voir comment elles s'inscrivent parmi les autres attaques.

Comment savoir si vous avez été touché

Recherchez les noms de paquets internes résolus depuis un registre public, ou les versions qui n'existent pas dans votre registre interne. C'est difficile à faire à partir d'un seul lockfile, car la question est de savoir d'où un paquet est réellement venu pendant le build.

Comment CRACI vous aide

CRACI agit au moment où le paquet est récupéré. En tant que runner GitHub Actions, il applique une politique de trafic sortant avec des sources typées pour les registres : un build peut ainsi être limité aux registres que vous autorisez. Il enregistre aussi chaque paquet récupéré par chaque job dans une SBOM : vous pouvez donc voir ce qui est entré dans un build. CRACI ne détecte pas qu'un paquet est malveillant : conservez donc la configuration de votre registre comme première ligne de défense. Consultez les bonnes pratiques de sécurité de la chaîne d'approvisionnement logicielle.

Confusion de dépendances : questions fréquentes

Qu'est-ce qu'une attaque par confusion de dépendances ?

Une attaque dans laquelle un paquet public portant le même nom qu'un paquet privé est installé par erreur, parce que le gestionnaire de paquets consulte les deux registres et préfère la version la plus élevée.

Quelle est la différence entre la confusion de dépendances et le typosquatting ?

Le typosquatting repose sur une personne qui saisit mal le nom d'un paquet public. La confusion de dépendances utilise le nom exact d'un paquet privé et repose sur une configuration de build qui consulte les registres publics.

Comment prévenir la confusion de dépendances ?

Utilisez un seul registre interne, des noms de paquets à scope, des lockfiles avec vérification des hashs et des règles qui limitent les registres que vos builds peuvent atteindre. Réserver publiquement vos noms internes aide aussi.

--extra-index-url est-il sûr ?

Pas pour les paquets privés. Il fait des deux index des candidats : un paquet public du même nom peut donc être installé. Utilisez --index-url avec un seul index que vous contrôlez.

Qui a découvert la confusion de dépendances ?

Le chercheur en sécurité Alex Birsan a publié la technique en février 2021, après l'avoir utilisée contre plus de 35 organisations dans le cadre de programmes de bug bounty ou avec leur autorisation.