Attacchi omografi IDN: come i caratteri "gemelli" ingannano i tuoi utenti (e come fermarli)

Un dipendente riceve un'email da un dominio che conosce bene, clicca e il sito è identico all'originale, con il lucchetto SSL verde e attivo, eppure le credenziali inserite finiscono nelle mani sbagliate. Non è un errore umano, è un attacco omografo, e il certificato SSL valido non c'entra nulla con l'autenticità del dominio.

In parole semplici: immagina di dover distinguere due gemelli identici solo dal loro nome scritto su un badge, ma qualcuno ha stampato uno dei due badge con un font leggermente diverso, invisibile a occhio nudo. Per te sono la stessa persona, ma il sistema che controlla gli accessi li riconosce come due individui completamente diversi. Con i siti internet succede la stessa cosa: alcune lettere di alfabeti diversi (come il cirillico o il greco) sono disegnate in modo identico alle nostre lettere latine, ma per il computer sono caratteri differenti, quindi un indirizzo web può sembrare quello della tua banca o del tuo fornitore ed essere invece un sito costruito apposta per rubare le tue credenziali.

Cosa sono gli attacchi omografi IDN

Un IDN Homograph Attack sfrutta i domini internazionalizzati (IDN), lo standard che permette di registrare indirizzi web con caratteri non latini come il cirillico, il greco o gli alfabeti estesi, e il problema è che molti di questi caratteri sono, a livello visivo, indistinguibili dalle lettere latine standard, pur avendo un codice Unicode completamente diverso.

Per un occhio umano le due stringhe sono identiche. Per DNS e browser sono due domini completamente distinti, con proprietari, certificati e infrastrutture diverse. Il meccanismo che rende tutto questo possibile si chiama Punycode, ovvero la rappresentazione ASCII di un dominio Unicode, riconoscibile dal prefisso xn--. Ogni volta che digiti un IDN, il browser lo traduce internamente in Punycode per interrogare il DNS, per poi ri-mostrartelo in Unicode nell'indirizzo, ed è proprio in questo passaggio di traduzione visiva che si nasconde il rischio.

Non è una teoria, i precedenti sono reali

Il problema non è nuovo. Nel 2005 il ricercatore Eric Johanson dimostrò a ShmooCon che Firefox 1.0, Safari 1.2.5 e Opera 7.54 mostravano come autentico un dominio PayPal contraffatto con una "a" cirillica al posto di quella latina. Nel 2017 Xudong Zheng registrò un dominio Punycode che i principali browser convertivano in una versione visivamente identica ad apple.com, riaprendo pubblicamente la questione, e sempre nel 2017 il ricercatore Ankit Anubhav individuò una campagna che sfruttava un dominio omografo di Adobe per distribuire il trojan Betabot. Da allora Chrome, Firefox e gli altri browser hanno rafforzato i controlli, ma nessuna protezione nativa è infallibile al cento per cento, soprattutto fuori dal browser, perché email, social e messaggistica restano vettori scoperti.

Come difendere utenti e infrastrutture: tre livelli di controllo

1. Forzare la visualizzazione in Punycode

Chrome e Safari applicano già in modo nativo un rilevamento dei mix di alfabeti sospetti, il cosiddetto mixed-script detection, e mostrano il Punycode quando un dominio appare ambiguo. Firefox invece non lo fa di default, e l'opzione che forza sempre la visualizzazione in Punycode si chiama network.IDN_show_punycode ed è disattivata per impostazione predefinita, quindi per attivarla su un parco browser aziendale va impostata su true in about:config, oppure distribuita via policy con il file mozilla.cfg per tutta l'organizzazione.

2. Controlli lato endpoint e DNS

I filtri DNS e il safe browsing bloccano gran parte dei domini malevoli noti, ma non sempre intercettano un dominio omografo appena registrato, quindi un secondo livello di verifica, a livello di endpoint, che analizzi in tempo reale il set di caratteri effettivamente usato nella pagina o nel dominio visitato, permette di intercettare mix anomali di alfabeti prima che l'utente inserisca dati sensibili.

3. Strumenti di analisi per incident response

In fase di investigazione, l'URL va scomposto nei suoi singoli code point Unicode e non semplicemente letto. CyberChef, lo strumento open source sviluppato da GCHQ, include l'operazione dedicata "To Punycode" (e la sua inversa "From Punycode") proprio per questo tipo di analisi, e permette di individuare esattamente quale carattere, di quale alfabeto, è stato sostituito: un passaggio utile per motivare un blocco a livello di firewall o EDR durante una perizia o un'indagine forense.

Le domande che le persone cercano su Google

Domande frequenti

Riconoscere un attacco omografo a occhio nudo è, per definizione, quasi impossibile, ed è un problema di configurazione tecnica e di processo prima ancora che di attenzione individuale. Quando un dominio sospetto è già stato cliccato, o quando serve ricostruire con precisione come un attacco di questo tipo si è verificato all'interno della tua organizzazione, la parte più delicata non è la teoria ma la prova: individuare i code point esatti usati, ricostruire la cronologia degli accessi, mettere tutto nero su bianco in una forma che regga anche in sede legale. È esattamente il lavoro che facciamo con le nostre attività di digital forensics e incident response, dall'analisi tecnica del dominio fino alla perizia utilizzabile a supporto di denunce, cause civili o procedimenti assicurativi.

Articoli correlati

Se il tema della sicurezza digitale ti interessa, qui trovi altri approfondimenti utili, oltre ai servizi con cui Alchimie Digitali affianca le aziende su questo fronte, dai test di phishing simulato alla formazione anti-phishing rivolta sia agli addetti che al board.