Falha no WhatsApp permitia infecção por chamada de voz antes do atendimento

A vulnerabilidade CVE-2019-3568 envolvia estouro de buffer no processamento de pacotes SRTCP e podia ser acionada por chamadas VoIP especialmente construídas, sem interação da vítima.

Componente	Implementação própria de SRTCP do WhatsApp, escrita em código nativo C/C++, no fluxo de chamadas de voz.
Vetor	Chamadas VoIP especialmente construídas enviadas ao alvo, com processamento de pacotes antes de a chamada ser atendida.
Impacto	Estouro de buffer no tratamento de pacotes de rede, associado à injeção de spyware em telefones das vítimas conforme o relato público disponível.
Prioridade	Garantir atualização do WhatsApp para versão corrigida, revisar sinais de chamadas suspeitas e tratar dispositivos potencialmente expostos como endpoints de alto risco.
Versões	A análise de correção citada comparou a versão Android v2.19.134, programa de 32 bits, em busca das alterações relacionadas à CVE-2019-3568.
Artefatos	Foram observadas duas validações novas de tamanho no módulo SRTCP, incluindo verificação de argumento de comprimento contra limite máximo de 1480 bytes, ou 0x5C8.

Resumo técnico

A vulnerabilidade CVE-2019-3568 afetava o WhatsApp no processamento de chamadas de voz e foi descrita como uma falha crítica de estouro de buffer no protocolo SRTCP. O ponto central do caso é que a exploração não dependia de clique, resposta à chamada ou qualquer ação explícita da vítima. O fluxo vulnerável era alcançado durante o tratamento inicial de pacotes associados à chamada VoIP, antes de a ligação ser aceita pelo usuário. Essa característica amplia o risco operacional porque transforma uma tentativa de chamada em superfície de ataque suficiente para atingir o código responsável por analisar pacotes de mídia e controle.

O aplicativo é usado em grande escala em Android e iPhone, e o contexto técnico recebido indica que a falha estava sendo usada ativamente para injetar spyware em telefones. O impacto confirmado deve ser entendido dentro desse limite: o problema está no processamento de pacotes de chamada e na possibilidade de corrupção de memória por estouro de buffer, com associação a instalação de spyware no relato público. Não há, no material fornecido, lista de indicadores, nomes de vítimas, hash de amostras, família de malware, infraestrutura de comando e controle ou detalhes sobre persistência posterior. A defesa deve separar a vulnerabilidade no parser de mídia do comportamento do spyware instalado, pois o segundo estágio não foi detalhado no contexto.

Fluxo técnico

A falha fica no caminho de processamento de SRTCP, protocolo relacionado ao controle seguro de tráfego em tempo real usado no contexto de chamadas. O WhatsApp mantinha uma implementação própria desse componente em código nativo C/C++, fora da camada Java no caso analisado para Android. Isso é tecnicamente importante porque erros de validação de tamanho em parsers nativos tendem a produzir falhas de memória mais graves do que simples exceções gerenciadas. Ao receber pacotes especialmente formatados durante uma chamada VoIP, o aplicativo encaminhava dados para uma função relevante do módulo RTCP antes da resposta do usuário, permitindo que o fluxo vulnerável fosse atingido no estágio inicial da chamada.

A análise da versão corrigida para Android v2.19.134, em binário de 32 bits, identificou duas alterações compatíveis com correção de estouro de buffer no módulo SRTCP. Uma delas aparece no início de uma função principal de tratamento RTCP e adiciona uma validação do argumento de comprimento contra um tamanho máximo de 1480 bytes, representado como 0x5C8. A segunda alteração reutiliza a mesma variável de comprimento em uma checagem adicional, acompanhada de uma string de registro que descreve explicitamente a validação como saneamento para evitar possível overflow. Esses elementos indicam que a correção reduziu a confiança em campos de tamanho vindos do fluxo de rede e passou a bloquear comprimentos incompatíveis antes da manipulação em memória.

O detalhe mais sensível para defesa é a posição do parser no ciclo de chamada. Como a função era chamada antes de a ligação ser atendida, controles baseados apenas em comportamento do usuário, treinamento contra clique ou bloqueio de links não cobririam esse vetor. A exposição depende do recebimento e processamento de pacotes de chamada, não de abertura de anexo ou navegação web. Também não há base no contexto para afirmar que todo dispositivo vulnerável foi comprometido; a condição comprovada é que uma chamada VoIP construída para explorar a falha podia alcançar o caminho de parsing vulnerável e acionar a corrupção de memória que a correção buscou impedir.

Superfície afetada

A superfície afetada envolve instalações do WhatsApp capazes de receber chamadas de voz no período anterior à correção da CVE-2019-3568. O contexto menciona explicitamente Android e iPhone como plataformas de uso do aplicativo, mas a análise de patch descrita se concentrou em Android v2.19.134, programa de 32 bits. Portanto, a presença da alteração nessa versão corrigida não deve ser lida como lista completa de versões afetadas. O dado técnico disponível permite afirmar que o módulo SRTCP do aplicativo era o componente analisado e que o caminho de chamada de voz era o vetor.

Ambientes corporativos com uso de WhatsApp em dispositivos pessoais ou gerenciados devem considerar a falha como risco de endpoint móvel, especialmente quando o aparelho acessa contas, mensagens, contatos, documentos internos ou canais de autenticação. O contexto não descreve roubo de dados, movimentação lateral, credenciais capturadas ou técnicas de pós-exploração, então esses efeitos não devem ser tratados como consequência confirmada da vulnerabilidade. O que se sustenta tecnicamente é a possibilidade de exploração remota via chamada e a associação do caso à instalação de spyware em telefones alvejados.

