Vulnerabilidade de clickjacking no WhatsApp permite ataques de phishing

• Foi descoberta uma vulnerabilidade de phishing no WhatsApp que exibe um link e uma prévia que parecem apontar para um site legítimo, enquanto o clique real leva o usuário para um site controlado pelo atacante
• A causa está na estrutura em que o link do corpo da mensagem e os dados da prévia são enviados separadamente, e na possibilidade de criar uma incompatibilidade na prévia ao remover matchedText
• O caractere U+202E Right-To-Left Override pode inverter a direção de exibição da URL, fazendo o domínio real parecer um domínio legítimo
• O atacante pode preparar um domínio espelho do alvo a ser falsificado, manter a prévia do site original e alterar apenas o valor de text para enganar a vítima
• A Meta respondeu que pode ajustar dinamicamente a lógica de normalização de URL, e os usuários devem copiar o link antes de clicar para verificar o endereço real

---

Onde a prévia do link e o link real se separam no WhatsApp

• O pesquisador enviou um link do webhook.site a um amigo para verificar se, ao renderizar a prévia do link, o destinatário de uma mensagem no WhatsApp gerava uma requisição HTTP
• A requisição HTTP ocorreu apenas uma vez, no lado do remetente, confirmando que o destinatário não renderiza o link separadamente
• Por causa desse comportamento, concluiu-se que as mensagens do WhatsApp são enviadas já contendo o link e as informações da prévia, e foi testado se os dois poderiam ser tornados diferentes entre si

Issue #1: incompatibilidade na prévia do link

• Tentou-se modificar diretamente uma mensagem do WhatsApp Web por proxy, mas por causa do E2EE do WhatsApp, a simples adulteração com ferramentas como Burp Suite não era fácil
• Em vez disso, foi colocado um breakpoint no JavaScript imediatamente antes de a mensagem criptografada ser enviada via WebSocket, para inspecionar o objeto da mensagem
• No objeto da mensagem, o link no corpo e as informações da prévia existem como propriedades separadas
  • text: corpo da mensagem
  • canonicalURL: domínio exibido na parte inferior da prévia
  • matchedText: parece ser o valor comparado com canonicalURL, e foi testado se esse valor também aparece dentro de text
• Ao trocar text por google.com em um objeto de mensagem para instagram.com, a prévia desaparece e resta apenas o link do Google
• Ao remover a propriedade matchedText, foi possível criar uma mensagem inconsistente em que o link real e a prévia são diferentes

Issue #2: disfarce visual do link com U+202E

• Para impedir que o corpo real do link ficasse evidente, foi feito fuzzing para verificar se caracteres Unicode poderiam alterar a forma como o texto é exibido
• U+202E é o caractere Right-To-Left Override, que faz o texto ser exibido ao usuário em ordem invertida
• Usar apenas U+202E deixava a aparência do link estranha e pouco convincente para clique, então foi necessário montar uma string invertida que parecesse uma URL normal

Como o URL espelho é construído

• O objetivo era criar uma URL que, quando invertida, parecesse https://instagram.com
• Uma simples string invertida seria moc.margatsni//:sttph, mas um TLD como .margatsni não pode ser registrado
• A solução foi usar um TLD realmente registrável de forma que ele parecesse um subdomínio
  • Por exemplo, usando o TLD holandês .nl, é possível criar uma string que pareça ln.instagram.com
• Como a URL precisava parecer começar com https://, foi acrescentado ao final o caminho válido //:sptth
• Como resultado, https://moc.margatsni.nl//:sptth, quando combinado com U+202E, pode parecer https://ln.instagram.com//:sptth
• O pesquisador chamou essa técnica de 2K2E

Fluxo do ataque

• O atacante compra um domínio espelho do site que quer falsificar
  • Exemplo: para fazer parecer ln.instagram.com, compra-se moc.margatsni.nl
• Primeiro, cria-se uma mensagem com o link do domínio original para obter a prévia do site
  • No objeto de exemplo, text, matchedText e canonicalUrl contêm https://instagram.com/
  • Também estão incluídos valores relacionados à prévia, como description, title, jpegThumbnail e thumbnailDirectPath
• Depois, remove-se matchedText e altera-se o valor de text para o formato \u202ehttps://moc.margatsni.nl//:sptth
• A mensagem final exibe a prévia do Instagram, mas ao clicar pode levar ao domínio preparado pelo atacante

