Um ataque homográfico registra um domínio construído com caracteres que parecem idênticos aos de um domínio real, mas não são - um "a" cirílico no lugar de um "a" latino, por exemplo - de modo que o endereço que uma pessoa lê e o endereço que um navegador resolve são duas coisas diferentes. O truque funciona porque o sistema de nomes de domínio só entende ASCII, então todo domínio não-ASCII é traduzido para uma forma ASCII chamada punycode, sinalizada com um prefixo xn--, antes mesmo de tocar o DNS. Os navegadores decodificam isso de volta para a versão legível na exibição, e é exatamente nessa etapa de decodificação que mora o engano.
Os navegadores modernos agora capturam os casos óbvios e voltam a mostrar o punycode bruto quando um rótulo mistura escritas de um jeito suspeito, fechando a maioria dos ataques fáceis que funcionavam há uma década. Mas essa proteção não sai da barra de endereço do navegador.
Eu analiso casos de falsificação de marca por profissão, e as boas falsificações ainda me enganam por meio segundo antes de o sinal delator ser percebido. Esta publicação cobre como um ataque homográfico funciona, onde a defesa do navegador para, e o que fazer a respeito - seja porque você está prestes a clicar, seja porque você é dono do domínio sendo falsificado. Para a pergunta mais ampla sobre se os próprios links curtos são confiáveis, os encurtadores de URL são seguros cobre esse terreno; esta publicação é sobre o domínio que fica por baixo do link.
O que é o punycode e por que ele existe
O DNS foi construído para ASCII, ponto final. Ele não tem nenhuma forma nativa de armazenar as letras acentuadas, os caracteres cirílicos, árabes ou chineses que compõem a maior parte dos sistemas de escrita do mundo, o que virou um problema real no momento em que o registro de domínios se abriu para além dos mercados de língua inglesa.
Punycode é a solução: uma codificação reversível, padronizada como RFC 3492, que converte um rótulo Unicode em letras, dígitos e hífens ASCII que o DNS consegue transportar sem nenhuma mudança no protocolo de rede. Uma padaria alemã que registra um domínio com um trema, ou um varejista ucraniano que registra um em cirílico, obtém um nome de domínio internacionalizado funcional que resolve exatamente como qualquer outro, porque por baixo é apenas mais um rótulo ASCII. A forma codificada sempre começa com xn--, sinalizando "isto é punycode, decodifique antes de mostrar a um humano".
Nada disso é uma vulnerabilidade por si só - nomes de domínio internacionalizados são um recurso genuíno e necessário, não uma solução alternativa que alguém deveria desativar. O problema começa uma camada acima, no momento em que um navegador decide como exibir esse nome decodificado de volta para você.
Como funciona um ataque homográfico
Um ataque homográfico explora a lacuna entre o que um domínio contém e a aparência que ele tem depois de renderizado. Duas variantes aparecem na prática, e elas não são igualmente comuns.
A versão de escrita inteira registra um domínio inteiro em uma escrita não latina cujas formas de letra por acaso se parecem com a marca alvo. Ela é chamativa de construir e mais fácil de ser detectada por quem defende, já que o rótulo inteiro é estrangeiro.
A versão de escritas mistas é a que realmente é usada, porque precisa de apenas uma única substituição. Pegue um domínio como novacloud.com. Troque o "o" latino pelo "о" cirílico visualmente idêntico (U+043E) e você obtém nоvacloud.com - mesma forma, mesmo comprimento, ponto de código diferente, e um domínio que se codifica em xn--nvacloud-nbh.com. Tudo o mais no rótulo permanece intocado, então o olho quase não tem nada para identificar. Pesquisadores de segurança chamam esse tipo de par parecido de "confundível", e um punhado deles cobre a maior parte do alfabeto latino.
Depois que o domínio é registrado, o resto do ataque é phishing comum: uma página de login copiada pixel a pixel, uma mensagem urgente apontando para o link falsificado, e um alvo que não tem motivo para duvidar de um endereço que parece perfeitamente correto.
O que os navegadores fazem a respeito hoje
Os fabricantes de navegadores fecharam a maior parte da versão fácil desse ataque anos atrás, com uma regra sobre quais escritas podem se misturar em um único rótulo. A política do Chrome, documentada em seu guia de tratamento de IDN, verifica se todo caractere de um rótulo pertence plausivelmente a uma única escrita, ou a um pequeno conjunto de combinações de escritas que legitimamente aparecem juntas, como o kanji japonês com o hiragana. Misture escritas fora desse conjunto permitido e o navegador mostra a forma bruta xn-- em vez de decodificá-la - o melhor trunfo do ataque, um domínio que parece completamente normal, volta a ser uma string claramente codificada. O Firefox executa uma verificação equivalente, descrita no algoritmo de exibição de IDN da Mozilla, e o Safari aplica sua própria versão.
Não é uma proteção completa. Um rótulo de escritas mistas construído apenas com caracteres dentro de uma combinação permitida ainda pode passar despercebido como um nome legível e enganoso, e a regra é aplicada navegador por navegador, sem nenhuma autoridade compartilhada decidindo o que conta como seguro.
Onde essa proteção para
A verificação de mistura de escritas vive no código de renderização da barra de endereço do navegador. Ela não acompanha a URL para mais lugar nenhum, e é nessa lacuna que um domínio falsificado ainda causa dano real.
Os clientes de e-mail são a maior exposição: uma mensagem pode exibir qualquer texto de âncora sobre um link independentemente do destino, e a maioria dos aplicativos de e-mail não executa nenhuma verificação de confundíveis. Os aplicativos de chat expandem um link compartilhado em um cartão de pré-visualização construído a partir dos metadados da página, não de um renderizador ciente de punycode. Os códigos QR eliminam totalmente a etapa do texto, uma lacuna que cobrimos em os códigos QR são seguros, e o material impresso não tem nenhuma camada de software entre o olho e o engano.
| Canal | Mostra o destino real antes de você agir | Exposição típica |
|---|---|---|
| Navegador de desktop moderno | Geralmente, via regras de mistura de escritas | Baixa para navegadores comuns, mantidos atualizados |
| Cliente de e-mail | Raramente - o texto de âncora pode dizer qualquer coisa | Alta, especialmente em apps de e-mail no celular |
| Apps de chat e mensagens | Raramente - as pré-visualizações usam metadados da página | Alta, os unfurls de link parecem idênticos |
| Código QR | Não - nada é renderizado até depois da leitura | Alta, a decisão acontece em uma fração de segundo |
| Material impresso | Nunca - nenhum software está envolvido | Altíssima, nenhuma verificação técnica é possível |
Se a sua equipe envia links sob um domínio que os seus clientes já reconhecem, um domínio parecido falsificado tem muito menos espaço para imitar você de forma convincente em todos esses canais ao mesmo tempo. Veja como um domínio de marca personalizado funciona na Elido se você ainda está enviando links de um domínio compartilhado ou genérico.
Por que um domínio de marca é a sua melhor defesa
Um ataque homográfico funciona explorando a familiaridade - ele precisa de uma marca reconhecível para falsificar. Isso parece um argumento contra construir um domínio reconhecível próprio, mas é exatamente o contrário. Um link curto de marca distintivo que o seu público já associa a você é algo com que ele pode comparar uma mensagem suspeita; um domínio de encurtador genérico ou emprestado dá a um atacante um modelo que os clientes não conseguem distinguir do provedor real de qualquer forma, porque nenhum dos dois parece "você".
Configurar um domínio personalizado para links curtos significa que todo link que você envia carrega um nome que os destinatários reconhecem, o que eleva a régua para quem tenta falsificá-lo. Vale a pena separar isso do cloaking de links e mascaramento de URL, uma escolha deliberada e declarada de rotear links pelo seu próprio domínio. Um ataque homográfico é o movimento oposto - ocultar a identidade do atacante enquanto imita a sua - e a defesa é a transparência sobre qual domínio é realmente seu.
Os controles de registrador que realmente importam
Dois controles fazem a maior parte do trabalho real depois que você possui um domínio que vale a pena proteger, e eles operam em níveis diferentes da pilha.
O registrar lock é o do dia a dia - um sinalizador de status, geralmente mostrado como clientTransferProhibited, que bloqueia solicitações de transferência automáticas de rotina dentro do próprio painel do seu registrador. Todo domínio que você usa ativamente deveria ter isso ativado; não custa nada. O registry lock fica um nível acima, envolvendo diretamente o operador do registro, de modo que qualquer alteração, transferência ou exclusão exige verificação manual fora de banda - uma ligação telefônica ou uma frase secreta segura - antes de entrar em vigor. Essa fricção pertence a um ou dois domínios em que uma alteração não autorizada seria genuinamente cara, o que para a maioria das empresas significa pelo menos o domínio principal da marca.
Nenhum dos dois bloqueios impede que alguém registre um domínio parecido ao lado do seu. Isso exige monitoramento ativo: observar novos registros de domínio e os logs públicos de transparência de certificados em busca de nomes visualmente próximos da sua marca, para que você possa denunciar ao registrador ou alertar os clientes antes que uma campanha usando esse domínio alcance alguém.
O que colocar em uma política de proteção de marca
Se você possui um domínio que vale a pena falsificar, a seção de segurança da sua política de proteção de marca deve ser específica o suficiente para que alguém novo na equipe consiga executá-la sem precisar perguntar antes.
- Registrar lock em todo domínio que a empresa possui, com registry lock adicionado no domínio principal da marca e em tudo o que lida com pagamentos ou logins.
- Uma cadência recorrente de varredura de novos registros de domínio e logs de transparência de certificados em busca de nomes visualmente próximos da sua marca, não uma verificação única.
- Registro defensivo dos rótulos parecidos de maior risco e dos domínios de nível superior confundíveis que você conseguir justificar, priorizados por quão próximos eles são do seu domínio principal.
- Um responsável nomeado e um caminho de escalonamento para denunciar ao registrador um domínio parecido descoberto, além de orientação interna para que a equipe de suporte reconheça o padrão quando um cliente relatar um. O checklist de segurança para escolher um provedor de links cobre os controles de fornecedor relacionados.
Uma receita de verificação que qualquer um consegue seguir
Você não precisa entender punycode para verificar um link com segurança. Quatro passos, feitos em ordem, capturam quase tudo o que um ataque homográfico depende.
- Expanda o link primeiro, em vez de clicar diretamente nele. Como ver para onde uma URL curta leva apresenta as ferramentas para isso, e o próprio verificador de links da Elido faz a mesma coisa sem pedir que você confie no destino antes.
- Leia o domínio registrável - a parte imediatamente antes do domínio de nível superior - e não qualquer coisa que apareça antes dele. Essa é a parte que um atacante precisa controlar por completo.
- Verifique se há um prefixo xn--, seja na URL expandida bruta, seja na barra de endereço do seu navegador. Se você ver um onde esperava um nome de marca simples, pare e trate isso como um domínio parecido até que se prove o contrário.
- Confirme o nome no certificado do site de destino. Um certificado reflete o que realmente foi emitido a um proprietário de domínio, o que é muito mais difícil de falsificar de forma convincente do que um rótulo renderizado.
Nenhum desses passos leva mais do que alguns segundos assim que viram hábito, e você consegue ensinar os quatro a um colega não técnico no tempo que leva para ler esta seção uma vez.
Um ataque homográfico é um problema de exibição vestido de fantasia de segurança. O punycode está fazendo exatamente o que foi projetado para fazer; o engano acontece na lacuna entre o que um domínio é e o que um software mostra a você em vez disso. Os navegadores fecharam a maior parte dessa lacuna para a barra de endereço. Em qualquer outro lugar a lacuna continua aberta, e é por isso que expandir um link e ler o domínio registrável continua sendo o hábito que funciona independentemente de qual canal colocou o link na sua frente.
Relacionados no blog
Perguntas frequentes
O que é um ataque homográfico IDN?
Um ataque homográfico IDN registra um domínio usando caracteres de uma escrita diferente que parecem idênticos ou quase idênticos aos de um domínio real, de modo que um leitor não consegue diferenciar os dois a olho nu. O caso clássico troca uma única letra latina por uma equivalente cirílica ou grega parecida, por exemplo o a cirílico pelo a latino, enquanto tudo o mais no domínio permanece inalterado. Como o caractere substituto tem um ponto de código diferente por baixo, os dois domínios são tecnicamente distintos e podem ser registrados e controlados por proprietários diferentes. O ataque funciona puramente pela aparência, e é por isso que ele mira nomes de marca reconhecíveis e confiáveis, em vez de nomes obscuros.
O que é punycode e por que ele existe?
Punycode é a codificação que transforma rótulos de domínio não-ASCII em uma string ASCII que o sistema de nomes de domínio consegue armazenar e resolver, definida na RFC 3492. Ele existe porque o DNS só entende um conjunto limitado de caracteres ASCII, então um domínio escrito em cirílico, árabe, chinês, ou com letras latinas acentuadas, precisa ser traduzido para essa forma antes de poder ser consultado. O rótulo codificado sempre começa com o prefixo xn--, que informa a resolvedores e navegadores que o que vem a seguir é uma string codificada em punycode, e não um nome ASCII simples. Os navegadores então a decodificam de volta para a escrita original na exibição, o que é um recurso legítimo e necessário, não a vulnerabilidade em si.
O que o prefixo xn-- significa em uma URL?
O prefixo xn-- marca um rótulo de domínio como ASCII Compatible Encoding, produzido pelo punycode, sinalizando que o nome legível foi traduzido a partir de caracteres não-ASCII. Tudo depois do prefixo é a forma codificada do rótulo original - xn--nvacloud-nbh.com, por exemplo, é decodificado para um domínio parecido com novacloud.com com uma letra trocada por uma parecida. Ver a forma xn-- onde você esperava um nome de marca simples é exatamente o sinal que os navegadores usam para avisar você, porque significa que o rótulo misturou escritas de um jeito que o navegador não considerou seguro exibir na versão bonita. Um domínio sem nenhum caractere não-ASCII nunca produz uma forma xn--, então ver uma sempre vale um segundo olhar.
Os navegadores protegem contra ataques homográficos?
Navegadores modernos aplicam regras de mistura de escritas que capturam a maioria das tentativas de ataque homográfico e voltam a mostrar a forma bruta em punycode em vez da forma enganosa. Tanto o Chrome quanto o Firefox verificam se os caracteres do rótulo de um domínio pertencem plausivelmente a uma única escrita ou a um pequeno conjunto de escritas comumente usadas juntas, e, se não pertencerem, exibem a versão xn-- em vez de decodificá-la para algo que poderia passar por um nome familiar. Isso bloqueia os ataques de escrita inteira mais fáceis de serem exibidos como impostores convincentes, embora os atacantes ainda consigam encontrar caracteres dentro dos conjuntos permitidos que são visualmente confundíveis com letras latinas. A proteção também é estritamente limitada à barra de endereço do navegador - nada mais na pilha herda isso automaticamente.
Como posso saber se um link é um domínio parecido antes de clicar nele?
Expanda o link primeiro, para ver o destino completo em vez de uma versão curta ou truncada, e depois leia o domínio registrável, e não qualquer coisa que venha antes dele. Se a barra de endereço ou o expansor mostrar um prefixo xn-- onde você esperava um nome de marca simples, trate isso como um domínio parecido até que se prove o contrário. Confirmar o nome no certificado do site de destino é uma última verificação útil, já que um certificado reflete o que realmente foi emitido, e não apenas o que é exibido. Nada disso exige software especial - só o hábito de fazer isso antes de digitar uma senha ou o número de um cartão.
O que é registry lock e meu domínio precisa disso?
Registry lock é um controle definido no nível do registro do domínio que bloqueia qualquer alteração, transferência ou exclusão de um domínio até que seja verificada manualmente fora de banda, tipicamente por telefone ou uma frase secreta segura, o que impede até uma conta de registrador comprometida de mover o domínio. É uma garantia mais forte do que o registrar lock, mais comum, que só evita transferências automáticas de rotina dentro do próprio painel do seu registrador. O registry lock vale o custo anual modesto para qualquer domínio cujo tempo de inatividade ou sequestro seria caro, o que para a maioria das empresas significa pelo menos o domínio principal da marca. Ele não impede que alguém registre um domínio parecido ao lado do seu - esse é um problema separado, resolvido por monitoramento, não por bloqueio.
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Grátis, sem necessidade de registo · 2 por dia