Introdução
Desde a introdução do Unicode em nomes de domínio (conhecidos como Nomes de Domínio Internacionalizados, ou simplesmente IDN) pela ICANN há mais de duas décadas, uma série de novas implicações de segurança veio à tona, juntamente com a possibilidade de registrar nomes de domínio usando diferentes alfabetos e caracteres Unicode.
Ao pesquisar a viabilidade de phishing e outros ataques baseados em homógrafos e IDNs, principalmente no contexto de testes de intrusão em aplicações web, nos deparamos com alguns casos curiosos em que eles também afetavam aplicações móveis.
Decidimos então investigar a prevalência dessa classe de vulnerabilidade em mensageiros instantâneos móveis, especialmente aqueles voltados para a segurança.
Esta postagem no blog oferece uma breve visão geral dos ataques de homógrafos, destaca seus riscos e apresenta uma cadeia de dois exploits práticos contra o Signal, Telegram e Tor Browser que poderiam levar a cenários de phishing quase impossíveis de detectar, além de situações em que exploits mais poderosos poderiam ser usados contra um alvo preocupado com a segurança operacional (opsec).
O que são homóglifos e homógrafos?
Não é incomum que caracteres pertencentes a alfabetos diferentes sejam parecidos. Eles são chamados de homóglifos e, às vezes, dependendo da fonte em que são renderizados, tornam-se visualmente indistinguíveis, impossibilitando que o usuário perceba a diferença entre eles.
A olho nu, 'a' e 'а' parecem iguais (um homóglifo), mas o primeiro pertence ao alfabeto latino e o segundo ao cirílico. Embora para o olho humano não treinado seja difícil distinguir entre ambos, eles podem ser interpretados de forma totalmente diferente pelos computadores.
Homógrafos são duas strings que parecem ser iguais, mas são, na verdade, diferentes. Pense, por exemplo, na palavra em inglês "lighter", que é escrita da mesma forma, mas tem significados diferentes dependendo do contexto – pode significar "um dispositivo para acender fogo" como substantivo ou o oposto de "mais pesado" (heavier), como adjetivo. As strings blazeinfosec.com e blаzeinfosec.com são frequentemente renderizadas como homógrafos, mas produzem resultados diferentes quando transformadas em uma URL.
Homóglifos, e por extensão homógrafos, existem entre muitos scripts diferentes. O latim, o grego e o cirílico, por exemplo, compartilham inúmeros caracteres que parecem exatamente iguais (por exemplo, A e А) ou têm uma semelhança muito próxima (por exemplo, P e Р). O Unicode possui um documento que considera caracteres "confundíveis" que possuem semelhantes em diferentes scripts.
Renderização de fontes e homóglifos
Dependendo da fonte, da forma como é renderizada e também do tamanho da fonte no visor, homóglifos e homógrafos podem ser exibidos de forma diferente ou completamente indistinguíveis um do outro, como visto na CVE-2018-4277 e no exemplo elaborado por Xudong Zheng em abril de 2017, que destacou as medidas insuficientes que os navegadores aplicavam contra homógrafos IDN até então.
Abaixo estão as strings https://www.apple.com (latino) e https://www.аррӏе.com (cirílico) exibido na fonte Tahoma, tamanho 30:
Abaixo estão as mesmas strings exibidas na fonte Bookman Old Style, tamanho 30:
Na forma como são renderizadas e exibidas, a Tahoma não parece distinguir entre ambas, não oferecendo qualquer indicação visual ao usuário de um site fraudulento. A Bookman Old Style, por outro lado, parece pelo menos renderizar o 'l' e o 'І' de forma diferente, dando uma pequena dica visual sobre a legitimidade da URL.
Nomes de Domínio Internacionalizados (IDN) e Punycode
Com o advento do suporte a Unicode nos principais sistemas operacionais e aplicativos, e o fato de a Internet ter ganhado popularidade em países que não utilizam necessariamente o alfabeto latino, a ICANN introduziu a primeira versão de IDN no final da década de 1990.
Isso significava que os nomes de domínio poderiam ser representados com os caracteres de seus idiomas nativos, em vez de ficarem restritos aos caracteres ASCII. No entanto, os sistemas DNS não compreendem Unicode, sendo necessária uma estratégia para adaptação aos sistemas que utilizam apenas ASCII. Portanto, Punycode foi inventado para traduzir nomes de domínio que contêm símbolos Unicode para ASCII, permitindo que os servidores DNS funcionassem normalmente.
Por exemplo, https://www.blazeinfosec.com e https://www.blаzeinfosec.com em ASCII serão:
Como o 'a' na segunda URL é, na verdade, um 'а' cirílico, é necessária uma tradução para Punycode.
Registro de domínios homógrafos
Inicialmente, na versão 1 dos Nomes de Domínio Internacionalizados, era possível registrar uma combinação de ASCII e Unicode no mesmo domínio. Isso claramente apresentava um problema de segurança, o que não ocorre mais desde a adoção das versões 2 e 3 de IDN, que restringiram ainda mais o registro de nomes de domínio Unicode. Mais notavelmente, instruiu os gTLDs a impedir o registro de nomes de domínio que contenham scripts mistos (por exemplo, caracteres latinos e kanji na mesma string).
Embora muitos registradores de domínios de nível superior restrinjam scripts mistos, a história mostrou na prática a possibilidade de registrar domínios com aparência semelhante em um único script – o que é a prática atualmente permitida por muitos registradores de gTLD.
Por exemplo, os domínios apple.com e paypal.com possuem equivalentes homógrafos em cirílico e foram registrados por pesquisadores de segurança no passado como uma prova de conceito de problemas de homógrafos em navegadores web.
Logan McDonald criou o ha-finder, uma ferramenta que analisa o 1 milhão de sites mais acessados e verifica se as letras em cada um deles podem ser confundidas com caracteres latinos ou decimais, realiza uma consulta WHOIS e informa se o domínio está disponível para registro ou não.
Ataques de homógrafos
Embora a ICANN estivesse ciente dos riscos potenciais de ataques de homógrafos desde a introdução do IDN, acredita-se que uma das primeiras demonstrações reais de um ataque prático de homógrafos IDN tenha sido descoberta em 2005 por 3ric Johanson, do Shmoo Group. Os detalhes do problema foram descritos neste ticket do Bugzilla e afetaram muitos outros navegadores na época.
Outra implicação dos homógrafos Unicode, embora não relacionada diretamente ao problema descrito nesta postagem do blog, foi o ataque documentado contra o Spotify em seu blog de engenharia, onde um pesquisador descobriu como assumir o controle de contas de usuários devido à conversão e canonização inadequadas de nomes de usuário baseados em Unicode em seus equivalentes ASCII.
Mais recentemente, ataques de phishing semelhantes foram detectados na prática contra usuários da corretora de criptomoedas MyEtherWallet, Github, e em 2018 a Apple corrigiu um bug, o CVE-2018-4277, no Safari, descoberto pelo Tencent Labs, onde a letra latina minúscula 'ꝱ' (dum) era exibida na barra de URL exatamente como o caractere 'd'.
Os navegadores possuem estratégias diferentes para lidar com IDN. Dependendo da configuração, alguns deles exibirão o Unicode para proporcionar uma experiência de usuário mais amigável. Eles também possuem algoritmos de exibição de IDN diferentes – o algoritmo do Google Chrome pode ser encontrado aqui. Ele realiza verificações no gTLD onde o domínio está registrado e também verifica se os caracteres estão em uma lista de caracteres cirílicos confusíveis.
O Firefox, incluindo o Tor Browser com sua configuração padrão, implementa um algoritmo muito menos rigoroso que simplesmente exibirá caracteres Unicode em seus scripts pretendidos, mesmo que sejam confusíveis com o alfabeto latino. Isso certamente não é suficiente para proteger os usuários e não é difícil realizar um exemplo prático: basta clicar em https://www.раураӏ.com para ser levado a um site no qual a barra de URL mostrará https://www.paypal.com mas não é de forma alguma o PayPal original.
Isso apresenta um problema claro para os usuários do Firefox e, consequentemente, do Tor Browser. Muitas tentativas de alterar o comportamento desses dois navegadores ao exibir IDNs ocorreram no passado, incluindo tickets para o Firefox e para o Tor Browser — esses tickets estão abertos desde o início de 2017.
Atacando o Signal, Telegram e Tor Browser com homógrafos
A grande maioria das pesquisas anteriores sobre este tópico concentrou-se em navegadores e clientes de e-mail. Portanto, decidimos investigar diferentes vetores onde homógrafos poderiam ser aproveitados, total ou parcialmente, para ataques bem-sucedidos.
Muitas vezes, o modelo de ameaça de indivíduos que usam plataformas de mensagens focadas em privacidade, como Signal e Telegram, inclui não clicar em links enviados via SMS ou mensageiros instantâneos, já que isso provou ser o vetor de ataque inicial em uma cadeia de explorações para comprometer um alvo móvel, por exemplo.
Como mencionado anteriormente neste artigo, dependendo da fonte e do tamanho usados para exibir o texto, ele pode ser renderizado na tela de uma forma visualmente indistinguível, tornando impossível para um usuário humano diferenciar uma URL legítima de um link malicioso.
Etapas do ataque
- O adversário adquire um nome de domínio homógrafo semelhante ao domínio adequado para o ataque
- O adversário hospeda conteúdo malicioso (por exemplo, phishing ou um exploit de navegador) no servidor web que fornece essa URL
- O adversário envia um link contendo uma URL homógrafa maliciosa para o alvo
- O alvo clica no link, acreditando ser uma URL legítima e confiável, já que não há como distinguir visualmente URLs legítimas de maliciosas
- A atividade maliciosa ocorre
Abaixo, podemos ver como o Signal para Android e Desktop, respectivamente, renderizaram mensagens com links contendo caracteres homógrafos:
O Telegram chegou ao ponto de criar uma prévia do site falso e renderizou o link de uma forma que torna impossível para um ser humano identificar que é malicioso:
Até recentemente, muitos navegadores eram vulneráveis a esses ataques e exibiam links homógrafos na barra de URL com aparência latina, em vez do Punycode esperado. O Firefox, por outro lado, tenta ser amigável por padrão e, em muitos casos, não mostra o Punycode, deixando seus usuários vulneráveis a tais ataques.
O Tor Browser, como já mencionado, é baseado no Firefox, o que permite uma cadeia de ataque completa contra usuários do Signal e do Telegram. Dadas as preocupações com a privacidade e o modelo de ameaças dos usuários desses mensageiros instantâneos, é provável que muitos deles utilizem o Tor Browser para navegar, tornando-os, portanto, vulneráveis a um ataque homógrafo de cadeia completa.
Ataque Signal + Tor Browser
Ataque Telegram + Tor Browser
As vulnerabilidades que encontramos no Signal e no Telegram receberam os identificadores CVE-2019-9970 e CVE-2019-10044, respectivamente. Os avisos podem ser encontrados em nossa página de avisos no Github.
Outros mensageiros instantâneos populares, como Slack, Facebook Messenger e WhatsApp, não se mostraram vulneráveis a essa classe de ataque durante nossos experimentos. As versões mais recentes do WhatsApp chegam a exibir um rótulo no link para alertar os usuários de que ele pode ser malicioso, enquanto outros mensageiros simplesmente tornam o link não clicável.
Conclusão
Homógrafos confusíveis são uma classe de ataques contra usuários da Internet que existem há quase duas décadas, desde o advento do Unicode em nomes de domínio. Os riscos dos homógrafos na segurança da computação são conhecidos e relativamente bem compreendidos, mas continuamos vendo ataques relacionados a homógrafos ressurgirem de tempos em tempos.
Embora existam há algum tempo, pouca atenção tem sido dada a essa classe de ataques, pois geralmente são vistos como pouco prejudiciais e costumam cair na categoria de engenharia social – que nem sempre faz parte dos modelos de ameaças de muitos aplicativos, assumindo-se frequentemente que o usuário deve se cuidar. No entanto, acreditamos que os aplicativos podem fazer melhor.
Por fim, as equipes de segurança de aplicativos devem elevar o nível e ser proativas na prevenção desses ataques (como o Google fez com o Chrome), em vez de culpar os registradores, confiar na conscientização do usuário para não cair na armadilha ou esperar que a ICANN apresente uma solução mágica para o problema.
Referências
- https://krebsonsecurity.com/2018/03/look-alike-domains-and-visual-confusion/
- https://citizenlab.ca/2016/08/million-dollar-dissident-iphone-zero-day-nso-group-uae/
- https://bugzilla.mozilla.org/show_bug.cgi?id=279099
- https://www.phish.ai/2018/03/13/idn-homograph-attack-back-crypto/
- https://dev.to/loganmeetsworld/homographs-attack--5a1p
- https://www.unicode.org/Public/security/latest/confusables.txt
- https://labs.spotify.com/2013/06/18/creative-usernames
- https://xlab.tencent.com/en/2018/11/13/cve-2018-4277
- https://urlscan.io/result/0c6b86a5-3115-43d8-9389-d6562c6c49fa
- https://www.xudongz.com/blog/2017/idn-phishing
- https://github.com/loganmeetsworld/homographs-talk/tree/master/ha-finder
- https://www.chromium.org/developers/design-documents/idn-in-google-chrome
- https://wiki.mozilla.org/IDN_Display_Algorithm
- https://www.ietf.org/rfc/rfc3492.txt
- https://trac.torproject.org/projects/tor/ticket/21961
- https://bugzilla.mozilla.org/show_bug.cgi?id=1332714
