Un attacco omografo registra un dominio costruito con caratteri che sembrano identici a quelli di un dominio reale ma non lo sono - una "a" cirillica al posto di una "a" latina, per esempio - così l'indirizzo che una persona legge e l'indirizzo che un browser risolve sono due cose diverse. Il trucco funziona perché il sistema dei nomi di dominio comprende solo l'ASCII, quindi ogni dominio non-ASCII viene tradotto in una forma ASCII chiamata punycode, contrassegnata da un prefisso xn--, prima ancora di toccare il DNS. I browser la decodificano di nuovo nella versione leggibile per la visualizzazione, ed è esattamente in quel passaggio di decodifica che si nasconde l'inganno.
I browser moderni oggi intercettano i casi più evidenti e mostrano il punycode grezzo quando un'etichetta mescola alfabeti in modo sospetto, chiudendo la porta alla maggior parte degli attacchi semplici che funzionavano un decennio fa. Ma quella protezione non esce dalla barra degli indirizzi del browser.
Analizzo casi di spoofing di marchi per mestiere, e le contraffazioni ben fatte mi catturano ancora l'occhio per una frazione di secondo prima che il dettaglio rivelatore si registri. Questo articolo copre come funziona un attacco omografo, dove si ferma la difesa del browser e cosa fare al riguardo - sia che tu stia per cliccare, sia che tu possieda il dominio che viene contraffatto. Per la domanda più ampia se i link brevi in sé siano affidabili, gli abbreviatori URL sono sicuri copre quel terreno; questo articolo riguarda il dominio che sta sotto il link.
Cos'è punycode e perché esiste
Il DNS è stato costruito per l'ASCII, punto. Non ha un modo nativo per memorizzare le lettere accentate, i caratteri cirillici, arabi o cinesi che compongono la maggior parte dei sistemi di scrittura del mondo, il che è diventato un problema reale nel momento in cui la registrazione dei domini si è aperta oltre i mercati anglofoni.
Punycode è la soluzione: una codifica reversibile, standardizzata come RFC 3492, che converte un'etichetta Unicode in lettere, cifre e trattini ASCII che il DNS può trasportare senza alcuna modifica al protocollo di trasmissione. Un panificio tedesco che registra un dominio con una dieresi, o un rivenditore ucraino che ne registra uno in cirillico, ottiene un nome di dominio internazionalizzato funzionante che si risolve esattamente come qualsiasi altro, perché sotto è solo un'altra etichetta ASCII. La forma codificata inizia sempre con xn--, a segnalare "questo è punycode, decodificalo prima di mostrarlo a una persona."
Niente di tutto ciò è di per sé una vulnerabilità - i nomi di dominio internazionalizzati sono una funzionalità autentica e necessaria, non un workaround che qualcuno dovrebbe disabilitare. Il problema inizia un livello più su, nel momento in cui un browser decide come mostrarti di nuovo quel nome decodificato.
Come funziona un attacco omografo
Un attacco omografo sfrutta il divario tra ciò che un dominio contiene e il suo aspetto una volta visualizzato. In natura si presentano due varianti, e non sono ugualmente comuni.
La versione a script intero registra un intero dominio in un alfabeto non latino le cui forme delle lettere assomigliano al marchio bersaglio. È vistosa da costruire e più facile da intercettare per chi si difende, dato che l'intera etichetta è estranea.
La versione a script misto è quella che viene effettivamente usata, perché richiede una sola sostituzione. Prendi un dominio come novacloud.com. Sostituisci la "o" latina con la "о" cirillica visivamente identica (U+043E) e ottieni nоvacloud.com - stessa forma, stessa lunghezza, code point diverso, e un dominio che si codifica in xn--nvacloud-nbh.com. Tutto il resto dell'etichetta resta intatto, quindi l'occhio non ha quasi nulla da notare. I ricercatori di sicurezza chiamano questo tipo di coppia sosia un "confusable", e una manciata di essi copre la maggior parte dell'alfabeto latino.
Una volta registrato il dominio, il resto dell'attacco è phishing ordinario: una pagina di login copiata pixel per pixel, un messaggio urgente che punta al link contraffatto, e un bersaglio che non ha motivo di dubitare di un indirizzo che sembra perfettamente corretto.
Cosa fanno oggi i browser al riguardo
I produttori di browser hanno chiuso anni fa la maggior parte della versione semplice di questo attacco con una regola su quali alfabeti possono mescolarsi in un'unica etichetta. La policy di Chrome, documentata nella sua guida alla gestione IDN, verifica se ogni carattere di un'etichetta appartiene plausibilmente a un solo alfabeto, o a un piccolo insieme di combinazioni di alfabeti che compaiono legittimamente insieme, come i kanji giapponesi con l'hiragana. Se gli alfabeti si mescolano al di fuori di quell'insieme consentito, il browser mostra la forma xn-- grezza invece di decodificarla - il miglior punto di forza dell'attacco, un dominio che sembra completamente normale, torna a essere una stringa palesemente codificata. Firefox esegue un controllo analogo, descritto nell'algoritmo di visualizzazione IDN di Mozilla, e Safari applica una propria versione.
Non è una protezione completa. Un'etichetta a script misto costruita solo con caratteri all'interno di una combinazione consentita può comunque passare come un nome leggibile e ingannevole, e la regola viene applicata browser per browser, senza un'autorità condivisa che decida cosa sia considerato sicuro.
Dove si ferma quella protezione
Il controllo sulla mescolanza di alfabeti risiede nel codice di rendering della barra degli indirizzi del browser. Non viaggia con l'URL altrove, ed è proprio in quel divario che un dominio contraffatto continua a fare danni reali.
I client di posta elettronica rappresentano l'esposizione maggiore: un messaggio può mostrare qualsiasi testo di ancoraggio sopra un link indipendentemente dalla destinazione, e la maggior parte delle app di posta non esegue alcun controllo sui confusable. Le app di chat trasformano un link condiviso in una scheda di anteprima costruita dai metadati della pagina, non da un renderer consapevole di punycode. I codici QR eliminano del tutto il passaggio testuale, un divario che trattiamo in i codici QR sono sicuri, e il materiale stampato non ha alcuno strato software tra l'occhio e l'inganno.
| Canale | Mostra la destinazione reale prima che tu agisca | Esposizione tipica |
|---|---|---|
| Browser desktop moderno | Di solito, tramite regole sulla mescolanza di alfabeti | Bassa per i browser comuni, mantenuti aggiornati |
| Client di posta elettronica | Raramente - il testo di ancoraggio può dire qualsiasi cosa | Alta, specialmente sulle app di posta mobile |
| App di chat e messaggistica | Raramente - le anteprime dei link usano i metadati della pagina | Alta, le anteprime dei link sembrano identiche |
| Codice QR | No - non viene visualizzato nulla prima della scansione | Alta, la decisione avviene in una frazione di secondo |
| Materiale stampato | Mai - non è coinvolto alcun software | Massima, nessun controllo tecnico è possibile |
Se il tuo team invia link sotto un dominio che i tuoi clienti già riconoscono, un sosia contraffatto ha molto meno margine per imitarti in modo convincente su tutti quei canali contemporaneamente. Scopri come funziona un dominio brandizzato personalizzato su Elido se stai ancora inviando link da un dominio condiviso o generico.
Perché un dominio brandizzato è la tua migliore difesa
Un attacco omografo funziona sfruttando la familiarità - ha bisogno di un marchio riconoscibile da contraffare. Sembra un argomento contro la costruzione di un dominio riconoscibile tutto tuo, ed è l'esatto contrario. Un link breve brandizzato distintivo che il tuo pubblico associa già a te è qualcosa con cui può confrontare un messaggio sospetto; un dominio di abbreviazione generico o preso in prestito offre a un aggressore un modello che i clienti non riescono comunque a distinguere dal vero fornitore, perché nessuno dei due assomiglia a "te."
Configurare un dominio personalizzato per i link brevi significa che ogni link che invii porta un nome che i destinatari riconoscono, il che alza l'asticella per chiunque cerchi di contraffarlo. Vale la pena distinguerlo dal cloaking dei link e mascheramento degli URL, una scelta deliberata e dichiarata di instradare i link attraverso il proprio dominio. Un attacco omografo è la mossa opposta - nascondere l'identità dell'aggressore imitando la tua - e la difesa è la trasparenza su quale dominio sia effettivamente tuo.
I controlli del registrar che contano davvero
Due controlli fanno la maggior parte del lavoro reale una volta che possiedi un dominio che vale la pena proteggere, e operano a livelli diversi dello stack.
Il registrar lock è quello di uso quotidiano - un flag di stato, spesso mostrato come clientTransferProhibited, che blocca le richieste di trasferimento automatico di routine all'interno della dashboard del tuo registrar. Ogni dominio che usi attivamente dovrebbe averlo attivato; non costa nulla. Il registry lock si colloca un livello più in alto, coinvolgendo direttamente l'operatore del registro in modo che qualsiasi modifica, trasferimento o cancellazione richieda una verifica manuale fuori banda - una telefonata o una passphrase sicura - prima di entrare in vigore. Quell'attrito è giustificato solo per il dominio, o i due domini al massimo, in cui una modifica non autorizzata sarebbe genuinamente costosa, il che per la maggior parte delle aziende significa come minimo il dominio del marchio principale.
Nessuno dei due blocchi impedisce a qualcuno di registrare un dominio sosia accanto al tuo. Per questo serve un monitoraggio attivo: tenere d'occhio le nuove registrazioni di domini e i log pubblici di certificate transparency alla ricerca di nomi visivamente vicini al tuo marchio, così da poterlo segnalare al registrar o avvisare i clienti prima che una campagna che lo usa raggiunga qualcuno.
Cosa inserire in una policy di brand protection
Se possiedi un dominio che vale la pena contraffare, la sezione sicurezza della tua policy di brand protection dovrebbe essere abbastanza specifica da permettere a qualcuno nuovo del team di eseguirla senza doverti chiedere prima.
- Blocco di trasferimento del registrar su ogni dominio posseduto dall'azienda, con registry lock aggiunto sul dominio del marchio principale e su tutto ciò che gestisce pagamenti o login.
- Una cadenza ricorrente per scansionare le nuove registrazioni di domini e i log di certificate transparency alla ricerca di nomi visivamente vicini al tuo marchio, non un controllo una tantum.
- Registrazione difensiva delle etichette sosia a più alto rischio e dei domini di primo livello confusable che puoi giustificare, dando priorità in base a quanto assomigliano al tuo dominio principale.
- Un responsabile nominato e un percorso di escalation per segnalare al registrar un dominio sosia scoperto, oltre a linee guida interne affinché il personale di supporto riconosca lo schema quando un cliente ne segnala uno. La checklist di sicurezza per scegliere un fornitore di link copre i controlli adiacenti sui fornitori.
Una procedura di verifica che chiunque può seguire
Non devi capire il punycode per controllare un link in sicurezza. Quattro passaggi, eseguiti in ordine, intercettano quasi tutto ciò su cui fa affidamento un attacco omografo.
- Espandi prima il link, invece di cliccarci direttamente. Come vedere dove porta un URL breve illustra gli strumenti per farlo, e il link checker di Elido fa la stessa cosa senza chiederti di fidarti prima della destinazione.
- Leggi il dominio registrabile - la parte immediatamente prima del dominio di primo livello - piuttosto che qualsiasi cosa appaia prima. È quella la parte che un aggressore deve controllare interamente.
- Controlla la presenza di un prefisso xn--, sia nell'URL espanso grezzo sia nella barra degli indirizzi del tuo browser. Se ne vedi uno dove ti aspettavi un nome di marchio semplice, fermati e trattalo come un sosia finché non è dimostrato il contrario.
- Conferma il nome sul certificato del sito di destinazione. Un certificato riflette ciò che è stato effettivamente rilasciato al proprietario di un dominio, il che è più difficile da falsificare in modo convincente rispetto a un'etichetta visualizzata.
Nessuno di questi passaggi richiede più di pochi secondi una volta diventati abitudine, e puoi insegnare tutti e quattro a un collega non tecnico nel tempo necessario a leggere questa sezione una sola volta.
Un attacco omografo è un problema di visualizzazione travestito da problema di sicurezza. Punycode sta facendo esattamente ciò per cui è stato progettato; l'inganno avviene nel divario tra ciò che un dominio è e ciò che un software ti mostra al suo posto. I browser hanno chiuso la maggior parte di quel divario per la barra degli indirizzi. Ovunque altrove il divario resta aperto, ed è per questo che espandere un link e leggere il dominio registrabile resta l'abitudine che funziona indipendentemente dal canale che ti ha messo il link davanti.
Articoli correlati sul blog
Domande frequenti
Che cos'è un attacco omografo IDN?
Un attacco omografo IDN registra un dominio usando caratteri di un alfabeto diverso che appaiono identici o quasi identici a quelli di un dominio reale, così che un lettore non riesce a distinguerli a occhio. Il caso classico sostituisce una singola lettera latina con un sosia cirillico o greco, ad esempio la a cirillica al posto della a latina, mentre tutto il resto del dominio resta invariato. Poiché il carattere sostitutivo ha un code point diverso alla base, i due domini sono tecnicamente distinti e possono essere registrati e controllati da proprietari diversi. L'attacco funziona esclusivamente sull'aspetto visivo, ed è per questo che prende di mira nomi di marchi riconoscibili e affidabili, non quelli oscuri.
Che cos'è punycode e perché esiste?
Punycode è la codifica che trasforma le etichette di dominio non-ASCII in una stringa ASCII che il sistema dei nomi di dominio può memorizzare e risolvere, definita nella RFC 3492. Esiste perché il DNS comprende solo un set limitato di caratteri ASCII, quindi un dominio scritto in cirillico, arabo, cinese, o con lettere latine accentate deve essere tradotto in quella forma prima di poter essere risolto. L'etichetta codificata inizia sempre con il prefisso xn--, che indica ai resolver e ai browser che ciò che segue è una stringa codificata in punycode e non un nome ASCII semplice. I browser poi la decodificano di nuovo nell'alfabeto originale per la visualizzazione, il che è una funzionalità legittima e necessaria, non la vulnerabilità in sé.
Cosa significa il prefisso xn-- in un URL?
Il prefisso xn-- contrassegna un'etichetta di dominio come ASCII Compatible Encoding, prodotta da punycode, segnalando che il nome leggibile è stato tradotto da caratteri non-ASCII. Tutto ciò che segue il prefisso è la forma codificata dell'etichetta originale - xn--nvacloud-nbh.com, per esempio, si decodifica in un dominio che appare come novacloud.com con una lettera sostituita da un sosia. Vedere la forma xn-- dove ti aspettavi un nome di marchio semplice è esattamente il segnale che i browser usano per avvertirti, perché significa che l'etichetta mescolava alfabeti in un modo che il browser non ha considerato sicuro da mostrare nella versione leggibile. Un dominio senza caratteri non-ASCII non produce mai una forma xn--, quindi vederne una merita sempre un secondo sguardo.
I browser proteggono dagli attacchi omografi?
I browser moderni applicano regole sulla mescolanza di alfabeti che intercettano la maggior parte dei tentativi omografi e mostrano la forma punycode grezza invece di quella ingannevole. Chrome e Firefox verificano entrambi se i caratteri dell'etichetta di un dominio appartengono plausibilmente a un solo alfabeto o a un piccolo insieme di alfabeti comunemente usati insieme, e in caso contrario mostrano la versione xn-- invece di decodificarla in qualcosa che potrebbe passare per un nome familiare. Questo blocca gli attacchi più semplici, quelli in un unico alfabeto estraneo, impedendo che vengano mostrati come impostori convincenti, anche se gli aggressori possono comunque trovare, all'interno degli alfabeti consentiti, caratteri visivamente confondibili con le lettere latine. La protezione è inoltre strettamente limitata alla barra degli indirizzi del browser - nient'altro nello stack la eredita automaticamente.
Come posso capire se un link è un dominio sosia prima di cliccarci?
Espandi prima il link, così vedi la destinazione completa invece di una versione breve o troncata, poi leggi il dominio registrabile piuttosto che qualsiasi cosa venga prima. Se la barra degli indirizzi o lo strumento di espansione mostra un prefisso xn-- dove ti aspettavi un nome di marchio semplice, trattalo come un dominio sosia finché non è dimostrato il contrario. Confermare il nome sul certificato del sito di destinazione è un utile controllo finale, poiché un certificato riflette ciò che è stato effettivamente rilasciato e non semplicemente ciò che viene mostrato. Nulla di tutto questo richiede software speciale - solo l'abitudine di farlo prima di inserire una password o un numero di carta.
Cos'è il registry lock e il mio dominio ne ha bisogno?
Il registry lock è un controllo impostato a livello di registro del dominio che blocca qualsiasi modifica, trasferimento o cancellazione di un dominio finché non viene verificato manualmente fuori banda, in genere per telefono o con una passphrase sicura, il che impedisce anche a un account registrar compromesso di spostare il dominio. È una garanzia più forte del più comune registrar lock, che impedisce solo i trasferimenti automatici di routine all'interno della tua dashboard del registrar. Il registry lock vale il suo modesto costo annuale per qualsiasi dominio la cui inattività o sottrazione sarebbe costosa, il che per la maggior parte delle aziende significa come minimo il dominio del marchio principale. Non impedisce a qualcuno di registrare un dominio dall'aspetto simile accanto al tuo - quello è un problema separato risolto dal monitoraggio, non dal blocco.
Prova Elido
Incolla un URL, ottieni un link breve
Senza registrazione. Il link vive 30 giorni. Iscriviti per conservarlo.
Gratis, nessuna registrazione richiesta · 2 al giorno