Siano essi centralinisti, sistemisti o developer, ogni persona che lavori per conto di un’azienda tech è potenziale vettore e obiettivo di attori malevoli ed è necessario mantenere alta la guardia per evitare di ritrovarsi a essere inconsapevolmente noi stessi punto di ingresso verso il cuore dell’infrastruttura aziendale.
Tutto nasce da un pacchetto, ovvero una collezione di codice riutilizzabile scritto da altri per fare quasi qualunque cosa, dal sapere se un numero è pari, sino all’identificare delle persone in un feed video. Avere come dipendenza del codice pubblico significa fidarsi di altri dev sconosciuti ma è una pratica essenziale nel mondo tecnologico moderno perché consente di non dover reinventare la ruota ogni giorno.
Ebbene, correva il 2021 quando un security researcher rumeno che va sotto il nome di Alex Birsen stava lavorando a un bounty program per Paypal quando, insieme a un gruppo di colleghi, notava su dei repo Github del codice Node.js, sempre relativo a Paypal, che includeva nel file package.json una lista di pacchetti elencati come dipendenze.
Si sa che le dipendenze sono spesso sede di vulnerabilità e, più dipendenze ha un software, maggiore sarà la superficie di attacco. Tali pacchetti, però, non risultavano disponibili tramite npm, il noto package manager di Javascript, poiché distribuiti da repository interni all’azienda e quindi inarrivabili.
Un vicolo cieco, verrebbe da pensare, e tutto ciò sarebbe potuto essere ignorato se non fosse per la curiosità di Birsen e colleghi, i quali si sono chiesti cosa sarebbe accaduto se si fosse caricato sui repo pubblici un pacchetto con lo stesso nome di uno di quelli internamente distribuiti.
Birsen e colleghi che, ricordiamo, stavano lavorando al bounty program ed erano quindi autorizzati dalla stessa azienda ad andare oltre, hanno così provato a fare esattamente quanto descritto e i risultati avevano dell’incredibile: in mancanza di accorgimenti specifici (package indexing o hash da matchare), trovando lo stesso pacchetto sia nei repo aziendali interni e sia sui repo pubblici, npm non solo sceglie di installare la versione più recente, ma permette anche di eseguire uno script di pre-installazione, che può contenere ulteriore codice arbitrario. Trattandosi di un test e non di hacker black hat, si è scelto di raccogliere giusto alcune informazioni tecniche innocue e non sensibili, come ad esempio ip e hostname delle macchine raggiunte.
Non è difficile immaginare come, a questo punto, la frittata fosse quasi fatta, sebbene il cerchio non fosse ancora chiuso. Rimaneva solo l’ultimo ma non meno importante step, ovvero l’esfiltrazione dei dati acquisiti, task non facile dal momento che qualsiasi azienda che si rispetti implementa diverse misure di sicurezza che bloccherebbero o almeno rileverebbero quasi subito il traffico anomalo, tra regole firewall stringenti, IDS, EDR e quant’altro.
Come ben sappiamo, però, qualcosa deve pur uscire affinché la rete funzioni e una di queste sono le richieste DNS, ancora tallone di Achille di molte infrastrutture. Il team di Birsen ha quindi pensato di implementare un’altra categoria di attacco già conosciuta come DNS exfiltration e, adesso sì, il piano era completo.
A questo punto non rimaneva che testare il piano sul campo e i risultati hanno superato ogni aspettativa. I pacchetti malevoli venivano scaricati e questo attacco di dependency confusion stava funzionando davvero. Il team ha quindi espanso lo scope anche ad altre aziende, entrandone nei relativi bounty program per essere autorizzati a svolgere tali test, e ben 35 aziende si sono rivelate vulnerabili all’attacco, che sembra essere viabile sia con npm (Javascript), sia con pip (Python), sia con gem (Ruby).
Non molto tempo dopo, una volta comunicato quanto scoperto alle aziende interessate, il team iniziava a intascare i premi delle relative bug bounty, che si aggirano complessivamente intorno ai 130.000 dollari. Tra le aziende colpite, giganti del calibro Apple, Shopify, Netflix, Paypal, Yelp e Uber.
A seguito di questa vicenda, Sonatype ha dichiarato di aver rilevato più di 700 pacchetti che emulavano la tecnica, stavolta caricati da attori malevoli e non più con l’intento di esportare informazioni innocue ma dati sensibili, finalizzati alla reale compromissione delle aziende colpite.
Tornando ai giorni nostri, vi starete domandando se tale attacco è ancora possibile e la risposta non solo è affermativa, ma tale attacco continua ad essere usato attivamente.
Possibili mitigazioni consistono nell’includere un controllo di hash, limitare quanto più possibile l’utilizzo di dipendenze esterne e affidarsi a pacchetti ben conosciuti o specificare direttamente il repo (privato o pubblico) da cui si intendono installare i pacchetti. Occorre, comunque, mantenere alta la guardia in quanto i supply chain attack rimangono sempre dietro l’angolo.
English (US)