Falha no WhatsApp Web e Telegram Web permitia tomada de contas por arquivos manipulados

Vulnerabilidade em clientes web aceitava conteúdo malicioso dentro de anexos criptografados e podia expor dados de sessão armazenados no navegador.

Componente	WhatsApp Web e Telegram Web, com foco no processamento de anexos em sessões de navegador sincronizadas com contas móveis.
Vetor	Envio de arquivo aparentemente legítimo contendo HTML malicioso, aceito pelo cliente web após manipulação de tipo MIME e aberto pela vítima no navegador.
Impacto	Acesso potencial ao armazenamento local do navegador associado ao domínio do serviço, permitindo tomada de conta e acesso a conversas, contatos e arquivos compartilhados.
Prioridade	Reiniciar o navegador para garantir o uso do cliente web corrigido e revisar sessões conectadas em computadores usados para WhatsApp Web e Telegram Web.
Artefatos	Uso defensivamente relevante de FileReader, URL BLOB, armazenamento local do navegador, URI FileSystem, text/html e video/mp4 no fluxo descrito.
Mitigação	Validação de conteúdo antes da criptografia e bloqueio de arquivos maliciosos nos clientes web, conforme correção aplicada pelos serviços.

Resumo técnico

Uma vulnerabilidade no tratamento de anexos em WhatsApp Web e Telegram Web permitia que um arquivo recebido como conteúdo aparentemente inofensivo fosse processado pelo navegador dentro do contexto do próprio serviço. O ponto crítico não estava na quebra da criptografia de ponta a ponta, mas no fato de que o conteúdo era criptografado e transportado sem validação suficiente antes desse processo. Como os servidores recebiam uma versão já cifrada do arquivo, a aplicação podia não bloquear um documento malicioso que, ao ser aberto no cliente web, passava a executar no escopo do domínio usado pela sessão do usuário.

O impacto descrito era de tomada de conta nos clientes web, com acesso potencial a conversas pessoais e de grupo, fotos, vídeos, arquivos compartilhados e listas de contatos. A condição essencial era a interação da vítima com o anexo enviado pelo atacante. No WhatsApp Web, o fluxo dependia da abertura do item apresentado como imagem ou documento com pré-visualização legítima. No Telegram Web, a exploração exigia que o usuário abrisse o suposto vídeo em uma nova aba para que o recurso fosse acessado no contexto adequado do navegador. Em ambos os casos, o alvo técnico era o armazenamento local associado ao serviço web, onde dados de sessão e informações necessárias à continuidade da conta podiam ser lidos pelo código malicioso.

A falha foi comunicada às equipes de segurança do WhatsApp e do Telegram em 7 de março de 2017, e os dois serviços validaram o problema e distribuíram correções para os clientes web. Depois da correção, o fluxo passou a validar o conteúdo antes da criptografia, permitindo bloquear arquivos maliciosos antes que fossem aceitos e distribuídos. Para usuários finais e equipes de suporte, a recomendação operacional imediata era reiniciar o navegador para garantir que a versão web atualizada fosse carregada, além de revisar computadores autenticados nas contas.

Fluxo técnico

A exploração começava com o envio de um anexo fabricado para parecer legítimo. O arquivo trazia conteúdo visual ou metadados usados para aumentar a probabilidade de abertura, mas encapsulava HTML malicioso. O detalhe central era o descompasso entre a política de upload do cliente, os tipos MIME aceitos e o momento em que o conteúdo era cifrado. Como a validação efetiva não ocorria antes da criptografia, o atacante podia alterar atributos do arquivo no cliente e fazer com que conteúdo HTML fosse aceito como um tipo permitido. A partir daí, o arquivo trafegava pelo serviço cifrado e chegava ao destinatário como um anexo aparentemente normal.

No caso do WhatsApp Web, o mecanismo de upload aceitava diferentes tipos de documentos, incluindo arquivos de escritório, PDF, áudio, vídeo e imagens. O fluxo descrito explorava a lista de tipos MIME permitidos mantida em variável do cliente, associada a DOC_MIMES, para aceitar conteúdo text/html. O documento era então cifrado por uma função de mídia do cliente e enviado como BLOB ao servidor. Quando a vítima abria o item, o cliente web usava a API HTML5 FileReader para gerar uma URL BLOB com o conteúdo recebido e navegava para esse recurso. Como a página resultante era tratada no contexto de web[.]whatsapp[.]com, o código malicioso podia acessar recursos disponíveis nesse escopo, incluindo dados no armazenamento local.

