Attacchi alla supply chain nel mondo dell’open source

Dopo gli attacchi informatici ai provider Solar Winds e Kaseya, che causarono la compromissione di migliaia di aziende ed enti nazionali in tutto il mondo, le organizzazioni di cyber criminali hanno diversificato le proprie strategie di attacco alla supply chain del software con l’obiettivo di consolidare sempre più il loro impatto sull’economia del cybercrime.

L’azienda americana di software Sonatype ha recentemente costruito una timeline che racchiude la breve storia di tutti gli attacchi registrati ad aziende che operano nel settore del B2B del software. Partiremo da questo strumento per un’analisi dettagliata di alcuni casi.

La libreria ua-parser-js di NPM

Scorrendo sul sito sopracitato la cronologia degli attacchi, tra cui ritroviamo il ransomware Revil di Kaseya del luglio del 2021, è importante soffermarsi su un major incident che ha visto coinvolta una sussidiaria di GitHub chiamata NPM. L’azienda americana Node Package Manager (NPM) gestisce librerie opensource Javascript ed ogni settimana, dalla sua piattaforma online, vengono effettuati milioni di download di pacchetti utilizzati da grandi aziende come Facebook, Microsoft, Amazon, Instagram, Google, Slack, Mozilla, Discord, Elastic, Intui, Reddit, etc.

Venerdì 22 ottobre 2021, per quasi 4 ore consecutive, ua-parser-js, uno dei pacchetti NPM più scaricato, è stato incorporato con uno script dannoso con l’obiettivo di installare un bitcoin miner e un trojan per raccogliere informazioni sensibili e credenziali. Le versioni compromesse dai criminali sono state le seguenti: 0.7.29, 0.8.0, 1.0.0.

Per risolvere il codice malevolo è stato effettuato un revert dal codice risalendo alla versione precedente all’attacco. La libreria ua-parser-js viene utilizzata nelle applicazioni o nei siti web per analizzare lo user agent di un browser ed identificare il browser stesso, il sistema operativo, la CPU e il dispositivo dell’utente. Quando i pacchetti malevoli vengono installati sulla macchina, uno script malevolo .js viene eseguito da una shell Linux o un file batch di Windows per dare il via alla raccolta silente di dati o per minare cryptovaluta.

Già nel 2017 NPM subì un data leak importante con 16.400 credenziali di sviluppatori esposte che permise ai criminali di accedere al 14% del repository, che si stima contenesse 79 mila pacchetti Javascript.

Per i criminali fu semplice trovare l’accesso alla maggior parte degli account tramite ricerche OSINT, poiché i dati erano già disponibili online in seguito a precedenti violazioni. Vennero identificati migliaia di utenti che utilizzavano come password il proprio username oppure password deboli come 1234 o password01. A seguito del primo attacco, venne effettuato un reset password massivo a causa delle scarse regole di cyber-igiene nell’uso delle credenziali da parte degli utenti.

I diversi attacchi del 2021, però, si pensa provenissero dalla compromissione di account dei mantainer, ovvero di quelle figure che svolgono un’attività di controllo e direzione nella pubblicazione degli sviluppi nei progetti opensource e a cui la community di utilizzatori può segnalare problematiche o discutere miglioramenti.

NPM richiederà l’autenticazione a due fattori nel primo trimestre del 2022. Secondo GitHub, infatti, nessuno dei manutentori di queste librerie popolari possedeva l’MFA abilitata sui propri account al momento della violazione di dati.

Analisi dal malware

Il 20 ottobre 2021 sono stati individuati dai ricercatori di Sonatype diversi pacchetti chiamati “okhsa” e “klown” nel registro di NPM cryptominer su macchine Windows, macOS e Linux. Tutti i pacchetti sono stati pubblicati dallo stesso autore “wozheqirsplu” il cui account è stato tempestivamente disattivato da NPM.

In particolare, le diverse versioni del pacchetto “okhsa” contengono un codice che sfrutta una vulnerabilità nell’applicazione Calcolatrice su macchine Windows.

Questi script scaricano un EXE o un ELF Linux che eseguono un codice che specifica il cryptominer da utilizzare, il portafoglio Bitcoin verso cui indirizzare la criptovaluta estratta e la quantità di CPU da utilizzare.

Inoltre, è stato identificato un file Batch contenente una sequenza di comandi come cmd.exe in alcune versioni del malware nel pacchetto “klown”.

