CVE-2024-29748

Falha de lógica no firmware dos dispositivos Google Pixel que permite a um atacante com acesso físico interromper um processo de reset de fábrica (wipe) disparado remotamente via Device Admin API. Na prática, isso derrota o principal controle anti-roubo/anti-perícia dos dispositivos: um wipe remoto acionado por um MDM ou pelo próprio usuário para destruir dados pode ser abortado antes de terminar, preservando o conteúdo do aparelho para extração posterior. O EPSS baixo (0.0068) contrasta com a presença no KEV da CISA — o Google já sinalizou 'exploração limitada e direcionada', compatível com uso por ferramentas forenses/de extração, não com exploração em massa.

O bug está no componente 'Pixel Firmware' (bug interno do Google A-318507188), catalogado pela CISA como CWE-280 (tratamento inadequado de permissões/privilégios insuficientes). Quando um app com privilégio de administrador de dispositivo (Device Admin API, DevicePolicyManager.wipeData()) dispara um apagamento remoto — cenário típico de MDM corporativo ou de recursos 'apague meu dispositivo' —, o firmware deveria conduzir a sequência de wipe até o fim sem possibilidade de interrupção por um usuário local sem privilégios adicionais. A lógica falha permite que essa sequência seja interrompida antes da conclusão.

O vetor CVSS (AV:L/AC:L/PR:N/UI:R) resume o pré-requisito real: acesso local ao aparelho, nenhuma execução privilegiada prévia necessária, mas interação do usuário/atacante é obrigatória para acionar a interrupção — ou seja, quem exploraria isso precisa manipular o dispositivo fisicamente durante a janela do wipe. A confidencialidade, integridade e disponibilidade impactadas ao máximo (C:H/I:H/A:H) refletem que o resultado final é acesso total aos dados que deveriam ter sido destruídos.

Segundo a GrapheneOS, que reportou o problema, apps que usam a API de administração de dispositivo para apagar dados 'não oferecem nenhuma segurança contra um atacante local, já que é possível interromper o processo' — e afirma que empresas forenses já tinham conhecimento disso antes da correção pública, o que reforça a hipótese de exploração direcionada citada pelo Google.

O exploit não é remoto: exige posse física do aparelho no momento em que um wipe é disparado via Device Admin API. O cenário de abuso descrito pela GrapheneOS é justamente o inverso do que a manchete 'privilege escalation' sugere — não se trata de um app malicioso escalando privilégios sozinho, mas de um agente com acesso físico ao hardware (por exemplo, quem está de posse de um dispositivo apreendido ou roubado) interrompendo um comando de apagamento remoto antes que ele termine, preservando os dados originais.

Isso é relevante para quem depende de wipe remoto como controle de segurança institucional (MDM corporativo, 'Find My Device', apps de segurança que apagam o aparelho após tentativas de acesso). Se o atacante consegue manter o aparelho ligado e interagir com ele durante a janela de wipe, a proteção falha silenciosamente — o comando é recebido, mas não chega a ser concluído.

A presença no catálogo KEV da CISA confirma exploração ativa observada, e o próprio bulletin do Google já indicava 'indicações de exploração limitada e direcionada' junto com a CVE-2024-29745 (falha relacionada, no bootloader). Não há EPSS alto porque não é um vetor de exploração em massa via internet — é uma técnica de nicho, típica de cadeias de perícia digital contra dispositivos apreendidos.

Atualizar dispositivos Google Pixel para o nível de patch de segurança 2024-04-05 ou posterior corrige o problema, segundo o Pixel Update Bulletin de abril de 2024. A CISA, ao incluir a falha no KEV, orienta aplicar as mitigações do fornecedor ou descontinuar o uso do produto se a correção não estiver disponível — o que, na prática, significa que não há paliativo de configuração conhecido para quem não pode atualizar.

A GrapheneOS alertou que a correção do Google, mesmo após o patch, é parcial: o projeto identificou trabalho em andamento ('wipe-without-reboot') que sugere que a solução completa ainda não estava pronta em abril de 2024. Isso significa que mesmo dispositivos atualizados podem não ter eliminado totalmente a janela de interrupção — não há confirmação pública posterior sobre quando o fix completo foi entregue.

Não há mitigação eficaz baseada em rede, WAF ou configuração de app, porque o problema está no firmware que processa o comando de wipe, não em uma superfície remota exposta. Confiar em wipe remoto via Device Admin API como único controle contra exposição de dados em caso de perda/roubo do aparelho é, por definição, insuficiente enquanto o dispositivo não estiver no patch corrigido — criptografia de disco completa e bloqueio de tela continuam sendo os controles que realmente impedem acesso aos dados, independentemente do resultado do wipe.

Não há assinatura de rede ou log remoto confiável, já que a exploração é local e física — não gera tráfego nem chamada de API anômala visível a um SOC. O sinal mais próximo de evidência seria um registro de MDM/gestão de dispositivos mostrando que um comando de wipe foi emitido e confirmado como enviado, mas o dispositivo nunca reportou conclusão do apagamento ou retornou ao estado de fábrica esperado — uma discrepância entre 'comando enviado' e 'wipe concluído' nos logs do sistema de gestão é o indicador prático disponível, mas não é garantia de exploração desta CVE especificamente.