O fluxo do Telegram Web seguia a mesma lógica geral, mas com diferenças relevantes. O cliente armazenava determinados tipos de documento na área de arquivos do navegador, especialmente imagens e vídeos. A cadeia descrita manipulava o tipo MIME para video/mp4, fazendo um documento HTML malicioso parecer um vídeo. Depois do envio cifrado e do recebimento pela vítima, o conteúdo só alcançava a condição explorável quando o suposto vídeo era aberto em uma nova aba. Nesse momento, o recurso era carregado sob web[.]telegram[.]org por meio de uma URI FileSystem, permitindo que o código malicioso operasse no contexto do serviço e acessasse dados locais da sessão.

A consequência técnica principal era a substituição ou reutilização de dados de sessão da vítima pelo operador do ataque. O material descreve um mecanismo em que o atacante verificava periodicamente a chegada de novos dados e passava a refletir o armazenamento local da vítima para assumir a conta. No WhatsApp Web, havia ainda um comportamento operacional importante: o serviço não permitia mais de uma sessão web ativa ao mesmo tempo, o que gerava uma mensagem para a vítima quando a conta era tomada. O ataque descrito incluía uma técnica para dificultar a interferência do usuário mantendo a janela travada, mas o detalhe operacional deve ser tratado apenas como evidência de risco defensivo. No Telegram Web, a existência de múltiplas sessões simultâneas reduzia a visibilidade imediata para a vítima, pois a conta podia continuar acessível em paralelo.

Superfície afetada

A superfície de exposição estava nos clientes web, não nos aplicativos móveis de forma isolada. WhatsApp Web e Telegram Web funcionam como espelhos das mensagens enviadas e recebidas, sincronizados com o dispositivo ou com a conta do usuário. Isso aumenta o impacto de uma falha no navegador, porque o comprometimento do contexto web não se limita ao arquivo aberto: ele pode alcançar conversas, mídia compartilhada e contatos associados à conta. O risco também se ampliava pela capacidade de propagação social, já que uma conta assumida podia enviar o mesmo anexo para contatos da vítima, criando uma cadeia de disseminação dentro das redes de confiança dos usuários.

O WhatsApp tinha mais de 1 bilhão de usuários no período descrito, com versão web acessível em navegadores e compatível com plataformas móveis como Android, iPhone, Windows Phone, BlackBerry, BB10 e Nokia. O Telegram tinha mais de 100 milhões de usuários ativos mensais e processava mais de 15 bilhões de mensagens por dia. Esses números não confirmam exploração em larga escala, mas dimensionam a superfície potencial: uma vulnerabilidade em clientes web desses serviços poderia atingir contas pessoais, grupos, arquivos privados e comunicações de trabalho quando usuários dependessem do acesso por navegador.

A exposição dependia de três condições combinadas. Primeiro, a conta precisava estar acessível pelo cliente web. Segundo, o usuário precisava receber e abrir o anexo manipulado conforme o fluxo de cada serviço. Terceiro, o navegador precisava processar o conteúdo no contexto do domínio do serviço, permitindo acesso ao armazenamento local. Sem essas condições, o cenário de tomada de conta descrito não se completava. Também não há, no material analisado, evidência de exploração ativa, identificação de ator, campanha nomeada, CVE ou indicador de infraestrutura externa associado ao caso.

• WhatsApp Web com anexo manipulado aceito como documento ou imagem e processado por URL BLOB no contexto do serviço.
• Telegram Web com arquivo HTML disfarçado por tipo MIME de vídeo e aberto em nova aba sob URI FileSystem.
• Sessões web autenticadas em navegadores com dados de conta presentes no armazenamento local.
• Contas com contatos e grupos que poderiam receber anexos repassados por uma conta já assumida.

Hunting e telemetria

A investigação defensiva deve se concentrar em sinais de uso anômalo de clientes web e em eventos de sessão, porque o caso não fornece hashes, domínios de comando e controle, endereços IP ou nomes de arquivos confiáveis para bloqueio. Em ambientes corporativos, a telemetria mais útil vem de inventário de navegadores, histórico de sessões web autorizadas, logs de proxy, EDR com visibilidade de navegador e registros de acesso a serviços de mensagens quando permitidos pela política interna. O objetivo é identificar abertura de anexos incomuns, navegação para recursos locais do navegador associados aos domínios dos serviços e mudanças inesperadas de sessão.

