Dependency Confusion
Last updated
Last updated
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
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.
In tutti i casi, l'attaccante deve solo pubblicare un pacchetto malevolo con il nome delle librerie utilizzate dalla società vittima.
Se la tua azienda sta cercando di importare una libreria che non è interna, è molto probabile che il repo 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.
È molto comune per gli sviluppatori non specificare alcuna versione della libreria utilizzata, o specificare solo una versione principale. Quindi, l'interprete cercherà di scaricare la versione più recente che soddisfa quei 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.
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.
Nel post originale sulla confusione delle dipendenze l'autore ha cercato migliaia di file package.json esposti contenenti le dipendenze dei progetti javascript.
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
