Dependency Confusion nuova tecnica di attacco alla Supply Chain

Dependency Confusion, la nuova tecnica di attacco alla supply chain. L’attacco comprende il caricamento di malware su repository open source.

Dependency Confusion nuova tecnica di attacco alla Supply Chain

Dependency Confusion, la nuova tecnica di attacco alla supply chain.

Un ricercatore è riuscito a violare i sistemi interni di oltre 35 grandi aziende, tra cui Microsoft, Apple, PayPal, Shopify, Netflix, Yelp, Tesla e Uber, in un nuovo attacco alla supply chain del software.

L’attacco comprende il caricamento di malware su repository open source tra cui PyPI, npm e RubyGems, per poi essere distribuiti automaticamente a valle nelle applicazioni interne dell’azienda.

A differenza dei tradizionali attacchi di typosquatting che si basano su tattiche di ingegneria sociale o di errori di ortografia della vittima nel nome di un pacchetto, questo particolare attacco alla supply chain è più sofisticato in quanto non ha richiesto alcuna azione da parte della vittima, che ha ricevuto automaticamente i pacchetti dannosi.

Questo perché l’attacco ha sfruttato un difetto di progettazione unico degli ecosistemi open source chiamato Dependency Confusion (confusione delle dipendenze).

Per i suoi sforzi di ricerca etica, il ricercatore ha guadagnato ben oltre $ 130.000 in bug bounties.

Il malware viene distribuito automaticamente

L’anno scorso, il ricercatore di sicurezza Alex Birsan ha avuto l’idea quando lavorava con un altro ricercatore Justin Gardner.

Gardner aveva condiviso con Birsan un file manifest, package.json, da un pacchetto npm utilizzato internamente da PayPal.

Dependency Confusion

Birsan ha notato che alcuni dei pacchetti di file manifest non erano presenti nel repository npm pubblico, ma erano invece pacchetti npm creati privatamente da PayPal, utilizzati e archiviati internamente dall’azienda.

Vedendo questo, il ricercatore si è chiesto, se esistesse un pacchetto con lo stesso nome nel repository npm pubblico, oltre a un repository NodeJS privato, quale avrebbe la priorità?

Per testare questa ipotesi, Birsan iniziò a cercare nomi di pacchetti interni privati che poteva trovare nei file manifest sui repository GitHub o nei CDN di importanti aziende ma che non esistevano in un repository open source pubblico.

Il ricercatore ha quindi iniziato a creare progetti contraffatti utilizzando gli stessi nomi su archivi open-source come npm, PyPI e RubyGems.

Ogni pacchetto pubblicato da Birsan è stato fatto sotto il suo account reale e aveva chiaramente un disclaimer in atto, affermando “Questo pacchetto è pensato per scopi di ricerca sulla sicurezza e non contiene alcun codice utile”.

Dependency Confusion

Birsan si è reso presto conto che se un pacchetto di dipendenze utilizzato da un’applicazione esiste sia in un repository pubblico open source che in una build privata, il pacchetto pubblico ha la priorità venendo scaricato, senza che fosse necessaria alcuna azione da parte dello sviluppatore.

In alcuni casi, come con i pacchetti PyPI, il ricercatore ha notato che il pacchetto con la versione superiore ha la priorità indipendentemente da dove si trovava.

Utilizzando questa tecnica, Birsan ha eseguito con successo un attacco alla supply chain contro Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp e Uber semplicemente pubblicando pacchetti pubblici utilizzando lo stesso nome di quelli interni dell’azienda.

Credo che la Dependency Confusion sia molto diversa dal typosquatting o dal brandjacking, in quanto non richiede necessariamente alcun tipo di input manuale da parte della vittima“.

Piuttosto, vulnerabilità o difetti di progettazione negli strumenti di installazione o build automatizzati possono far sì che le dipendenze pubbliche vengano scambiate per dipendenze interne con lo stesso identico nome“, ha detto Birsan  in un’intervista via e-mail.

Guadagnati oltre $130.000 in bounties

Complessivamente, il ricercatore è riuscito a guadagnare oltre $130.000 in premi attraverso programmi di bug bounty e accordi di penetration test pre-approvati.

