Hva er dependency confusion?

Slik fungerer et dependency confusion-angrep

1. Finner et internt navn. Private pakkenavn lekker gjennom offentlig kode, JavaScript-bundles, feilmeldinger og manifester som er lagt igjen i repositorier.
2. Publiserer samme navn offentlig. Angriperen registrerer det på npm, PyPI eller et annet offentlig register, med et svært høyt versjonsnummer.
3. Venter på et bygg. En pakkebehandler som er satt opp til å sjekke både det interne og det offentlige registeret, finner to kandidater og foretrekker den høyeste versjonen.
4. Kjører inne i selskapet. Installasjonsskriptet til pakken kjører på en utviklers maskin eller en CI-runner, med tilgang til det som måtte være der.

Forskningen som ga det navn

I februar 2021 publiserte sikkerhetsforskeren Alex Birsan teknikken. Han hadde brukt den til å få kode til å kjøre inne i mer enn 35 organisasjoner, blant dem Apple, Microsoft og PayPal, under bug bounty-programmer eller med tillatelse. Den virket i alle de tre språkene han testet, og angripere begynte å kopiere den i løpet av dager etter publiseringen.

Hvorfor det skjer

Grunnårsaken er en pakkebehandler som behandler flere registre som likeverdige. Det klassiske eksempelet er Python: --extra-index-url i pip legger til en ekstra kilde ved siden av PyPI, og pip kan installere den offentlige pakken hvis den finner 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 det samme problemet med interne navn uten scope, mens et scope knyttet til registeret ditt unngår det.

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

Slik forhindrer du dependency confusion

• Bruk én sannhetskilde. Pek bygg mot ett internt register som er proxy for offentlige pakker, og konfigurer det slik at interne navn aldri løses offentlig.
• Bruk scopes eller navnerom. Ha eierskap til et scope som @acme i det offentlige registeret, og knytt det til ditt private.
• Reserver navnene dine. Registrer interne pakkenavn i offentlige registre, så ingen andre kan gjøre det.
• Lås og verifiser. Commit en lockfile og bruk hash-kontroll, for eksempel --require-hashes i pip, så en annen pakke får installasjonen til å feile. Se hva en lockfile gjør og ikke gjør.
• Begrens hvor bygg kan koble seg til. Hvis et bygg bare kan nå registeret ditt, kan det ikke hente angriperens pakke i det hele tatt. Se egress-policy for GitHub Actions.
• Sjekk hva du lekker. Søk i offentlig kode og klient-bundles etter de interne pakkenavnene dine.

Dependency confusion vs. typosquatting

Typosquatting er avhengig av at en person skriver navnet på en offentlig pakke feil. Dependency confusion bruker det nøyaktige navnet på en privat pakke og er avhengig av hvordan bygget er konfigurert. Begge ender på samme sted: angriperkode som kjører i bygget ditt. Se hva er et leverandørkjedeangrep for hvordan de passer sammen med andre angrep.

Slik finner du ut om du ble rammet

Se etter interne pakkenavn som ble løst fra et offentlig register, eller versjoner som ikke finnes i ditt interne. Det er vanskelig å gjøre ut fra en lockfile alene, fordi spørsmålet er hvor en pakke faktisk kom fra under bygget.

Slik hjelper CRACI

CRACI virker der pakken hentes. Som GitHub Actions-runneren din håndhever CRACI en egress-policy med typede kilder for registre, så et bygg kan begrenses til registrene du tillater. CRACI registrerer også hver pakke hver jobb hentet, i en SBOM, så du kan se hva som kom inn i et bygg. CRACI oppdager ikke at en pakke er ondsinnet, så behold registerkonfigurasjonen som første forsvarslinje. Se beste praksis for sikkerhet i programvareleverandørkjeden.

Dependency confusion: ofte stilte spørsmål

Hva er et dependency confusion-angrep?

Et angrep der en offentlig pakke med samme navn som en privat blir installert ved en feil, fordi pakkebehandleren sjekker begge registrene og foretrekker den høyeste versjonen.

Hvordan skiller dependency confusion seg fra typosquatting?

Typosquatting er avhengig av at noen skriver navnet på en offentlig pakke feil. Dependency confusion bruker det nøyaktige navnet på en privat pakke og er avhengig av en byggekonfigurasjon som sjekker offentlige registre.

Hvordan forhindrer du dependency confusion?

Bruk ett internt register, pakkenavn med scope, lockfiler med hash-kontroll og regler som begrenser hvilke registre byggene dine kan nå. Det hjelper også å reservere de interne navnene dine offentlig.

Er --extra-index-url trygt?

Ikke for private pakker. Det gjør begge indeksene til kandidater, så en offentlig pakke med samme navn kan bli installert. Bruk --index-url med én indeks du kontrollerer.

Hvem oppdaget dependency confusion?

Sikkerhetsforskeren Alex Birsan publiserte teknikken i februar 2021, etter å ha brukt den mot mer enn 35 organisasjoner under bug bounty-programmer eller med tillatelse.