Il cryptominer Xmrig, identificato per la prima volta nel maggio 2017, appartiene ad una delle 3 varianti più diffuse che, in particolare, ha colpito l’8% delle organizzazioni in tutto il mondo.

Il malware riesce a determinare la posizione del dispositivo e, se non si trova in un Paese tra Russia, Ucraina, Bielorussia o e Kazakistan, scarica il file http[:]//159.148.186[.]228/download/jsextension e lo esegue.

La libreria coa e rc di NPM

Risalendo lungo la cronologia della supplychain di Sonatype arriviamo a novembre 2021 quando la libreria chiamata “coa” fu colpita dallo stesso identico attacco di ua-parser-js.

Una versione malevola di “coa” compromessa conteneva trojan simili a quelli visti nel caso di NPM per il furto di credenziali. Poche ore dopo, “rc”, un’altra libreria con 14 milioni di download settimanali, subì lo stesso hijacking.

Tutti gli attacchi hanno avuto una linea in comune: vi è infatti un collegamento tra i criminali e gli incidenti.

Il 16 novembre 2021 i ricercatori Kajetan Grzybowski e Maciej Piechota hanno risolto una vulnerabilità che consentiva la pubblicazione non autorizzata di nuove versioni dal 2020.

In particolare, il problema riguardava il registro JavaScript NPM che consentiva ad un utente malintenzionato di aggiornare qualsiasi pacchetto utilizzando un account senza autorizzazione. GitHub ha dichiarato che la vulnerabilità non è stata sfruttata nella maniera più assoluta in modo dannoso (almeno da settembre 2020).

I rischi dell’open source

Oltre il 90% di qualsiasi applicazione moderna è costituita da codice open source, consentendo sia l’ispezione del codice che la sua modifica e miglioramento. Alcuni rischi per la sicurezza informatica derivano dalla costruzione del software open source e dal metodo di distribuzione che in gran parte non è ancora regolamentato.

I rischi principali sono:

• Le vulnerabilità nel software open source sono rese di dominio pubblico dai contributori stessi, nonché da organizzazioni come l’NVD. Se non si effettuano gli aggiornamenti alle ultime versioni o componenti in breve tempo, ci si espone ad un rischio elevato, poiché le vulnerabilità sono spesso identificate e immediatamente sfruttate dai criminali informatici.

• Gli sviluppatori responsabili della creazione del software spesso non sono esperti di sicurezza e il rischio che si corre è che potrebbero non essere seguite ed implementate le best practice.

• Spesso il software open source richiede l’uso di librerie di terze parti estratte dai gestori di pacchetti, come NMP. La natura black-box di queste librerie rende più difficile e dispendioso, in termini di tempo, identificare e correggere eventuali vulnerabilità che potrebbero essere introdotte nel codice originale dai criminali informatici. Inoltre, la difficoltà nel trovare una vulnerabilità aumenta ancora di più considerando la complessità esponenziale dei sistemi informatici.

• Infine, il software open source non fornisce alcuna garanzia in merito alla sua sicurezza o al suo contenuto.

I membri della comunità possono fornire supporto per problemi di sicurezza attraverso forum aperti senza però essere responsabili in caso di eventuali problemi nel codice. Inoltre, il software open source è generalmente creato da comunità di contributori a volte anonimi, per questo è difficile verificare che il codice fornito sia originale e non preso da una fonte di terze parti.

Conclusione

Un caso che mette in luce quanto sia potenzialmente pericoloso dedicare un’infrastruttura all’open source è quello del 10 gennaio del 2022: uno sviluppatore ha intenzionalmente corrotto due librerie open source su GitHub e i registri npm “faker.js” e “colors.js”, scaricati rispettivamente da 2,5 milioni e 2,4 milioni di utenti. Le versioni sabotate hanno fatto sì che le applicazioni emettessero all’infinito lettere e simboli.

NPM e, soprattutto, il recente caso di Log4j hanno portato un’attenzione sempre maggiore sulla software composition analysis che deve essere effettuata in anticipo per comprendere quali componenti open source vengono utilizzate nei software per poter effettuare una remediation nel caso di injection malevola.

Più in generale, è arrivato il momento che i gestori di librerie e gli sviluppatori acquisiscano e concretizzino nuove abitudini in ambito di security.