No WhatsApp Web, um sinal operacional relevante é a notificação de substituição de sessão, porque o serviço web não mantinha mais de uma sessão ativa ao mesmo tempo. Usuários que relatassem desconexão inesperada, mensagem de uso em outro navegador ou perda de controle da sessão deveriam ser tratados como casos de triagem. No Telegram Web, a análise precisa considerar que múltiplas sessões podiam coexistir, reduzindo alertas visíveis ao usuário. Por isso, a revisão de sessões ativas e dispositivos autorizados era mais importante para descobrir acessos indevidos persistentes.

No endpoint, a busca deve evitar dependência de assinaturas de payload específico. O comportamento descrito envolve um arquivo recebido como mídia ou documento, renderização via APIs do navegador e acesso ao armazenamento local. Equipes de segurança podem procurar sequências de eventos em que anexos de mensageiros web abrem novas abas, criam URLs BLOB, usam armazenamento local de forma incomum e são seguidos por envio massivo de mensagens ou anexos para contatos. Em redes gerenciadas, picos de tráfego para os clientes web após abertura de anexos podem indicar propagação, embora esse sinal precise ser correlacionado com relato do usuário e eventos do navegador para evitar falso positivo.

• Relatos de desconexão inesperada do WhatsApp Web ou aviso de sessão ativa em outro navegador.
• Sessões do Telegram Web desconhecidas ou simultâneas em computadores que o usuário não reconhece.
• Abertura de anexos que resultem em nova aba, URL BLOB ou URI FileSystem associada ao domínio do mensageiro.
• Envio não reconhecido de arquivos para múltiplos contatos ou grupos logo após abertura de anexo.
• Persistência de sessão web mesmo depois de a vítima fechar a janela do navegador.

Mitigação

A correção principal foi aplicada nos próprios clientes web: WhatsApp e Telegram passaram a validar conteúdo antes da criptografia, permitindo que arquivos maliciosos fossem bloqueados antes do envio ou da entrega. Essa mudança ataca a causa do problema, porque remove a possibilidade de o serviço transportar cegamente um documento perigoso apenas por estar cifrado. Como clientes web são carregados pelo navegador, usuários precisavam reiniciar o navegador para assegurar que a versão corrigida fosse obtida e usada em novas sessões.

Para resposta defensiva, a ordem recomendada é garantir atualização do cliente web, encerrar sessões desconhecidas e revisar atividade recente da conta. Usuários devem limpar computadores conectados periodicamente nas configurações do WhatsApp e do Telegram, removendo dispositivos que não reconheçam. Em ambientes corporativos, help desk e SOC devem orientar a abertura de chamados para qualquer mensagem enviada sem ação do usuário, sessão web inesperada, arquivo suspeito recebido de contato confiável ou comportamento de travamento da janela após abertura de anexo em mensageiros web.

A contenção de uma suspeita de tomada de conta deve incluir encerramento de sessões web, troca de credenciais quando aplicável ao ecossistema da conta, revisão de dispositivos autorizados e comunicação aos contatos que possam ter recebido anexos suspeitos. Como o caso envolve dados de sessão no navegador, a limpeza de cache e dados do site pode ser útil dentro de um procedimento controlado, mas não substitui a revogação de sessões no próprio serviço. Em endpoints corporativos, também é prudente verificar extensões de navegador, persistência incomum, downloads recentes e histórico de abertura de anexos vinculados a mensagens.

A lição técnica mais importante é que criptografia de ponta a ponta não elimina a necessidade de validação de conteúdo no cliente. Quando o serviço não consegue inspecionar o arquivo depois de cifrado, a validação deve ocorrer antes da criptografia e precisa considerar MIME, extensão, pré-visualização, contexto de renderização e capacidade do navegador de executar HTML dentro do domínio da aplicação. Para equipes de AppSec, esse caso reforça a necessidade de tratar clientes web de mensageiros, áreas de upload e renderização de mídia como superfícies de execução, não apenas como canais passivos de transporte.

• Reiniciar o navegador para carregar os clientes web corrigidos.
• Encerrar sessões de WhatsApp Web e Telegram Web que não sejam reconhecidas pelo usuário.
• Revisar mensagens e anexos enviados sem ação do titular da conta.
• Tratar anexos recebidos por mensageiros web como conteúdo ativo até que MIME, extensão e renderização sejam validados.
• Priorizar validação antes da criptografia em fluxos de upload cifrado e bloquear HTML disfarçado como mídia.