# Dependency Confusion {% hint style="success" %} Learn & practice AWS Hacking:

[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)

\ Learn & practice GCP Hacking:

[**HackTricks Training GCP Red Team Expert (GRTE)**

](https://training.hacktricks.xyz/courses/grte)

Support HackTricks

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)! * **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.** * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/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**](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)).\ 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**](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) l'autore ha cercato migliaia di file package.json esposti contenenti le dipendenze dei progetti javascript. ## References * [https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) * [https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)