Il ricercatore di sicurezza Alex Birsan ha ottenuto l'accesso a sistemi appartenenti ad
Apple, Microsoft, PayPal, Shopify, Netflix, Tesla, Uber e altre aziende, sfruttando strumenti di sviluppo pubblici open source. L'azione, che si può vedere come un attacco alla supply chain, si basa su una vulnerabilità che Birsan ha soprannominato
dependency confusion.
Dopo SolarWinds gli attacchi alle supply chain sono la nuova e più pericolosa minaccia informatica da cui guardarsi. È quindi una buona cosa che i ricercatori di sicurezza cerchino di sferrare attacchi di questo tipo per
testare le difese delle aziende e rafforzarle, in vista di eventuali attacchi reali.
Dependency confusion identifica una vulnerabilità che può consentire a un attaccante di eseguire malware all'interno delle reti di un'azienda mediante l'override di pacchetti di dipendenze dannosi. Il trucco sta nell'iniettare codice dannoso in strumenti comuni per l'installazione di dipendenze nei progetti di sviluppo che utilizzano repository pubblici come GitHub.
Tutto parte dal fatto che la maggior parte dei linguaggi di programmazione usa un metodo più o meno ufficiale per installare le dipendenze nei progetti privati. Gli installatori sono solitamente legati a repository di codice pubblici, in cui chiunque può caricare liberamente pacchetti di codice che tutti possono utilizzare. Node sfrutta il registro NPM, Python utilizza PyPI (Python Package Index), eccetera.
Nessuno dei servizi di hosting può garantire che tutto il codice caricato dai suoi utenti sia privo di malware. È qui che si creano molte opportunità per i cyber attacchi. In passato era già emerso il problema del
typosquatting, ossia l'impiego dei nomi tipografici di pacchetti popolari per la pubblicazione di codice dannoso. Lo stesso meccanismo funziona con la dependency confusion: caricare codice dannoso sotto il falso nome di dipendenze usate nei progetti di sviluppo.
Il codice dannoso utilizza le dipendenze malevole per
propagare malware attraverso le applicazioni e i sistemi interni di un'azienda vittima. È esattamente quello che ha fatto Birsan, per verificare se la tecnica funzionasse. Ha individuato le aziende che intendeva colpire e ha caricato codice dannoso nei registri pubblici delle dipendenze NPM sotto i nomi di pacchetti privati che ha trovato su GitHub, su siti di hosting e su forum online.
Qui è arrivata la prima scoperta: se un pacchetto di dipendenza è elencato con lo stesso nome su repository pubblici e privati, la versione pubblica ha la priorità e viene utilizzata. Il ricercatore ha sferrato il suo attacco e "
il tasso di successo è stato semplicemente sorprendente".
L'aspetto più preoccupante è che
non è stata necessaria alcuna interazione da parte di Birsan: la sostituzione dei pacchetti privati con quello pubblico dannoso di Birsan è stata automatica. Il test, condotto con un pezzo di codice sorgente di Node.js ai danni di PayPal, è stato replicato creando pacchetti pubblici RubyGems e Python, bersagliando Apple, Yelp, Microsoft, Shopify, Netflix, Tesla e Uber e altri.
Fortunatamente l'attaccante non era un cyber criminale, quindi quello che ha fatto è stato solo collezionare tutte le informazioni su quello che aveva fatto e inviarle alle aziende colpite perché ponessero rimedio ai problemi. In tutto
Birsan ha colpito più di 35 aziende, di cui "la stragrande maggioranza con oltre 1.000 dipendenti".
L'annoso problema del DevOps
Quanto provato dal ricercatore non fa che rafforzare la nota dolente evidenziata
dall'attacco a SolarWinds:
i processi di sviluppo software sono tutt'altro che secure by design. Nello sviluppo di codice non è prioritaria la sicurezza, ma la velocità. Questo espone migliaia di aziende all'altissimo rischio di subire attacchi come quello che si è verificato alla supply chain di Solar Winds. Sulla questione insiste fortemente anche Birsan, sottolineando che troppo spesso sono
gli errori interni delle aziende di sviluppo ad aprire le porte ai cyber attacchi.
Errori commessi dagli sviluppatori sulle proprie macchine, server di compilazione interni o in cloud non configurati correttamente, pipeline di sviluppo vulnerabili dal punto di vista sistemico. Tutto porta a delineare un
percorso agevolato per l'inserimento di backdoor e codice malevolo all'interno delle build in fase di sviluppo. L'hack dimostra peraltro quanto era già noto ai più: il problema riguarda la maggioranza delle grandi aziende di sviluppo software.
Ieri, nel corso di un evento per i partner, il Presidente di SolarWinds John Pagliuca ha affermato che l'attacco alla supply chain non è stato un attacco contro Solar Winds, ma contro gli Stati Uniti d'America. Volendo allargare gli orizzonti, sarebbe più corretto dire che è stato un attacco contro chiunque sviluppi software, dentro e fuori dagli USA. Per essere corretti, dovremmo dire che è stato un attacco studiato per sfruttare un problema noto nello sviluppo software, in modo da massimizzare vittime e danni.
Il Vice Presidente della Security di Solar Winds, Tim Brown, ha argomentato una difesa estrema sottolineando che i prodotti MSP non sono stati intaccati da Sunburst e da Supernova. E ha ripetuto come un mantra che non ci sono prove che siano avvenuti movimenti laterali nell'ambiente di sviluppo.
Peccato che oltre 18.000 clienti siano stati colpiti dal codice malevolo diffuso con il suo software.
Birsan ha dimostrato almeno un modo per farlo senza fare movimenti laterali e senza inscenare effetti hoolywoodiani. È indubbiamente una lezione dura da imparare.