Gli sviluppatori sanno bene che i supply chain attack sono un problema. Da non confondersi con gli attacchi digitali alla supply chain (in senso lato) delle imprese, questi riguardano la "catena del valore" dello sviluppo. Ossia cercano di "conquistare" quanti più sistemi possibili violando almeno uno dei componenti usati nello sviluppo di una applicazione o un servizio. È spesso un problema di open source security. Perché i componenti open source spesso sono meno sicuri di quanto potrebbero.

GitHub è stata coinvolta suo malgrado in un caso di vulnerabilità diffusa attraverso la supply chain software. Un caso di open source security in cui una ventina di repository collegati al mondo Java hanno veicolato un pericoloso malware. Battezzato Octopus Scanner. E parecchio ingegnoso nel suo funzionamento: creare backdoor in tutti i progetti per i quali venivano usati i componenti "infetti". Attraverso diversi passi, come vediamo in dettaglio.

Una volta scaricato sul computer del malcapitato sviluppatore, Octopus Scanner lo scandaglia alla ricerca delle cartelle dell'ambiente di sviluppo NetBeans. Che una volta era l'IDE di riferimento per la larga maggioranza degli sviluppatori Java. Ma ora, sfortunatamente per Octopus, è molto meno diffuso. Trovate le cartelle, inserisce in quelle di ciascun singolo progetto un file apparentemente innocuo: cache.dat. Poi fa in modo che questo file "innocuo" sia eseguito ogni volta che NetBeans esegue la build di un progetto Java.
Cache.dat ovviamente non è affatto innocuo. Il suo compito principale, durante la fase di building del progetto, è modificare tutte le classi Java coinvolte prima che siano assemblate in un file .jar. Le classi così modificate diventano un vero e proprio codice "ostile". Per chiunque lo esegua.

Questo codice fa essenzialmente tre cose. Crea un canale di comunicazione tra il computer colpito e alcuni server C2 di comando e controllo. Scarica un trojan per l'accesso remoto (un Remote Administration Tool, o RAT) che può eseguire diverse azioni sul computer-bersaglio. Mette in atto alcune azioni di offuscamento e persistenza, per non essere identificato ed eliminato dagli anti-malware.

A questo punto un qualsiasi sviluppatore colpito da Octopus è una mina vagante per la open source security. Potenzialmente ogni progetto a cui sta lavorando contiene una backdoor per un RAT. Basta eseguirne la build e aggiornare il repository del progetto su GitHub per rendere il repository stesso un "distributore" di artefatti Java infetti. E incrementare ulteriormente il contagio di Octopus. Che opera più o meno allo stesso modo indipendentemente dal sistema operativo - Linux, macOS, Windows - del computer colpito.
Ad aumentare la pericolosità di Octopus Scanner è il fatto che un repository infetto può essere anche clonato da un secondo sviluppatore. E un terzo può decidere di eseguirne un forking. E così via, con operazioni a catena che aumentano la probabilità di infezione del malware e, allo stesso tempo, lo rendono più subdolo. Perché il malware di "allontana" dal repository originario ed è meno identificabile, se si scopre che il repository di partenza è stato compromesso.

Inoltre, infettare il computer di uno sviluppatore con un RAT può essere molto "redditizio" per i criminali. Perché su quel computer probabilmente si trovano dati importanti e rivendibili. Come in primo luogo le credenziali di accesso a sistemi e risorse aziendali pregiate. Octopus adesso è stato fermato da GitHub e dagli sviluppatori ed esperti di sicurezza che hanno partecipato alla sua analisi. Ma è un esempio di quanto restino chiave i supply chain attack per lo sviluppo software e la open source security.