Hvad er dependency confusion?

Sådan virker et dependency confusion-angreb

1. Find et internt navn. Private pakkenavne siver ud gennem offentlig kode, JavaScript-bundles, fejlmeddelelser og manifester efterladt i repositories.
2. Offentliggør samme navn. Angriberen registrerer det på npm, PyPI eller et andet offentligt registry med et meget højt versionsnummer.
3. Vent på et build. En pakkehåndtering, der er sat op til at tjekke både det interne og det offentlige registry, finder to kandidater og foretrækker den højeste version.
4. Kør inde i virksomheden. Pakkens install-script kører på en udviklers maskine eller en CI-runner med adgang til det, der ligger der.

Forskningen, der gav det navnet

I februar 2021 offentliggjorde sikkerhedsforskeren Alex Birsan teknikken. Han havde brugt den til at få kode til at køre hos over 35 organisationer, herunder Apple, Microsoft og PayPal, under bug bounty-programmer eller med tilladelse. Den virkede i alle tre sprog, han testede, og angribere begyndte at kopiere den få dage efter offentliggørelsen.

Derfor sker det

Grundårsagen er en pakkehåndtering, der behandler flere registries som ligeværdige. Det klassiske eksempel er Python: pips --extra-index-url tilføjer en ekstra kilde ved siden af PyPI, og pip kan installere den offentlige pakke, hvis den finder en med samme navn.

# 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 har samme problem med interne navne uden scope, mens et scope knyttet til dit registry undgår det.

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

Sådan forebygger du dependency confusion

• Brug én sandhedskilde. Peg builds på ét internt registry, der proxyer offentlige pakker, og konfigurér det, så interne navne aldrig resolves offentligt.
• Brug scopes eller namespaces. Sørg for at eje et scope som @acme i det offentlige registry, og map det til dit private.
• Reservér dine navne. Registrér interne pakkenavne i offentlige registries, så ingen andre kan.
• Lås og verificér. Commit en lockfile, og brug hash-tjek, for eksempel pips --require-hashes, så en anden pakke får installationen til at fejle. Se hvad en lockfile gør og ikke gør.
• Begræns, hvor builds kan oprette forbindelse til. Hvis et build kun kan nå dit registry, kan det slet ikke hente angriberens pakke. Se egress-politik for GitHub Actions.
• Tjek, hvad du lækker. Søg i offentlig kode og klient-bundles efter dine interne pakkenavne.

Dependency confusion vs. typosquatting

Typosquatting bygger på, at en person staver et offentligt pakkenavn forkert. Dependency confusion bruger det præcise navn på en privat pakke og bygger på, hvordan buildet er konfigureret. Begge ender samme sted: angriberkode, der kører i dit build. Se hvad er et forsyningskædeangreb for, hvordan de passer sammen med andre angreb.

Sådan finder du ud af, om du blev ramt

Kig efter interne pakkenavne, der blev resolvet fra et offentligt registry, eller versioner, der ikke findes i dit interne. Det er svært at gøre ud fra en lockfile alene, fordi spørgsmålet er, hvor en pakke faktisk kom fra under buildet.

Sådan hjælper CRACI

CRACI arbejder dér, hvor pakken hentes. Som din GitHub Actions-runner håndhæver det en egress-politik med typede kilder for registries, så et build kan begrænses til de registries, du tillader. Det registrerer også hver pakke, hvert job hentede, i en SBOM, så du kan se, hvad der kom ind i et build. CRACI opdager ikke, at en pakke er ondsindet, så behold din registry-konfiguration som første forsvarslinje. Se bedste praksis for forsyningskædesikkerhed for software.

Dependency confusion: ofte stillede spørgsmål

Hvad er et dependency confusion-angreb?

Et angreb, hvor en offentlig pakke med samme navn som en privat bliver installeret ved en fejl, fordi pakkehåndteringen tjekker begge registries og foretrækker den højeste version.

Hvordan adskiller dependency confusion sig fra typosquatting?

Typosquatting bygger på, at nogen staver et offentligt pakkenavn forkert. Dependency confusion bruger det præcise navn på en privat pakke og bygger på en build-konfiguration, der tjekker offentlige registries.

Hvordan forebygger du dependency confusion?

Brug ét internt registry, pakkenavne med scope, lockfiles med hash-tjek og regler, der begrænser, hvilke registries dine builds kan nå. Det hjælper også at reservere dine interne navne offentligt.

Er --extra-index-url sikker?

Ikke til private pakker. Den gør begge indekser til kandidater, så en offentlig pakke med samme navn kan blive installeret. Brug --index-url med ét indeks, du selv kontrollerer.

Hvem opdagede dependency confusion?

Sikkerhedsforskeren Alex Birsan offentliggjorde teknikken i februar 2021 efter at have brugt den mod over 35 organisationer under bug bounty-programmer eller med tilladelse.