Come si sviluppa un attacco alla supply chain, che è il punto di partenza per capire come prevenirlo?

Il normale sviluppo del software prevede diverse fasi, ad esempio si parte dallo sviluppatore, che crea il codice sorgente che verrà convertito in programma, il quale verrà caricato su un server ed infine distribuito all’utente finale che lo installa. In questo processo ci sono diversi punti in cui un attaccante interno o esterno può inserirsi e agire: direttamente sul codice sorgente inserendo uno script malevolo, che potrà essere riportato in tutte le fasi successive fino ad arrivare all’utente finale, oppure sulle build modificando materialmente quello che è stato compilato, per inserire di nuovo un codice dannoso. In molti casi gli attaccanti possono modificare ciò che è disponibile sul server, quindi al posto delle build vengono distribuiti altri programmi che o non sono collegati al software oppure sono simili al software originale ma con aggiunte dannose. Soprattutto quando si lavora con protocolli non sicuri come http, il rischio che alcuni attori possono intervenire nell’infrastruttura di comunicazione, e quindi a livello network, per sostituire i pacchetti è molto elevato; in questo caso però non si parla di attacchi alla supply chain ma di network hijacking, ovvero di qualcosa che solitamente è distinto.

La criticità maggiore in un caso di attacco alla supply chain è la mutevolezza dello scenario. La condizione ottimale è che tutte le fasi siano distinte a livello logico: la macchina dello sviluppatore su cui si organizza localmente il codice sorgente, che poi viene passato in un repository centralizzato, e i server che si occupano delle build che poi sono trasferite su server veri e propri di aggiornamento. In molti casi, però, ci sono server di aggiornamento esterni, come ad esempio GitHub, che offrono la gestione del codice sorgente in cui si possono caricare i file finali da distribuire; si tratta dunque di server di proprietà di un’entità terza, non controllati direttamente dall’azienda. Inoltre, spesso capita che le aziende o i team di sviluppo abbiano capacità di spesa limitate e di conseguenza più componenti, in particolare sviluppatore, sorgente e build, sono contenute nella stessa macchina, rappresentando un unico punto critico.

In molti casi gli attacchi alla supply chain sono simili a quelli mirati e quelli APT. La catena di attacco è similare, ma l’impatto finale è differente. Spesso sono presenti attività di ricognizione e movimenti laterali per identificare i sistemi che contengono la compilazione, che andrebbero protetti con maggior attenzione rispetto ai sistemi tradizionali. La prima componente che va applicata nell’organizzazione aziendale per rispondere e mitigare il rischio di attacchi alla supply chain è l’applicazione delle contromisure di sicurezza – soluzioni specifiche per la protezione degli endpoint, monitoraggio delle reti, soluzioni anti APT – che sono solitamente consigliate anche per gli di attacchi mirati o sofisticati.

Alla luce della vostra esperienza, quali condotte devono cambiare le aziende per gestire questo rischio e quali strumenti gli occorrono?

Negli ultimi anni gli attacchi alla supply chain si sono sempre più intensificati. Ricordiamo ad esempio i famosi attacchi CCleaner e NoPetya, Solarwinds, che ha colpito principalmente le aziende americane, o Kaseya utilizzato per realizzare attacchi ransomware mirati con un forte impatto anche in Italia, a questi si aggiungono ShadowPad e ShadowHammer, scoperti da noi ricercatori del GReAT. Per gestire il rischio di un attacco alla supply chain, è importante effettuare verifiche e controlli che garantiscano l’impossibilità da parte di soggetti terzi o interni di inserire un codice senza che questo venga validato. A livello di codice sorgente è sempre consigliabile eseguire una code review e disporre di un sistema di tracciamento interno delle modifiche in modo da averne visibilità. In fase di building, invece, è importante limitare l’esposizione del sistema e utilizzare la politica del minimo privilegio per limitare il numero di soggetti o servizi che possono accedere all’ambiente. Lo stesso principio dovrebbe essere applicato anche sui server di distribuzione: solo un numero limitato di utenti dovrebbe avere la possibilità di generare i pacchetti e caricare, modificare o accedere al server per rendere disponibili gli aggiornamenti.

Inoltre, l’uso dei certificati digitali è importante nella fase di build, infatti, una volta generato il software, è necessario firmarlo digitalmente con certificati proprietari dell’azienda, in modo che anche le entità esterne sappiano che si tratta di un prodotto costruito e “buildato” all’interno del contesto aziendale.

Un altro aspetto importante è la verifica dell’integrità dell’ambiente di sviluppo. Soprattutto nei casi in cui i singoli sviluppatori generano le release finali che vengono poi distribuite. In questo caso è importante scaricare gli strumenti da fonti affidabili per evitare casistiche simili a quella di XCodeGhost, un vecchio caso di “supply chain attack” dove vari sviluppatori di app per iOS avevano scaricato, da repository non ufficiali, una versione modificata dell’ambiente di sviluppo di Apple XCode che in automatico aggiungeva del codice dannoso ai progetti creati dagli sviluppatori.

A livello di server, invece, sono consigliate tutte le contromisure che solitamente si applicano in ambito amministrativo e, nel caso siano esterni, è importante fare attenzione all’autenticazione, preferendo quella multi-fattore, per limitare le possibilità di compromissione delle credenziali. Infine, i software di terze parti rappresentano il problema principale. Quando si crea un software spesso vengono sfruttate le librerie di terze parti che offrono determinate funzionalità senza che lo sviluppatore debba riscriverle da zero. Purtroppo la verifica di queste librerie è più complessa e solitamente non è possibile avere visibilità sulla sicurezza delle relative “supply chain”. In questo caso si ha poco spazio di manovra ma lo SBOM, ovvero la lista delle componenti utilizzate all’interno dei software per il tracciamento delle attività, può essere di grande aiuto, permettendo di comprendere meglio il livello di rischio e velocizzare le eventuali attività di risposta agli incidenti informatici identificati da entità terze.