5.9 KiB
Confusione delle dipendenze
Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!
- Lavori in una azienda di sicurezza informatica? Vuoi vedere la tua azienda pubblicizzata su HackTricks? o vuoi avere accesso all'ultima versione del PEASS o scaricare HackTricks in PDF? Controlla i PACCHETTI DI ABBONAMENTO!
- Scopri La Famiglia PEASS, 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 ai repository hacktricks e hacktricks-cloud.
{% embed url="https://websec.nl/" %}
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
reqests
invece direquests
- 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 superiori.
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 %}
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
- https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
- https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d
{% embed url="https://websec.nl/" %}
Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!
- Lavori in una azienda di sicurezza informatica? Vuoi vedere la tua azienda pubblicizzata su HackTricks? o vuoi avere accesso all'ultima versione del PEASS o scaricare HackTricks in PDF? Controlla i PACCHETTI DI ABBONAMENTO!
- Scopri La Famiglia PEASS, 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 ai repository hacktricks e hacktricks-cloud.