Ritengo sia importante chiarire che ogni singola organizzazione presa di mira durante questa ricerca ha fornito il permesso di testare la propria sicurezza, tramite programmi pubblici di bug bounty o accordi privati. Si prega di non tentare questo tipo di test senza autorizzazione, “avverte Birsan.

Per la divulgazione di Birsan, Microsoft gli ha assegnato la più alta quantità di bug bounty di $40.000 e ha pubblicato un white paper su questo problema di sicurezza. Identificano questo problema come CVE-2021-24105 per il loro prodotto Azure Artifactory.

Tuttavia, Microsoft ha detto a Birsan in una e-mail che lo considera un difetto di progettazione nei gestori di pacchetti.

``Anche se stiamo trattando questo come un grave problema di sicurezza, alla fine deve essere risolto riconfigurando gli strumenti di installazione e i flussi di lavoro, e non correggendo nulla nei repository dei pacchetti stessi .... Per risolvere questo problema, Microsoft ha apportato piccoli miglioramenti ad Azure Artifacts per garantire che possa essere utilizzato come soluzione alternativa affidabile ... Detto questo, riteniamo che la causa principale di questo problema sia un difetto di progettazione (piuttosto che un bug) nei gestori di pacchetti che può essere risolto solo attraverso la riconfigurazione``

In una dichiarazione a BleepingComputer, Yelp ha confermato il rapporto del ricercatore e lo ha premiato dopo aver risolto il problema entro un giorno.

``Attraverso il programma bug bounty di Yelp, Alex Birsan ci ha aiutato a identificare una vulnerabilità, che abbiamo risolto immediatamente entro un giorno ... Ci impegniamo a collaborare con esperti di sicurezza per rimanere aggiornati con le ultime tecniche di sicurezza e fare affidamento sul nostro programma di bug bounty per premiare i ricercatori di sicurezza qualificati che aiutano a migliorare i sistemi e i servizi di Yelp``

Apple ha detto  che Birsan riceverà una ricompensa tramite il programma Apple Security Bounty per aver divulgato responsabilmente questo problema.

PayPal ha divulgato pubblicamente il rapporto HackerOne di Birsan nel quale menziona l’importo della taglia di $30.000.

Tuttavia, gli sforzi di ricerca etica del ricercatore non sono stati accolti favorevolmente da tutti.

Penso che questo [sia] probabilmente un motivo sufficiente per non avere questi progetti su PyPI“, ha affermato Dustin Ingram, Direttore della Python Software Foundation e un sostenitore degli sviluppatori di Google, che ha indagato e ha ritirato alcuni dei pacchetti di Birsan da PyPI.

Dopo aver trascorso un’ora a rimuovere questi pacchetti, Ingram ha sottolineato che il caricamento di pacchetti illeciti su PyPI pone un onere eccessivo sui volontari che mantengono PyPI.

In definitiva, se sei interessato a proteggere gli utenti da questo tipo di attacco, ci sono modi migliori per farlo che proteggano l’intero ecosistema, non solo un insieme specifico di organizzazioni con premi di bug“, ha aggiunto Ingram.

Gli attacchi dovrebbero aumentare, un problema difficile da risolvere

Attraverso questa ricerca che abbraccia le principali organizzazioni, Birsan afferma di aver già sensibilizzato le principali aziende tecnologiche con questo tipo di attacco, le quali ora hanno implementato una sorta di mitigazione nella loro infrastruttura. Tuttavia, il ricercatore ritiene che ci sia altro da scoprire.

Resta la possibilità che tali attacchi riaffiorino e crescano, specialmente su piattaforme open source senza una soluzione facile per la dependency confusion.

Nello specifico, credo che trovare modi nuovi e intelligenti per far trapelare i nomi dei pacchetti interni esporrà sistemi ancora più vulnerabili e la ricerca di linguaggi di programmazione e repository alternativi da prendere di mira rivelerà una superficie di attacco aggiuntiva per bug di dependency confusion“, ha concluso il ricercatore nel suo post sul blog.

Sonatype ha rilasciato uno script su GitHub che gli utenti di Nexus Repository Manager possono eseguire per verificare se una delle loro dipendenze private prende il nome da pacchetti esistenti presenti nei repository pubblici npm, RubyGems e PyPI. Le aziende di altri gestori di archivi di artefatti possono adottare implementazioni identiche.

Related Posts

Comments are closed.