hacktricks/pentesting-web/dependency-confusion.md

5.9 KiB

Confusione delle dipendenze

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

{% 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, è 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

{% embed url="https://websec.nl/" %}

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