Dipendenza Confusa
Reading time: 3 minutes
tip
Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.
Informazioni di Base
In sintesi, una vulnerabilità di dipendenza confusa 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 raccogliere versioni aggiornate da repository pubblici.
- Scritto male: Importa
reqests
invece direquests
- 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.
Sfruttamento
warning
In tutti i casi, l'attaccante deve solo pubblicare un pacchetto malevolo con il nome delle librerie utilizzate dalla società vittima.
Scritto Male & Inesistente
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.
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 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.
Correzione AWS
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.
Trovare Librerie Vulnerabili
Nel post originale sulla dipendenza confusa l'autore ha cercato migliaia di file package.json esposti contenenti le dipendenze dei progetti javascript.
Riferimenti
- https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
- https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d
tip
Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.