Dependency Confusion
Informazioni di base
In sintesi, una vulnerabilità di confusione delle dipendenze si verifica quando un progetto utilizza una libreria con un nome sbagliato, inesistente o con una versione non specificata e il repository delle dipendenze utilizzate consente di raccogliere versioni aggiornate da repository pubblici.
Sbagliato: Importa
reqestsinvece direquestsInesistente: 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 superiori.
Sfruttamento
In tutti i casi, l'attaccante deve solo pubblicare un pacchetto dannoso con il nome delle librerie utilizzate dall'azienda vittima.
Sbagliato & Inesistente
Se la tua azienda sta cercando di importare una libreria che non è interna, è molto probabile che il repository delle librerie la stia cercando in repository pubblici. Se un attaccante l'ha creato, è molto probabile che il tuo codice e le macchine in esecuzione siano compromessi.
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 libreria esterna conosciuta (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 (consente aggiornamenti minori), può pubblicare la libreria requests-company versione 1.0.2 e l'azienda utilizzerà quella libreria invece di quella interna.
Correzione AWS
Questa vulnerabilità è stata trovata in AWS CodeArtifact (leggi i dettagli in questo post sul blog). AWS ha risolto questo 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 confusione delle dipendenze l'autore ha cercato migliaia di file package.json esposti contenenti le dipendenze dei progetti JavaScript.
Riferimenti
Last updated
