Aller au contenu
Sécurité medium

Dependency confusion (A. Birsan)

3 min de lecture
Point de compromission dans la chaîne Rupture · étape Dépendances
Source
amont
Dépendances
Dépendances
Build & CI
ci
Packaging
artefact
Release
provenance
Registres
distribution
Déploiement
admission
Runtime
exécution
Rayon d'explosion — compromission à l'étape Dépendances, propagation possible aux consommateurs. Domaines : Intégration
Gravité faible
Des noms de paquets internes résolus vers le registre public permettent de substituer une dépendance attaquante ; démontré chez des dizaines de grandes entreprises.
2021
démo (A. Birsan)
dizaines
entreprises touchées
0 compte
compromis nécessaire
version+
supérieure = priorité

En bref

Date
09/02/2021
Gravité
Faible
Étape de la chaîne
Dépendances
Domaines SOCLE
Intégration

Que s'est-il passé ?

Contexte

En 2021, le chercheur Alex Birsan démontre la confusion de dépendances, une technique de substitution exploitant la résolution de noms de certains gestionnaires de paquets.

Mécanisme

De nombreuses organisations utilisent des paquets internes dont les noms ne sont pas réservés sur les registres publics. En publiant sur le registre public des paquets de même nom avec une version supérieure, Birsan fait tirer automatiquement la version publique attaquante au lieu de l'interne.

Impact

Sans compte compromis ni paquet détourné, le code s'exécute chez des dizaines de grandes entreprises : une faille systémique de la consommation d'OSS. La technique a depuis engendré des milliers de paquets opportunistes sur npm et PyPI.

Parades

Router l'ingestion OSS via un proxy ou miroir interne à liste d'autorisation, réserver les noms internes sur les registres publics, épingler sources et versions, et garantir une résolution non ambiguë privilégiant l'interne.

Chronologie de l'attaque

2021
Démonstration de la technique

Alex Birsan publie des paquets publics homonymes de paquets internes avec une version supérieure, exécutant son code chez des dizaines de grandes entreprises.

Comment l'attaquant a procédé

Cet incident met en jeu les vecteurs d'attaque suivants du catalogue SOCLE ; chacun renvoie à sa fiche, où l'on trouve les exigences qui le neutralisent :

La leçon à en tirer

Ce qu'il faut retenir

Proxy/miroir interne avec allowlist ; réservation des noms internes ; résolution non ambiguë des sources.

Les exigences SOCLE qui auraient limité cet incident

Cet incident se rattache à 4 exigences du référentiel, par domaine. Les satisfaire n'aurait pas forcément tout empêché, mais aurait réduit la probabilité de l'attaque, limité son impact ou accéléré sa détection :

Pour aller plus loin

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracing. Aujourd'hui, ce site ne couvre même pas mes frais d'hébergement, d'électricité, de matériel, de logiciels, mais surtout de cafés.

Un soutien régulier, même symbolique, m'aide à garder ces ressources gratuites et à continuer de produire des guides de qualité. Merci pour votre appui.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn