Due ricercatori di Cambridge hanno trovato un nuovo modo di nascondere codice malevolo all’interno del source code delle applicazioni. Piuttosto che utilizzare bug logici, gli avversari possono sfruttare la codifica dei caratteri del codice sorgente per inserire delle vulnerabilità.
Nell’alfabeto latino i testi vengono allineati a sinistra, mentre nelle lingue arabe vengono allineati a destra. Utilizzando l’algoritmo BiDi di Unicode è possibile visualizzare correttamente questi testi. In alcuni casi può capitare che l’algoritmo fallisca, rendendo necessario l’utilizzo di caratteri speciali che hanno come unico scopo quello di forzare l’allineamento del testo nella maniera corretta: questi caratteri sono invisibili “ad occhio nudo“ ;. Un attaccante può utilizzare i caratteri speciali per nascondere del codice malevolo.
La pericolosità della tecnica risiede nella sopravvivenza dei caratteri speciali alla copia, cioè se copiamo del codice artefatto con questa tecnica, sicuramente copieremo anche i caratteri di controllo che non vediamo.
Qui in basso possiamo vedere l’effetto dei caratteri di controllo sulla visualizzazione:
Le tecniche
Vediamo quali sono le tecniche possibili di modifica codice mediante questa meccanica.
Ritorno anticipato: l’istruzione di return appare all’interno di un commento, mentre in realtà si trova effettivamente nel codice che viene compilato.
Istruzioni commentate: parti di codice che sembrano appartenere al codice da compilare ma in realtà non verranno eseguite perché incluse in un commento.
Stringhe allungate: fa apparire le stringhe come uguali ma in realtà restituiranno un valore falso in fase di comparazione logica
La variante
Un attacco simile può essere condotto a partire da stringhe omografe. Per chi di voi ha fatto il liceo classico, parlando di omografi vi verrà in mente il punto interrogativo greco perfettamente uguale al nostro punto e virgola, poco male perché nel caso venisse sostituito in fase di compilazione quest’ultima fallirebbe. Diverso sarebbe se sostituissimo caratteri più usuali
void sayHello() {
std::cout << "Hello, World!\n";
void sayНello() {
std::cout << "Bye, World!\n";
La lettera blu è diversa da quella rossa
void sayhello() {
std::cout << "hello, world!\n";
void sayнello() {
std::cout << "bye, world!\n";
}
Nell’ esempio qui sopra la N russa è stata sostituita con l’H dell’alfabeto latino; questo potrebbe essere usato per richiamare una funzione differente da quella voluta ad esempio:
#include <stdio.h>
void sayHello() {
printf("Hello, World!\n");
void sayНello() {
printf("Goodbye, World!\n");
int main() {
sayНello();
return 0;
Copiare per credere.
Rimedi
Alla luce di questi sviluppi GitHub ha aggiunto un grosso banner a sfondo giallo per avvertire della presenza di eventuali caratteri che cambiano l’orientamento del testo:
Per quanto riguarda i compilatori e gli interpreti che supportano unicode, sarebbe una buona cosa che i produttori di tali strumenti, in linea con quanto ha fatto GitHub, generassero avvisi o errori nel caso ci siano caratteri di controllo direzionale nei commenti; sarebbe opportuno, inoltre, che le specifiche dei linguaggi vietino i caratteri di controllo direzionale.
Speriamo che in un futuro prossimo questi caratteri siano visibili anche in altri repository di codice o in portali di collaborazione tra sviluppatori come stackoverflow, in maniera chiara e a colpo d’occhio.
La medesima tecnica può essere orientata ad altro “sorgente”; un esempio è stato l’attacco del 2018 tramite Telegram, in cui un cryptominer è stato diffuso utilizzando un nome file ingannevole “photo_high_re*U+202E*gnp.js” che veniva “innocentemente” mostrato come “photo_high_resj.png”. Il carattere “*U+202E*” è in questo caso il carattere di inversione RLO.
L’inversione del testo rendeva la parte finale del nome “gnp.js” in “sj.png”, mascherando la vera essenza del file (esistente), ossia un file contenente codice javascript.