• Aplicativo WhatsApp em telefones Android e iPhone expostos ao recebimento de chamadas VoIP no período anterior ao patch.
• Módulo SRTCP implementado em C/C++, com parsing de pacotes de controle de mídia em código nativo.
• Fluxo de chamada alcançado antes de a vítima atender, reduzindo a utilidade de defesas baseadas somente em interação do usuário.
• Correção observada em Android v2.19.134 de 32 bits, com validações novas de comprimento no tratamento RTCP.

Hunting e telemetria

A telemetria mais útil deve partir do evento inicial: chamadas de voz recebidas de origem desconhecida ou incomum perto do período de exposição, principalmente quando acompanhadas de comportamento anômalo do aplicativo ou do sistema. O contexto não fornece IoCs de rede, domínios, endereços IP, hashes ou nomes de processos relacionados ao spyware, então a investigação não deve depender de indicadores estáticos inexistentes. Em vez disso, a defesa deve correlacionar registros de chamadas, eventos do aplicativo, alertas de EDR móvel e sinais de instabilidade, travamento ou atualização emergencial do WhatsApp.

Em dispositivos móveis gerenciados, a busca deve priorizar inventário de versões do aplicativo, datas de atualização, permissões sensíveis e eventos em torno de chamadas não atendidas. Como a exploração podia ocorrer antes do atendimento, chamadas perdidas não devem ser descartadas como ruído operacional. Onde houver MDM, os times devem verificar se a versão instalada foi atualizada para uma compilação corrigida e se houve dispositivos que permaneceram sem atualização após a divulgação pública da falha. Em ambientes sem MDM, o caminho defensivo é coletar evidências do próprio aparelho com cuidado forense, evitando ações que apaguem artefatos voláteis.

A ausência de indicadores no material recebido impõe limite de atribuição. Não há nomes técnicos de infraestrutura, cadeia completa de infecção, persistência ou comandos de controle. Assim, hunting baseado em assinatura teria baixa cobertura se for construído apenas a partir desse contexto. A abordagem mais defensável é combinar linha do tempo de chamadas, versão do aplicativo, sinais de comprometimento móvel e qualquer alerta independente de spyware coletado por ferramentas de segurança do dispositivo.

• Chamadas VoIP recebidas e não atendidas de remetentes incomuns no período de exposição.
• Dispositivos com WhatsApp sem atualização após a disponibilidade de versão corrigida.
• Eventos de falha, reinicialização do aplicativo ou comportamento anômalo próximos a chamadas suspeitas.
• Mudanças inesperadas em permissões, perfis de gerenciamento, consumo de rede ou atividade em segundo plano no telefone.
• Alertas de solução MDM ou EDR móvel relacionados a spyware, integridade do sistema ou aplicativo de mensagens.

Mitigação

A primeira medida é confirmar que o WhatsApp foi atualizado para uma versão corrigida em todos os dispositivos sob responsabilidade da organização ou de usuários de alto risco. A mitigação precisa ser tratada como atualização de aplicativo móvel e não apenas como bloqueio de rede, porque o componente vulnerável está no parser interno usado pelo fluxo de chamada. Quando houver gestão corporativa, o MDM deve impor versão mínima, registrar exceções e remover dispositivos sem conformidade de fluxos sensíveis até a validação. Para usuários individuais, a prioridade é atualizar pelo canal oficial da plataforma e reiniciar o aplicativo ou o dispositivo quando exigido pelo sistema.

Dispositivos com sinais compatíveis com exploração devem ser isolados do acesso a contas críticas até avaliação. A resposta deve preservar evidências de chamadas e eventos do aplicativo, revisar sessões autenticadas em serviços corporativos e avaliar necessidade de troca de credenciais usadas no aparelho, sem assumir roubo de dados quando não houver evidência. Como o contexto técnico não descreve o spyware instalado, a contenção deve ser baseada em sinais observáveis do endpoint e em procedimentos de resposta móvel, incluindo análise por ferramenta confiável, revisão de perfis instalados e validação de integridade do sistema.

A correção também traz uma lição de engenharia: parsers de protocolos complexos em código nativo devem validar comprimentos antes de qualquer operação de cópia, indexação ou alocação dependente de dados de rede. As duas checagens adicionadas no módulo SRTCP, incluindo o limite de 1480 bytes, apontam para saneamento defensivo de tamanhos como controle essencial. Como o próprio módulo é descrito como grande e complexo, o risco residual de outras falhas de parsing não pode ser descartado apenas pela correção dessa CVE. Para organizações, isso reforça a necessidade de ciclo contínuo de atualização de aplicativos de comunicação, visibilidade sobre versões móveis e monitoramento de chamadas suspeitas em usuários com maior exposição.

• Atualizar o WhatsApp em todos os dispositivos e verificar conformidade por inventário ou MDM.
• Tratar chamadas suspeitas anteriores à atualização como eventos relevantes, mesmo quando não foram atendidas.
• Preservar registros e artefatos do dispositivo antes de redefinições ou reinstalações quando houver suspeita de exploração.
• Revisar sessões, tokens de acesso e contas usadas no telefone se houver sinais independentes de comprometimento.
• Manter política de atualização rápida para aplicativos de comunicação que processam mídia e chamadas em código nativo.