Dependency Confusion

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Lavori in una azienda di sicurezza informatica? Vuoi vedere la tua azienda pubblicizzata in HackTricks? O vuoi avere accesso all'ultima versione di PEASS o scaricare HackTricks in PDF? Controlla i PACCHETTI DI ABBONAMENTO!
Scopri The PEASS Family, la nostra collezione di NFT esclusivi
Ottieni il merchandising ufficiale di PEASS & HackTricks
Unisciti al 💬 gruppo Discord o al gruppo Telegram o seguimi su Twitter 🐦@carlospolopm.
Condividi i tuoi trucchi di hacking inviando PR al repo di hacktricks e al repo di hacktricks-cloud.

Informazioni di base

In sintesi, una vulnerabilità di dependency confusion si verifica quando un progetto utilizza una libreria con un nome scritto male, inesistente o con una versione non specificata e il repository di dipendenze utilizzato consente di ottenere 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 interna esistente company-requests, ma il repository controlla repository pubblici per vedere se ci sono versioni più recenti.

Sfruttamento

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

Scritto male e inesistente

Se la tua azienda sta cercando di importare una libreria che non è interna, è molto probabile che il repository delle librerie la cerchi in repository pubblici. Se un attaccante l'ha creato, è molto probabile che il tuo codice e le macchine in esecuzione siano compromesse.

Versione non specificata

È 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 soddisfi tali requisiti.
Se la libreria è una conosciuta libreria esterna (come requests in 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 repository della libreria consente di controllare anche esternamente nuove versioni, 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 al posto di quella interna.

Soluzione AWS

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

Trovare librerie vulnerabili

Nel post originale sulla dependency confusion l'autore ha cercato migliaia di file package.json esposti contenenti le dipendenze dei progetti JavaScript.

Riferimenti