Resposta da Meta e comparação com outras plataformas

• A Meta respondeu que, como oferece suporte a várias plataformas e ambientes, a forma de normalização de URL pode diferir da lógica do servidor dependendo da plataforma
• Também afirmou que possui um sistema capaz de ajustar dinamicamente a lógica de normalização de URL quando ocorrer spam ou abuso real
• O pesquisador avaliou que a Meta parece menos interessada em corrigir ativamente esse problema de segurança e mais inclinada a reagir apenas quando o sistema detectar spam
• X, TikTok e Pinterest fazem sanitização do caractere U+202E, diferentemente do WhatsApp

Mitigação que o usuário pode adotar

• Não é confiável julgar links do WhatsApp apenas pela forma como são exibidos
• Para evitar phishing 2K2E, o usuário deve copiar o link antes de clicar e verificar o endereço real na prévia da área de transferência
• A prévia da área de transferência pode mostrar o endereço do link com o caractere U+202E já sanitizado
• O pesquisador afirmou ter encontrado depois outros serviços também vulneráveis ao 2K2E por não fazerem a sanitização adequada

[GN⁺]

Opiniões do Hacker News

• É uma combinação de usos indevidos bem engenhosa, mas o impacto de segurança geral provavelmente é baixo
  Mesmo no melhor cenário, isso no máximo faz o destinatário abrir um link no navegador, então, a menos que o atacante seja polícia ou agência de inteligência, normalmente seria preciso um ataque de acompanhamento explorando software desatualizado no dispositivo
  Tecnicamente, é difícil chamar isso exatamente de clickjacking. Clickjacking normalmente se refere a uma técnica bem específica de sobrepor um frame HTML invisível sobre outro conteúdo
  https://owasp.org/www-community/attacks/Clickjacking
  https://portswigger.net/web-security/clickjacking

  • Eu também não chamaria isso de clickjacking. O verdadeiro clickjacking faz a vítima executar ações ligadas à conta sem perceber, e apenas abrir um link não intencional não é tão grave assim
  • Se esse link mostrar uma tela de login idêntica à do Instagram, qual porcentagem dos usuários, depois de já ter se confundido uma vez ao conferir a prévia do WhatsApp, realmente vai verificar a URL de novo?

• Todo mundo está focando só nos caracteres UTF da direita para a esquerda, mas a Meta pelo menos deveria ter reconhecido o problema de a URL da prévia poder ser diferente da URL da mensagem
  Entendo que isso acontece por causa do comportamento de expandir URLs encurtadas, mas parece claro que Meta e WhatsApp poderiam implementar alguma solução alternativa inteligente

  • Não. Com criptografia de ponta a ponta, a prévia precisa ser gerada do lado do remetente ou do destinatário. Se o destinatário gerar a prévia, o IP dele vaza. No fim, a funcionalidade de prévia teria que ser removida

• Clickjacking é quando você acha que está clicando em um elemento, mas na verdade outro elemento, geralmente transparente e sobreposto por cima, intercepta o clique
  Se você der foco à camada visível de baixo e detectar a ocorrência do evento onblur, o atacante pode perceber o clique mesmo que o usuário não receba o evento
  O que o OP encontrou é legal, mas não é clickjacking. Eu mesmo já usei caracteres RTL para fazer um arquivo de protetor de tela, ou seja, um executável comum com uma extensão diferente no Windows, parecer um documento do Word. Acho que era para pregar uma peça em um amigo ou professor, mas não lembro bem por quê
  O OP foi um passo além e encontrou uma forma de alterar a exibição em outro sistema. O usuário não se engana sobre em que elemento está clicando, mas sim sobre para onde o link vai, então isso não é clickjacking, e a página da Wikipedia linkada no começo do texto confirma isso
  Nunca vi clickjacking ser explorado na prática, mas esse método que o OP encontrou parece algo que realmente pode ser abusado
  Para ser sincero, já desisti há muito tempo de esperar que usuários consigam distinguir o domínio final ao clicar em um link. A maioria nem entende o conceito, e o restante também tem dificuldade
  Até quem acha que consegue diferenciar acaba se frustrando quando todos os links vão para algo como sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o. Estamos treinando as pessoas diariamente a clicar em links suspeitos e ofuscados para rastreamento, e ninguém parece se importar

