Confusione delle Dipendenze

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

Lavori in una azienda di sicurezza informatica? Vuoi vedere la tua azienda pubblicizzata in 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 al repo di hacktricks e al repo di 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 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 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, 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 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 al posto di quella interna.

Soluzione 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