Os desenvolvedores do Chrome e do Firefox tentam encontrar um equilíbrio entre mostrar nomes de domínio internacionalizados e proteger os usuários contra phishing
A versão mais recente do Google Chrome, lançada em abril desse ano, restringe como os nomes de domínio que usam caracteres não latinos são exibidos no navegador. Esta mudança é em resposta a uma técnica recentemente divulgada que poderia permitir que os atacantes criassem sites de phishing altamente credíveis.
A capacidade de registrar nomes de domínio compostos de caracteres como os encontrados nos alfabetos árabe, chinês, cirílico, hebraico e outros não latinos remonta a uma década. Desde 2009, a Corporação de Internet para Nomes e Números Atribuídos (ICANN) também aprovou um grande número de domínios de primeiro nível internacionalizados (TLDs) - extensões de domínio - escritos com tais caracteres.
Quando usado no Domain Name System (DNS) - o livro de endereços da Internet - nomes de domínio internacionalizados são convertidos em formato compatível com ASCII usando um sistema chamado Punycode. No entanto, quando exibido para os usuários dentro de navegadores e outros aplicativos que suportam Unicode, eles são mostrados com seus caracteres não latinos pretendidos, tornando possível para bilhões de usuários da Internet para ler nomes de domínio em seus idiomas nativos e scripts.
Embora isso seja ótimo para a usabilidade global da internet, o uso de nomes de domínio internacionalizados levanta problemas de segurança porque alguns alfabetos contêm caracteres que se parecem muito com letras latinas e isso pode ser usado para a criação de URLs falsas. Por exemplo, as letras "a" nos scripts cirílico e latino são visualmente idênticas, mesmo que sejam caracteres diferentes com diferentes valores Unicode: U + 0430 e U + 0061.
Esta semelhança permitiria que as pessoas criassem o nome de domínio apple.com usando a letra "a" do alfabeto cirílico e o resto do alfabeto latino. Tal nome de domínio poderia ser usado para configurar um site de phishing que seria muito difícil de distinguir do real se o navegador visualmente mostrar apple.com para ambos na barra de endereços.
Para evitar esses ataques de homógrafos, os navegadores realizam uma série de verificações complexas para decidir se é melhor exibir nomes de domínio usando seus scripts pretendidos ou exibir seus equivalentes em Punycode. Uma das regras que eles aplicam é que se caracteres latinos, cirílicos ou gregos forem misturados, Punycode sempre será usado.
A versão Punycode do domínio apple.com mencionado acima, onde a letra "a" é do cirílico, seria: xn--pple-43d.com. Isso é o que os usuários veriam na barra de endereços do navegador.
No entanto, levando as coisas ainda mais adiante, um desenvolvedor de aplicativos da Web chamado Xudong Zheng percebeu que para alguns nomes de domínio ou marcas é possível substituir todas as letras com visualmente semelhantes de um script diferente. Por exemplo, há chracters lookalike em cirílico para todas as letras na palavra apple. Nesse caso, o filtro do navegador acima não se aplicaria mais porque não há nenhum script misturado no nome.
Para provar isso, a Xudong recentemente registrou o domínio xn--80ak6aa92e.com e criou um site cujo endereço parecia virtualmente idêntico ao apple.com quando aberto dentro do Chrome, Firefox ou Opera em Windows e Linux. Em macOS o "l" personagem parecia um pouco diferente, mas ainda estava perto o suficiente.
Xudong informou este problema aos fornecedores de navegadores e o Google corrigiu-o quarta-feira no Chrome 58 adicionando mais uma verificação à sua política de nome de domínio internacionalizado (IDN). O navegador agora exibirá nomes de domínio em Punycode se todos os seus caracteres forem letras em caracteres latinos parecidos com caracteres cirílicos e se o nome de domínio de nível superior não for internacionalizado. Isso significa que o cheque só se aplica a TLD tradicionais genéricos e de código de país baseados em latino como .com, .net, .org, .uk, .de e assim por diante.
Por exemplo, xn - 80ak6aa92e.xn - p1ai ainda olharia na barra de endereço do navegador como a apple seguida pelo TLD de código de país internacionalizado para a Rússia, que está escrito em cirílico.
A verificação não corresponde ao script do nome de domínio com o do TLD, o que significa que xn - 80ak6aa92e.xn - fiqs8s também funciona, mas com o TLD de código de país internacionalizado para a China; Assim faz xn - 80ak6aa92e.xn - qxam para a Grécia, xn - 80ak6aa92e.xn - 3e0b707e para a Coréia e assim por diante. Esses domínios podem não ser adequados para lançar ataques de phishing contra usuários em países que usam alfabetos latinos, mas podem parecer legítimos para usuários que usam scripts diferentes.
A política de exibição de IDN do Google Chrome já é composta por 10 verificações diferentes com condições diferentes, destacando o quão difícil é cobrir todos os possíveis abusos desses nomes de domínio.
A Mozilla ainda está considerando se deve tomar qualquer ação para bloquear a técnica de Xudong e não chegou a uma conclusão final. Uma discussão em seu rastreador de bugs mostra que há fortes pontos de vista opostos sobre quem deve ser responsável pela prevenção desses ataques.
Alguns acreditam que os ataques de homógrafos de todo o script, como no caso do apple.com escrito com caracteres cirílicos, não é algo que os navegadores devem corrigir. Eles sentem que a responsabilidade deve cair com os proprietários de marcas que devem registrar esses domínios para proteger suas marcas e com registradores de domínio que devem ter listas negras no local para impedir que os usuários de registrar domínios potencialmente abusivos.
Gervase Markham, um engenheiro de políticas da Mozilla, publicou um documento não oficial de FAQ que explica como o Firefox decide se exibir IDNs em sua forma apropriada e quais implicações uma política mais restritiva teria.
Os usuários do Firefox que não se importam em ver IDNs em seus scripts pretendidos podem forçar manualmente o navegador a exibi-los sempre em Punycode. Isso pode ser feito digitando about: config na barra de endereços do navegador, localizando a configuração network.IDN_show_punycode e alterando seu valor de false para true.
Homograph ataques usando IDNs provavelmente estão aqui para ficar, como sempre haverá alguns casos de ponta não abrangidos pelas políticas existentes. O debate é se o risco vale a pena sacrificar a usabilidade para um grande número de usuários, já que os phishers já têm muito sucesso com técnicas mais simples que não dependem de URLs falsas.
*Noticia também publicada no site: https://www.icmpconsultoria.com.br
