Dependency Confusion

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

{% embed url="https://websec.nl/" %}

Basic Information

In sintesi, una vulnerabilità di confusione delle dipendenze si verifica quando un progetto utilizza una libreria con un nome scritto male, inesistente o con una versione non specificata e il repository delle dipendenze utilizzato consente di raccogliere versioni aggiornate da repository pubblici.

Scritto male: Importa reqests invece di requests
Inesistente: Importa company-logging, una libreria interna che non esiste più
Versione non specificata: Importa una libreria company-requests interna esistente, ma il controllo del repo verifica i repo pubblici per vedere se ci sono versioni superiori.

Exploitation

{% hint style="warning" %} In tutti i casi, l'attaccante deve solo pubblicare un pacchetto malevolo con il nome delle librerie utilizzate dalla società vittima. {% endhint %}

Misspelled & Inexistent

Se la tua azienda sta cercando di importare una libreria che non è interna, è molto probabile che il repository delle librerie la cercherà in repository pubblici. Se un attaccante l'ha creata, il tuo codice e le macchine in esecuzione saranno molto probabilmente compromessi.

Unspecified Version

È molto comune per gli sviluppatori non specificare alcuna versione della libreria utilizzata, o specificare solo una versione principale. Quindi, l'interprete cercherà di scaricare l'ultima versione che soddisfa tali requisiti.
Se la libreria è una libreria esterna nota (come requests di python), un attaccante non può fare molto, poiché non sarà in grado di creare una libreria chiamata requests (a meno che non sia l'autore originale).
Tuttavia, se la libreria è interna, come requests-company in questo esempio, se il repo della libreria consente di controllare nuove versioni anche esternamente, cercherà una versione più recente disponibile pubblicamente.
Quindi, se un attaccante sa che l'azienda sta utilizzando la libreria requests-company versione 1.0.1 (consentendo aggiornamenti minori). Può pubblicare la libreria requests-company versione 1.0.2 e l'azienda utilizzerà quella libreria invece di quella interna.

AWS Fix

Questa vulnerabilità è stata trovata in AWS CodeArtifact (leggi i dettagli in questo post del blog).
AWS ha risolto questo problema consentendo di specificare se una libreria è interna o esterna, per evitare di scaricare dipendenze interne da repository esterni.

Finding Vulnerable Libraries

Nel post originale sulla confusione delle dipendenze l'autore ha cercato migliaia di file package.json esposti contenenti le dipendenze dei progetti javascript.

References