- Pixnapping é uma nova técnica de ataque em que um app Android malicioso rouba secretamente informações pessoais exibidas em outros apps ou sites
- O ataque usa um canal lateral entre as APIs do Android e o hardware da GPU, afetando a maioria dos dispositivos recentes dos principais fabricantes, como Google e Samsung
- Todas as informações exibidas na tela, como códigos de autenticação, chats e e-mails, podem ser expostas, e o ataque é possível mesmo sem permissões de app
- No Google Authenticator, é possível roubar o código de autenticação em dois fatores em até 30 segundos
- Tanto o Google quanto os fornecedores de GPU ainda estão sem um patch ou contramedida confiável para mitigar o ataque
Visão geral
- Pixnapping é um ataque que permite que um app Android malicioso roube, sem o conhecimento do usuário, informações exibidas em outros apps ou sites
- O vazamento de informações ocorre por meio do abuso de um canal lateral (side channel) entre as APIs do Android e a GPU, e afeta a maioria dos smartphones Android recentes, incluindo dispositivos do Google e da Samsung
- Entre os apps comprovadamente afetados estão Gmail, Signal, Google Authenticator, Venmo, Google Maps, e até os códigos 2FA do Google Authenticator podem ser roubados em até 30 segundos
Artigo de pesquisa e demonstração
- Será apresentado na ACM CCS 2025 no artigo “Pixnapping: Bringing Pixel Stealing out of the Stone Age”
- O preprint do artigo permite verificar o princípio do ataque e seus detalhes
Principais perguntas e respostas
Quais dispositivos são afetados
- Foi demonstrado em Google Pixel 6, 7, 8, 9 e Samsung Galaxy S25 com Android 13~16
- Há grande chance de que o princípio central do ataque funcione da mesma forma em dispositivos de outros fabricantes
Condições do ataque
- Qualquer app Android sem permissões pode executar o ataque
- Ele pode ser ativado sem declarar permissões adicionais no arquivo de manifesto do app
Que informações podem ser roubadas
- Todas as informações exibidas na tela (chats, códigos de autenticação, e-mails etc.) são alvos do ataque
- Informações internas não exibidas na tela não podem ser vazadas
Casos de exploração real
- Ainda não foi confirmado se já está sendo explorado em ataques reais
Como os usuários podem se proteger
- Recomenda-se instalar imediatamente cada novo patch de segurança do Android assim que for lançado
Como os desenvolvedores podem se proteger
- No momento, não há medidas de defesa ou soluções alternativas eficazes confirmadas
- Se houver insights de segurança, os pesquisadores pedem que entrem em contato
Como o ataque funciona
- O app malicioso invoca o app-alvo (por exemplo, o Google Authenticator) para induzir a renderização de informações sensíveis
- Na tela do app-alvo, ele força a aplicação de uma operação gráfica (como blur) sobre pixels específicos
- Em seguida, usa um canal lateral como o GPU.zip para extrair, pixel por pixel, os pixels da etapa 2
- As etapas 2 e 3 são repetidas até reconstruir toda a imagem, e depois o conteúdo original é extraído por OCR
- O efeito é semelhante a tirar uma captura de tela de uma tela à qual o app malicioso normalmente não teria acesso
APIs do Android exploradas
- Usa a window blur API para aplicar processamento gráfico (blur) sobre regiões de pixels sensíveis
- Usa callbacks de VSync para medir o tempo de renderização e aproveitá-lo na extração pixel a pixel
Patch e resposta do Google
- O Google respondeu limitando a quantidade de atividades com blur que um app pode invocar, mas logo foi encontrado um workaround
- Esse workaround permanece atualmente sob embargo e não foi divulgado
Canal lateral em nível de hardware
- As informações dos pixels são extraídas por um canal lateral baseado em GPU chamado GPU.zip
- Em outubro de 2025, nenhum fabricante de GPU tinha um plano específico de patch
Identificação da vulnerabilidade (CVE)
- Foi oficialmente registrado como CVE-2025-48561
Impacto em outros sistemas operacionais
- O Android se torna alvo porque permite que apps realizem operações gráficas sobre dados de tela de outros apps e meçam efeitos colaterais
- Ainda não foi confirmado se isso pode ser aplicado a outros sistemas operacionais
Vulnerabilidade adicional de App List Bypass
- Também existe uma vulnerabilidade de app list bypass que permite identificar a lista de outros apps instalados sem permissões extras nem declarações no manifesto
- Ela pode ser usada para profiling de usuários e, ao contrário dos métodos de bypass anteriores, funciona sem declarações adicionais
- O Google classificou isso como “Infeasible” e encerrou o caso sem ação adicional
Logo, código-fonte e licença
Resposta e cronograma principal
- Entre fevereiro e outubro de 2025, a vulnerabilidade foi divulgada de forma escalonada ao Google e à Samsung, com pedidos de resposta
- O Google classificou o risco de Pixnapping e app list bypass como High/Low, e concluiu que alguns patches eram insuficientes ou inviáveis (sem correção possível)
- Patches adicionais estão previstos para o boletim de segurança do Android de dezembro de 2025
Resumo
- Pixnapping é um ataque que pode vazar indevidamente informações importantes da tela real explorando uma combinação de falhas na estrutura de permissões dos apps e no funcionamento do hardware
- Tanto a segurança de software quanto a de hardware no Android ainda precisam de melhorias estruturais
1 comentários
Comentários no Hacker News
Na minha opinião, o problema central é que o sistema de permissões do Android permite por padrão coisas como "executar em segundo plano" ou "acesso à internet" sem consentimento do usuário; esse tipo de ataque é possível porque todo app — até mesmo jogos offline — tem essas permissões por padrão. Muitos apps só deveriam ter acesso à internet "enquanto o app estiver em uso" e, embora isso não seja uma proteção perfeita, como sempre existe o risco de executar um app malicioso por engano, isso pode reduzir bastante a eficácia do ataque.
Fico curioso se existe alguma pesquisa séria sobre os riscos de atualização automática versus atualização manual/não atualização, especialmente em ambientes meio sandboxados como o Android; queria saber se há estudos comparando taxas de falha.
Na verdade, a permissão de acesso à internet existe, e no GrapheneOS é possível negar totalmente o acesso à internet para apps que declaram essa permissão.
Existe uma resposta convincente para o motivo de apps Android não pedirem permissão de internet ao usuário; é uma resposta direta da equipe de desenvolvimento do Android fonte. Quanto à questão de "executar em segundo plano", como o Android é baseado em "intents", um app pode ser despertado a qualquer momento, então uma opção simples de "proibir execução em segundo plano" pode não funcionar da forma que o usuário espera.
Mesmo vendo o vídeo, ainda acho difícil entender como esse ataque funciona; fico em dúvida se ainda é possível acessar os pixels do app autenticador depois de trocar de app.
Sobre a pergunta de como um desenvolvedor de app pode proteger os usuários, embora digam que não há contramedidas públicas, acho que existem algumas tentativas básicas, por exemplo: não fixar a posição do código na tela, ocultá-lo em segundo plano, mantê-lo em movimento, alterar cor e contraste, exibir ruído estático, fazer apenas partes do código piscarem brevemente em vez do código inteiro etc. Claro que isso impactaria um pouco a UX, mas, em teoria, pode elevar bastante a dificuldade para o atacante. Dito isso, também menciono que há limites se já existir informação secreta em cache por screenshot.
Lembro que o Google Authenticator mudou no passado para exibir o código TOTP só após toque; na época achei que isso não bloqueava nenhuma ameaça real e só atrapalhava, e muita gente concordou, então pouco depois a função foi revertida discretamente. Fico curioso se aquilo era uma mitigação prévia para essa falha.
Apresenta uma demo em unscreenshottable.vercel.app.
Enfatiza que, para esse ataque ser realmente viável contra TOTP, é preciso conhecer perfeitamente a fonte e a posição dos pixels; segundo o artigo, leva bastante tempo para roubar regiões sensíveis da tela e, por exemplo, códigos 2FA são atualizados a cada 30 segundos por padrão, então há um limite de tempo rígido. Se o atacante não exfiltrar todos os 6 dígitos em 30 segundos, o valor desaparece. Ainda assim, se a fonte for conhecida pelo atacante, pode ser possível distinguir o código vazando apenas alguns pixels.
Embora seja uma técnica que já existia antes, afirma que ela é muito eficaz para atingir alvos com precisão. Se você consegue instalar um app específico no celular do usuário, nem precisa complicar tanto: pode simplesmente acessar diretamente pelo app as informações desejadas. Por exemplo, se um app como o Facebook mostrasse um aviso de privacidade dizendo "este app captura a tela periodicamente", um número surpreendente de pessoas permitiria mesmo assim. Disseram que o código-fonte do Pixnapping será publicado aqui quando for possível aplicar patch, mas na prática nem deve ser tão difícil fazer engenharia reversa. Eles poderiam ter esperado até sair o patch, mas parece que os pesquisadores quiseram chamar atenção mais cedo.
Na verdade, o patch da vulnerabilidade original já foi publicado; até a mensagem deste commit relacionado diz explicitamente que serve para "impedir roubo de pixels medindo o tempo de blur entre janelas". O motivo de os pesquisadores não publicarem o código é que encontraram um jeito de contornar esse patch. Além disso, mencionam que "não há fornecedor de GPU que tenha prometido corrigir o GPU.zip" e que "o Google também não pretende corrigir a vulnerabilidade de bypass da lista de apps" ("encerrado como não corrigível"). Considerando que a data do primeiro reporte foi 24 de fevereiro de 2025, é difícil dizer que os pesquisadores foram apressados. E, mesmo que exista um aviso de "este app captura a tela periodicamente", telas explicitamente marcadas como não capturáveis por screenshot não podem ser capturadas sem um exploit separado.
A data do primeiro reporte ao Google foi 24 de fevereiro de 2025; deram tempo suficiente.
Reconhece que esse ataque é uma técnica inteligente que explora o tempo de renderização (side channel), e comenta que, mesmo no Google Authenticator, levaria um bom tempo para coletar todos os pixels. Na verdade, preocupa mais o quanto esse método pode ser aplicável para roubar OTPs de mensagens de texto. Como também têm aumentado os e-mails de phishing com padrão fixo, como notificações do GitHub por e-mail, parei completamente de clicar em links em e-mails; agora também acho melhor evitar abrir apps por recomendações de intent. É melhor abrir o app diretamente para fazer o que precisa e apagar apps inúteis. A superfície de ataque também pode se expandir por SDKs ou intents de páginas web, e isso parece muito subestimado.
Pelo título, achei que fosse um jogo de navegador e fui procurar por isso.
Não sou especialista em segurança, mas acho que, ao instalar um app no desktop Windows, seria possível atacar de forma muito mais rápida e discreta do que com o pixnapping no Android. Se você usa a mesma senha em vários sites, um deles pode roubar a senha e fazer login em outro lugar (se não houver outra camada de segurança). Em teoria a segurança é fraca, mas, na prática, esse tipo de ataque não é tão comum nem tão fácil de executar.
Indica o link para a discussão anterior.
Acho que os dispositivos modernos ficaram complexos demais para permitir segurança completa; parece que isso acontece porque continuam adicionando infinitos recursos desnecessários. Acredito que, daqui para frente, vai crescer cada vez mais a demanda por sistemas operacionais focados em segurança com funcionalidade mínima, como o FreeBSD.
Quero um ambiente em que eu possa dar
make worldno terminal até em trânsito.Existe o Precursor, feito pelo bunnie; achei legal, mas caro demais. Se você acha caro pagar US$ 100 num calculadora, o Precursor tem formato parecido e capacidade de cálculo parecida, mas custa US$ 1000, e nem dá para usar em prova de matemática. Blog oficial do Precursor (atualmente fora do ar, talvez volte depois).
Ao longo de vários anos lendo comentários no HN, passei a sentir que o conhecimento e as práticas de segurança regrediram bastante, e acho que a popularização da IA generativa vai piorar ainda mais a situação. Hoje em dia também há muita conversa sobre projetos de telefone da FSF junto com reclamações de que usar app de banco no celular é inconveniente. Também tem gente dizendo que é chato digitar senha a cada 30 minutos no desktop, e muita reclamação do tipo "preciso ter dois celulares?". Do meu ponto de vista, se um ladrão roubar seu celular depois de observar você digitando a senha, vai abrir imediatamente o app do banco, app de dinheiro e tudo que puder para extrair o máximo de dados possível. Crimes assim acontecem literalmente todos os dias. O ideal é nem instalar esses apps no telefone, ou ao menos não deixá-los logados; o mesmo vale para apps de 2FA. É como exibir um alvo, tal qual andar com uma mala de viagem de marca cara. A menos que você seja CEO ou alvo de nível estatal, deveria ser ainda mais cuidadoso. Mesmo um dispositivo com "SO de segurança com funções mínimas" continua tendo essencialmente o mesmo problema de roubo físico (alguém vê a senha e leva o aparelho), mas é importante separar rigidamente um celular usado em bar para jogos e apps cheios de anúncios de outro usado para banco, 2FA e trabalho.