• Hack bem interessante. O problema real não é o WhatsApp nem os caracteres reversos do Unicode, e sim que URLs são difíceis
  Mesmo exemplos simples como visa.securesite.com enganam muita gente. Não vejo uma boa solução no futuro próximo

  • Neste caso específico, isso engana ativamente o usuário quando ele tenta entender no que está clicando, então é mais parecido com sanitização deficiente
    A confusão geral em torno de hostnames e domínios é um problema mais difícil, mas os navegadores vêm tentando amenizar isso destacando a parte do nome de domínio. Como na maioria das técnicas de phishing, parece que no fim as passkeys vão resolver isso

• RTL tem sido uma enorme fonte de vulnerabilidades de segurança desde sempre. Não entendo por que não existe uma configuração no sistema operacional para desativar todo RTL, para que pessoas que não conhecem esses idiomas não fiquem expostas a riscos sem ganhar nada em troca

  • Independentemente do sistema operacional, todos os widgets do SO que exibem texto deveriam ter essa opção. Incluindo o TextView do Android
    A menos que o desenvolvedor revise e permita explicitamente determinados trechos de texto, o padrão deveria ser desativar todos os controles de texto bidirecional
    Não faz sentido tornar toda a pilha de renderização de texto vulnerável por padrão em nome de atender menos de 1% da população mundial

• É decepcionante que a Meta tenha decidido não corrigir isso e também não pagar bug bounty a este pesquisador

  • No começo deste ano, relatei um problema parecido ao Google, mas ele foi rejeitado com a justificativa de que “só pode ocorrer via engenharia social” e de que “corrigir isso não tornaria os usuários significativamente menos vulneráveis”
    Não vou entrar em detalhes aqui, mas por causa da forma como o Google Search às vezes reescreve URLs, um atacante pode disfarçar a URL real
    É melhor nunca confiar cegamente em URLs exibidas em sites e aplicativos
  • Devem estar ocupados demais enviando ameaças legais para projetos OSS
  • Talvez ele não tenha conseguido deixar claro o que queria que fosse corrigido, por exemplo bloquear caracteres RTL, e a Meta pode ter entendido como um pedido para corrigir todas as URLs potencialmente enganosas. Isso é praticamente impossível
  • Vão corrigir, sim. Só não vão recompensar o caçador de bugs

• O mais problemático em termos de design de UI é justamente o fato de “como era de se esperar, o link e a prévia foram enviados separadamente!”. Por que um usuário comum deveria ter que comparar link e prévia para se manter seguro?

  • É um compromisso de segurança. Para oferecer um recurso útil como prévia de link, existem algumas opções
    1. Gerar do lado do remetente. A desvantagem é que pode ser falsificada
    2. Gerar do lado do destinatário. A desvantagem é que o IP do destinatário vaza
    3. Gerar por meio de um terceiro. A desvantagem é que a informação vaza para esse terceiro
       No geral, acho que a opção 1 é a melhor. O remetente já pode “falsificar” todas as próprias mensagens de qualquer forma, e incluir a prévia como parte da mensagem não muda tanto assim
       O problema aqui é que não fica claro que esse conteúdo veio do remetente. Como ele aparece como um balão separado, acho que 99% dos usuários não perceberiam que esse conteúdo foi fornecido pelo remetente
       Além disso, no fim a URL é o que importa. Se você clicar em uma URL controlada por um atacante, ele pode mostrar o que quiser na prévia. Por isso, o ganho obtido ao forçar que a prévia seja “real” é muito pequeno
       A opção 3 também pode ser aceitável. Especialmente se for implementada com algo como double blind, em que você se conecta a uma ponta e ela encaminha para uma segunda. Assim, a primeira vê o IP e a segunda vê o destino, mas, a menos que colaborem entre si, nenhuma das duas vê as duas coisas ao mesmo tempo
       Só que o benefício é relativamente pequeno para justificar construir e manter esse nível de infraestrutura

• Gosto que isso tenha sido classificado como engenharia reversa no fim do texto

• Isso não é clickjacking. Clickjacking é quando um atacante sequestra o clique para fazer o usuário clicar de fato em outro alvo, algo que ele não pretendia ou do qual não tinha consciência
  Code points RTL que fazem o texto fluir da direita para a esquerda são um recurso de internacionalização, e usá-los para confundir pessoas não é uma vulnerabilidade nova