Impianti invisibili nel codice sorgente

Gli esperti dell’Università di Cambridge hanno descritto una vulnerabilità che dicono colpisca la maggior parte dei compilatori moderni. Un nuovo metodo di attacco utilizza una caratteristica legittima dei tool di sviluppo per cui il codice sorgente mostra una cosa ma compila qualcosa di completamente diverso. Succede Il tutto avviene attraverso la i caratteri di controllo Unicode.

Caratteri di formattazione della modalità Unicode rilevanti per gli attacchi di riordino. Fonte

La maggior parte delle volte, i caratteri di controllo non appaiono sullo schermo con il resto del codice (anche se alcuni editor li visualizzano), ma modificano il testo in qualche modo. Questa tabella contiene i codici per l’algoritmo Unicode Bidirezionale (bidi), per esempio.

Come probabilmente sapete, alcune lingue umane sono scritte da sinistra a destra (ad esempio, l’inglese), altre da destra a sinistra (ad esempio, l’arabo). Quando il codice contiene solo una lingua, non c’è problema, ma quando è necessario, quando, per esempio, una riga contiene parole in inglese e in arabo, i codici bidi specificano la direzione del testo.

Esempio di codice Python vulnerabile usando i codici bidi. Fonte.

A destra è la versione che i programmatori vedono quando controllano il codice sorgente; a sinistra si mostra come il codice verrà eseguito. La maggior parte dei compilatori ignora i caratteri di controllo. Chiunque controlli il codice penserà che la quinta linea sia un innocuo commento, anche se in realtà, una dichiarazione di ritorno anticipato nascosta all’interno farà sì che il programma salti l’operazione che addebita i fondi del conto bancario. In questo esempio, in altre parole, il programma bancario simulato erogherà denaro ma non ridurrà il saldo del conto.

Perché è pericoloso?

A prima vista, la vulnerabilità sembra troppo semplice. Chi inserirebbe caratteri invisibili, sperando di ingannare i revisori del codice sorgente? Tuttavia, il problema è stato ritenuto abbastanza serio da giustificare un identificatore di vulnerabilità (CVE-2021-42574). Prima di pubblicare il documento, gli autori hanno avvisato gli sviluppatori dei compilatori più comuni, dando loro il tempo di preparare le patch.

Il rapporto delinea le capacità di attacco di base. Le due strategie di esecuzione sono nascondere un comando all’interno dei commenti, e nascondere qualcosa in una linea che, per esempio, appare sullo schermo. È possibile, in teoria, ottenere l’effetto opposto: creare del codice che sembra un comando, ma in realtà fa parte di un commento e non verrà eseguito. Metodi ancora più creativi per sfruttare questa debolezza sono destinati ad esistere.

Per esempio, qualcuno potrebbe usare il trucco per portare avanti un sofisticato attacco alla supply chain in cui un appaltatore fornisce a una società un codice che sembra corretto ma non funziona come previsto. Poi, dopo che il prodotto finale viene rilasciato, una parte esterna può utilizzare la “funzionalità alternativa” per attaccare i clienti.

Quanto è pericoloso, in realtà?

Poco dopo la pubblicazione del documento, il programmatore Russ Cox ha criticato l’attacco Trojan Source. Non era convinto, per usare un eufemismo. I suoi argomenti sono i seguenti:

• Non è affatto un nuovo attacco;
• Molti editor di codice usano l’evidenziazione della sintassi per mostrare il codice “invisibile”;
• Le patch per i compilatori non sono necessarie, è sufficiente controllare attentamente il codice per rilevare qualsiasi bug accidentale o malevolo.

Infatti, il problema con i caratteri di controllo Unicode è emerso, per esempio, già nel 2017. Inoltre, un problema simile con gli homoglyph (omogenei), caratteri che sembrano gli stessi ma hanno codici diversi, non è nuovo e può anche servire a far passare codice estraneo ai controlli manuali.

Tuttavia, l’analisi critica di Cox non nega l’esistenza del problema, ma piuttosto condanna i report come eccessivamente drammatici, una caratterizzazione appropriata, per esempio, dell’apocalittico Bug “Trojan Source” del giornalista Brian Krebs che minaccia la sicurezza di tutto il codice.

Il problema è reale, ma fortunatamente la soluzione è abbastanza semplice. Tutte le patch già uscite o attese a breve bloccheranno la compilazione di codice contenente tali caratteri (vedete, per esempio, questo avviso di sicurezza dagli sviluppatori del compilatore Rust). Se usate i vostri tool di compilazione del software, vi raccomandiamo di aggiungere un controllo simile per i caratteri nascosti, che normalmente non dovrebbero essere presenti nel codice sorgente.

Il pericolo degli attacchi alla supply-chain

Molte aziende esternalizzano i compiti di sviluppo a contraenti o usano moduli open-source già pronti nei loro progetti. Questo apre sempre la porta agli attacchi attraverso la supply chain. I criminali informatici possono compromettere un appaltatore o incorporare il codice in un progetto open-source e inserire codice dannoso nella versione finale del software. Le verifiche del codice in genere rivelano tali backdoor, ma se non lo fanno, gli utenti finali possono ottenere software da fonti affidabili ma perdere comunque i loro dati.

Trojan Source è un esempio di un attacco molto più elegante. Invece di cercare di contrabbandare megabyte di codice dannoso in un prodotto finale, i cybercriminali possono usare un approccio del genere per introdurre un impianto difficile da rilevare in una parte critica del software e sfruttarlo per gli anni a venire.

Come rimanere al sicuro

Per difendervi dagli attacchi di tipo Trojan Source:

• Aggiornate tutti i compilatori di linguaggi di programmazione che usate (se è già stata rilasciata una patch)
• Compilate i vostri script che rilevano una gamma limitata di caratteri di controllo nel codice sorgente.

Più in generale, la lotta contro i potenziali attacchi alla supply chain richiede sia verifiche manuali del codice che una serie di test automatici. Non fa mai male guardare il proprio codice dalla prospettiva del criminale informatico, cercando di individuare quel semplice errore che potrebbe rompere l’intero meccanismo di sicurezza. Se vi mancano le risorse interne per questo tipo di analisi, prendete in considerazione la possibilità di coinvolgere esperti esterni.