L’attacco Trojan Source, individuato da alcuni ricercatori dell’Università di Cambridge, si basa sull’omografia ovvero sul fatto che alcuni caratteri possono apparire come altri, in particolare quando si usano codifiche diverse all’interno dello stesso file (ASCII e Unicode, per esempio).
Utilizzare caratteri Unicode in un file ASCII fa si che alcune IDE di sviluppo non visualizzino correttamente il carattere che può essere quindi scambiato per altro dallo sviluppatore. Di conseguenza, è estremamente difficile da individuare durante una revisione manuale del codice. Per la macchina si tratta, invece, di porzioni di codice da eseguire, esattamente come le altre.
I ricercatori hanno individuato questa anomalia in alcune librerie largamente utilizzate e scaricabili attraverso il Node Package Manager (NPM), un gestore di pacchetti per il linguaggio JavaScript. In particolare, le anomalie sono state scoperte in:
- coa (Command-Option-Argument): un parser di argomenti della linea di comando con circa 8,8 milioni di download a settimana;
- rc: un configuration loader con circa 14,2 milioni di download a settimana;
- ua-parser-js: una libreria utilizzata per identificare alcune informazioni del sistema come il tipo di browser, si sistema operativo, modello del dispositivo e via dicendo con circa 8,2 milioni di download a settimana.
Analizzando l’insieme dei caratteri omografici è emerso uno script offuscato che scarica ed esegue un trojan infettando quindi la macchina. Il trojan individuato dai ricercatori è il password stealer Qakbot.
Non è ancora noto se ci siano altre librerie compromesse o altri package manager affetti o da quanto tempo sia in corso questo tipo di attacco. Di sicuro è possibile stimare il numero dei possibili software compromessi dal numero di volte che queste librerie sono state scaricate ma è estremamente complesso capire quali software siano effettivamente compromessi.
Indice degli argomenti
I rischi di un attacco Trojan Source
Stando alle ricerche condotte finora, il codice malevolo può essere eseguito in diversi punti: in fase di build dell’applicativo come in fase di esecuzione del codice JavaScript sul browser.
Le vittime, quindi, possono essere sia i server o i computer su cui viene compilato l’applicativo, sia i browser e quindi i computer che fruiscono dell’applicativo web.
I rischi sono diversi anche in funzione della vittima ma è ragionevole ipotizzare un ampio furto di dati che include indicativamente:
- furto di password dai password manager dei browser;
- furto di password di altri applicativi come RDP, FTP, email ecc.;
- furto di carte di credito dove conservate sul dispositivo infetto;
- furto di documenti di identità, dove conservati sul dispositivo infetto, come carta d’identità, passaporto e via dicendo.
Per le aziende vanno poi considerati altri rischi quali, ad esempio, danno d’immagine, non conformità ai regolamenti (leggi: GDPR) e quindi dei danni economici derivanti da eventuali sanzioni oltre ai costi per la mitigazione e risanamento del problema.
Ad oggi, sono stati individuati dei trojan ma non è da escludere che possano emergere miner, ransomware o altre tipologie di malware che espongono ancora ad altri rischi.
Considerando che non è possibile sapere se il sito che stiamo navigando usa una libreria che include un qualche tipo di malware, nell’immediato probabilmente assisteremo a diversi furti di credenziali e/o di identità e sarà complesso se non impossibile capire come, dove e quando questo è avvenuto.
Per dare un’idea della portata basta pensare che librerie come UAParser è ampiamente utilizzata da Microsoft e Meta (Facebook), Amzon e Reddit, insomma dai colossi del web.
Le soluzioni di mitigazione
Dal punto di vista dell’utente, non potendo sapere a priori quali siti possono diffondere un malware, è fondamentale mantenere aggiornati antivirus, browser e sistema operativo. Il primo perché sarà in grado di individuare eventuali comportamenti anomali sulla macchina; il secondo e il terzo perché correggono le falle sfruttate dal malware.
Per quanto riguarda le aziende che, come le best practice di sviluppo suggeriscono, usano queste librerie devono aggiornarle quanto prima con le nuove versioni. È molto comune segnalare la presenza di codice obsoleto e tipicamente vulnerabile quando si eseguono vulnerability assessment o attività di analisi del codice perché spesso aggiornare le librerie significa anche rivedere le porzioni di codice che le usano (magari a causa di un cambiamento nei parametri accettati da alcune funzioni o dal risultato che ritornano).
Bisogna però evidenziare come risparmiare quel tempo e quei soldi possa esporre a diversi rischi a volte anche maggiori e costosi.
Più in generale le aziende che sviluppano soluzioni IT dovrebbero:
- rivalutare la sicurezza delle postazioni di sviluppo, imponendo un aggiornamento costante del sistema operativo, dei compilatori e delle IDE di sviluppo per avere sempre le ultime patch di sicurezza;
- rivalutare l’uso delle librerie pubbliche cercando di usare sempre l’ultima versione per ogni nuovo progetto e aggiornare periodicamente il “vecchio” codice ancora in produzione;
- valutare l’introduzione di linter, ovvero quelle soluzioni di analisi statica del codice che cercano errori di programmazione, bug, costrutti sospetti (ma possono essere usati anche per uniformare lo stile dello sviluppo portando quindi benefici alla leggibilità del codice da parte del team di sviluppo);
- valutare l’introduzione di strumenti di source code analysis in fase di build, anche facilmente automatizzabili per le aziende che hanno adottato un approccio DevOps;
- per chi ha un proprio repository del codice, verificare periodicamente chi fa i rilasci e quando o adottare delle procedure e dei meccanismi di approvazione del rilascio per limitare i supply chain attack o compromissioni sulle macchine degli sviluppatori;
- implementare dei meccanismi di code review, magari facendo verificare il codice da altre persone.
Queste sono alcune delle possibili soluzioni che andrebbero comunque valutate caso per caso.
Restano chiaramente valide tutte quelle soluzioni di endpoint protection e firewall anche sui server, IDR/EDR e soluzioni di log analysis e correlation che permettono di individuare, mitigare e risolvere eventuali attacchi in corso.
Conclusioni
Cosa ci si aspetta nel prossimo futuro? I produttori delle IDE di sviluppo dovranno sicuramente individuare un modo migliore per visualizzare il codice, facilitando gli sviluppatori nello scoprire eventuali anomalie.
Inoltre, anche i sistemi di source code analysis si dovranno evolvere sia per individuare queste potenziali anomalie ma anche per aumentare il livello di trust di chi pubblica.
Sembrano invece ancora molto lontane delle soluzioni che possano almeno avvisare gli sviluppatori che la libreria che hanno utilizzato presenta delle vulnerabilità
