Come un dominio identico all’originale, con certificato SSL valido, può rubare le credenziali senza che nessun sistema dia l’allarme.
Lo scenario
L’utente riceve un’email apparentemente proveniente da bankofamerica.com. Il messaggio è ben scritto, il logo è corretto, il tono è quello istituzionale a cui è abituato. Clicca sul link.
Il sito che si apre è identico all’originale, pixel per pixel. Il certificato SSL è valido: il lucchetto verde è al suo posto, il browser non mostra alcun avviso. L’utente inserisce le proprie credenziali, che vengono immediatamente sottratte dall’attaccante.
Non si tratta di phishing classico basato su domini palesemente diversi (es. bank0famerica-login.com), né di un certificato contraffatto. Il dominio, così come appare, è visivamente indistinguibile da quello legittimo. La tecnica alla base si chiama IDN Homograph Attack.
Che cos’è un IDN Homograph Attack
Gli IDN (Internationalized Domain Names) permettono di registrare domini contenenti caratteri non ASCII: cirillico, greco, armeno e altri alfabeti Unicode. Il sistema DNS, però, lavora solo in ASCII, quindi ogni carattere Unicode viene tradotto internamente in una stringa Punycode, riconoscibile dal prefisso xn--.
Molti alfabeti condividono glifi visivamente identici o quasi identici ai caratteri latini. La lettera “a” latina e la “а” cirillica, ad esempio, sono praticamente indistinguibili a occhio nudo nella maggior parte dei font, ma per il sistema DNS sono due caratteri completamente diversi, e quindi due domini completamente diversi.
L’attaccante registra un dominio che, ai nostri occhi, sembra identico a quello di una banca, di un corriere o di un fornitore di servizi, ma che nella codifica reale è un dominio nuovo, di sua proprietà, per il quale può ottenere legittimamente un certificato SSL.
| Elemento | Dominio legittimo | Dominio homograph |
|---|---|---|
| Dominio visualizzato | apple.com | apple.com (con “a” cirillica) |
| Codifica reale (Punycode) | apple.com | xn--pple-43d.com |
| Certificato SSL | Valido, emesso a CA legittima | Valido, emesso al truffatore (dominio è suo!) |
| Lucchetto nel browser | Verde / presente | Verde / presente |
| Contenuto della pagina | Originale | Clone pixel-perfect |
Perché il certificato SSL non aiuta
Le Certification Authority moderne (Let’s Encrypt in primis) rilasciano certificati di dominio in modo automatizzato, verificando esclusivamente che il richiedente controlli il dominio in questione, non che il dominio sia “legittimo” nel senso commerciale del termine. Se l’attaccante è il proprietario registrato di xn--pple-43d.com, ha pieno diritto a un certificato SSL valido per quel dominio.
Il lucchetto verde certifica quindi che la connessione è cifrata e che il richiedente controlla il dominio visualizzato, non che il sito appartenga all’azienda che l’utente crede di star visitando. È un errore di interpretazione comune, e proprio per questo l’attacco homograph risulta particolarmente efficace anche su utenti mediamente attenti.
⚠ ATTENZIONE
Il lucchetto SSL indica solo che il traffico è cifrato tra il browser e il server che risponde a quel dominio. Non garantisce in alcun modo l’identità reale del proprietario del sito.
Come si riconosce (o si previene) nella pratica
I browser moderni (Chrome, Firefox, Edge) applicano policy di visualizzazione Punycode: se un dominio mescola alfabeti diversi in modo sospetto, spesso lo mostrano già in forma xn--... invece che nella forma Unicode ingannevole. Questa protezione, tuttavia, non copre tutti i casi, in particolare quando il dominio usa un solo alfabeto alternativo in modo coerente (es. tutto cirillico), che alcuni browser continuano a rendere in Unicode.
- Controllare l’URL carattere per carattere quando si accede a servizi sensibili (home banking, posta, gestionali), preferibilmente digitandolo o usando un segnalibro salvato in precedenza.
- Copiare l’URL sospetto in un editor di testo semplice: alcuni editor e alcune barre degli indirizzi mostrano differenze di font tra alfabeti diversi che ad occhio nudo passano inosservate.
- Verificare il dominio tramite un servizio di conversione Punycode (ricerca “punycode converter”) prima di inserire credenziali su un link ricevuto via email.
- Attivare, dove disponibile, le protezioni anti-phishing del browser e i filtri DNS aziendali che bloccano i domini xn-- non presenti in whitelist.
- Adottare l’autenticazione a due fattori (2FA) su tutti i servizi critici: anche in caso di furto della password, il secondo fattore riduce drasticamente il danno.
- Diffidare sempre dai link ricevuti via email per servizi finanziari: digitare manualmente l’indirizzo noto è la contromisura più efficace ed economica.
| ✔ FARE | ✘ NON FARE |
|---|---|
| Digitare manualmente l’indirizzo di banche e servizi sensibili | Cliccare link a servizi finanziari ricevuti via email |
| Verificare il dominio reale (Punycode) prima di inserire credenziali | Fidarsi del solo lucchetto verde come prova di autenticità |
| Usare un password manager (compila solo sul dominio corretto) | Riutilizzare la stessa password su più servizi |
| Attivare 2FA su tutti gli account critici | Ignorare avvisi del browser relativi a domini IDN |
| Segnalare email sospette all’IT o al proprio fornitore di sicurezza | Inserire credenziali su siti raggiunti da link esterni non verificati |
Implicazioni per aziende e call center
Per realtà che gestiscono grandi volumi di comunicazioni verso clienti, come i call center, il rischio si estende su due fronti: da un lato gli operatori possono essere bersaglio di campagne mirate (spear phishing) che sfruttano domini homograph per rubare credenziali di accesso ai gestionali; dall’altro, i clienti finali possono ricevere comunicazioni fraudolente che imitano il brand aziendale stesso, con conseguenti danni reputazionali.
Le contromisure aziendali più efficaci restano la configurazione DNS con blocco selettivo dei domini punycode non whitelistati, la formazione periodica del personale e la registrazione difensiva delle varianti homograph più plausibili del proprio dominio, pratica adottata da molti istituti finanziari proprio per contrastare questo tipo di attacco.
In sintesi
L’IDN Homograph Attack dimostra che la sicurezza percepita (lucchetto verde, aspetto grafico identico) non coincide necessariamente con la sicurezza reale. La difesa più solida resta l’abitudine a verificare l’indirizzo effettivo prima di inserire dati sensibili, unita a strumenti tecnici (filtri DNS, 2FA, policy browser aggiornate) che riducano la superficie di attacco anche quando l’errore umano è dietro l’angolo.
Docline Service & Networking supporta le aziende nella configurazione di filtri DNS, policy anti-phishing e formazione del personale contro le minacce basate su domini ingannevoli.