O gerenciador de senhas do Google tornou-se uma das principais ferramentas para armazenar credenciais e utilizar Passkeys, tecnologia criada para substituir senhas tradicionais por autenticação baseada em criptografia de chave pública. Entretanto, uma nova pesquisa da Unit 42, equipe de inteligência de ameaças da Palo Alto Networks, demonstra que, mesmo sem quebrar a criptografia do sistema, um invasor que já tenha comprometido o computador pode explorar falhas na lógica da implementação para sequestrar identidades digitais.
O estudo apresenta três novos vetores de ataque batizados de Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key, cada um explorando diferentes etapas da arquitetura utilizada pelo Google Chrome para gerenciar Passkeys. Em comum, todos compartilham uma característica importante: são ataques pós-comprometimento, ou seja, dependem da execução prévia de um malware no dispositivo da vítima.
Embora isso reduza o alcance desses ataques em comparação com campanhas remotas, a pesquisa chama a atenção porque demonstra que a segurança das Passkeys não depende apenas da robustez da criptografia, mas também da forma como navegadores, sistemas operacionais, provedores de credenciais e serviços online implementam o ecossistema WebAuthn. Para usuários, administradores de sistemas e profissionais de segurança, o trabalho representa um alerta importante sobre os desafios da autenticação sem senha.
O que são os ataques pós-comprometimento no gerenciador de senhas do Google
Ao contrário de ataques tradicionais que tentam quebrar senhas ou descriptografar bancos de dados, os ataques descritos pela Unit 42 assumem que o invasor já conquistou acesso ao computador por meio de um malware, um RAT, um infostealer ou outro código malicioso executado com privilégios do usuário.
Nesse cenário, o objetivo deixa de ser quebrar a criptografia utilizada pelo gerenciador de senhas do Google. Em vez disso, o malware passa a explorar informações presentes na memória do navegador, estruturas internas de armazenamento e processos responsáveis pelo gerenciamento das Passkeys.
No Windows, a arquitetura do Chrome utiliza recursos do próprio sistema operacional, incluindo o Trusted Platform Module (TPM) quando disponível, além da infraestrutura criptográfica baseada nas APIs Cryptography Next Generation (CNG). Essa combinação permite que chaves privadas permaneçam protegidas contra extração direta.
Entretanto, diversos componentes auxiliares ainda precisam armazenar metadados, identificadores e informações de configuração para permitir que o navegador reconheça dispositivos registrados, sincronize credenciais e execute operações relacionadas ao padrão WebAuthn.
É justamente nesse ecossistema que a pesquisa encontrou oportunidades para manipulação.
A estrutura de dados e chaves no Chromium
O Chromium, projeto de código aberto que serve de base para o Google Chrome, mantém diferentes estruturas responsáveis pelo gerenciamento das credenciais locais.
Parte dessas informações é armazenada em bancos LevelDB, contendo dados necessários para localizar credenciais, identificar dispositivos e manter o relacionamento entre contas, autenticadores e serviços.
Além disso, existe uma chave de identidade do dispositivo, utilizada durante o processo de autenticação para demonstrar que determinada Passkey pertence ao dispositivo previamente registrado.
Essa arquitetura foi criada para aumentar a segurança e a experiência do usuário, mas também amplia a superfície disponível para ataques quando um invasor já possui acesso local ao sistema.
A pesquisa deixa claro que o problema não está na quebra dos algoritmos criptográficos utilizados pelo Chrome, mas na manipulação da lógica responsável por utilizar essas chaves.
Como o gerenciador de senhas do Google protege as Passkeys
As Passkeys utilizam criptografia assimétrica.
Durante o registro, o navegador cria um par de chaves:
- Chave privada, mantida no dispositivo.
- Chave pública, enviada ao serviço online.
Quando ocorre um login, apenas a chave privada pode produzir uma assinatura válida para comprovar a identidade do usuário.
Na prática, isso elimina diversos ataques comuns contra senhas tradicionais, como reutilização de credenciais, phishing clássico e vazamentos de bancos de senhas.
Entretanto, caso um malware consiga manipular o ambiente local antes da assinatura criptográfica ou alterar o fluxo lógico utilizado pelo navegador, parte dessa proteção pode ser reduzida.
É exatamente essa hipótese que motivou os pesquisadores da Unit 42.
Os três caminhos de ataque explicados
Os pesquisadores dividiram suas descobertas em três famílias distintas, cada uma explorando um ponto diferente da arquitetura do gerenciador de senhas do Google e das Passkeys no Chrome.
Embora apresentem objetivos semelhantes, os métodos empregados são significativamente diferentes.
Pass-ta-key: falsificando a assinatura de identidade
O primeiro vetor, chamado Pass-ta-key, explora o processo utilizado para comprovar a identidade do dispositivo durante operações relacionadas às Passkeys.
Segundo a pesquisa, um malware pode utilizar as APIs CNG do Windows para produzir assinaturas que aparentam ser legítimas, explorando situações nas quais determinados serviços online deixam de validar corretamente informações críticas do protocolo.
Entre os elementos analisados está o bit User Verification (UV), indicador responsável por informar que houve autenticação local do usuário, normalmente por biometria, PIN ou outro método de verificação.
Caso uma parte confiável (Relying Party) deixe de validar corretamente esse indicador, existe a possibilidade de aceitar autenticações que não representam fielmente o estado real da verificação local.
Em outras palavras, a vulnerabilidade não está necessariamente no navegador, mas na implementação realizada pelo próprio site.
Esse detalhe transforma o ataque em um problema compartilhado entre navegadores, provedores de credenciais e serviços online.
Silver Pass-ta-key: sequestro do novo registro de dispositivo
O segundo vetor recebe o nome de Silver Pass-ta-key.
Nesse cenário, os pesquisadores identificaram um comportamento relacionado ao momento em que novas Passkeys são registradas.
Durante determinadas etapas do processo, a criação da chave utilizada para verificação do usuário ocorre posteriormente à geração de outros componentes da credencial.
Essa janela temporal permite que um malware residente substitua informações antes da conclusão do registro.
Na prática, o atacante pode fazer com que uma nova Passkey seja associada a uma chave controlada pelo invasor sem que o usuário perceba imediatamente.
Como consequência, futuras autenticações podem utilizar credenciais diferentes daquelas originalmente esperadas pelo proprietário do dispositivo.
Embora o ataque exija controle local do computador, ele demonstra que processos de registro também representam uma superfície importante para ataques pós-comprometimento.
Golden Pass-ta-key: extração do segredo de domínio de segurança
O ataque mais sofisticado apresentado pela pesquisa recebeu o nome de Golden Pass-ta-key.
Nesse caso, o alvo deixa de ser apenas o fluxo de autenticação e passa a ser um componente interno chamado Security Domain Secret (SDS).
Segundo os pesquisadores, esse segredo de 32 bytes permanece disponível na memória do Chrome durante determinadas operações.
Um malware capaz de ler a memória do processo pode capturar esse valor e utilizá-lo para interferir na proteção de chaves privadas relacionadas às Passkeys.
Além disso, a pesquisa demonstra cenários nos quais ocorre interceptação das operações envolvendo essas chaves antes que elas sejam efetivamente utilizadas.
É importante destacar que o estudo não afirma que o TPM foi quebrado nem que os algoritmos criptográficos utilizados pelo Chrome foram comprometidos.
O problema reside na disponibilidade temporária de informações sensíveis durante o processamento realizado pelo navegador.
Esse tipo de descoberta reforça a importância da proteção da memória contra códigos maliciosos já instalados no sistema.
Respostas das plataformas e recomendações de segurança
Após comunicar suas descobertas de forma responsável, os pesquisadores observaram respostas diferentes entre empresas afetadas pelo estudo.
Algumas plataformas, como eBay e GitHub, implementaram melhorias para validar corretamente o indicador User Verification (UV), reduzindo significativamente a eficácia de determinados cenários explorados pelo Pass-ta-key.
Já em relação ao ecossistema do Chrome, a pesquisa aponta que ainda existem desafios relacionados à rotação do Security Domain Secret, especialmente em cenários onde esse segredo possa ter sido exposto após um comprometimento do dispositivo.
Os pesquisadores também destacam recomendações para diferentes participantes do ecossistema.
Para as partes confiantes (sites):
- Validar corretamente todos os indicadores definidos pelo padrão WebAuthn.
- Exigir verificação do usuário quando apropriado.
- Não confiar apenas na presença de uma assinatura criptográfica.
- Revisar implementações de autenticação para garantir conformidade com as especificações.
Para os provedores de credenciais:
- Minimizar a permanência de segredos na memória.
- Implementar mecanismos de rotação de chaves sempre que possível.
- Reduzir a superfície de exposição durante processos de registro.
- Fortalecer proteções contra leitura de memória por processos maliciosos.
Para usuários finais, a principal recomendação permanece a mesma: impedir que o computador seja comprometido.
Como todos os ataques apresentados dependem da presença de malware em execução, manter o sistema operacional atualizado, utilizar soluções de proteção confiáveis, evitar softwares de origem desconhecida e limitar privilégios administrativos continuam sendo medidas extremamente eficazes.
Conclusão: por que essa pesquisa muda a discussão sobre Passkeys
A pesquisa da Unit 42 não representa o fim das Passkeys, nem demonstra uma quebra da criptografia utilizada pelo gerenciador de senhas do Google. Pelo contrário, ela reforça que a base criptográfica permanece sólida.
O verdadeiro aprendizado está em outro ponto: sistemas modernos de autenticação dependem não apenas de algoritmos seguros, mas também de implementações corretas em todas as camadas do ecossistema.
Os ataques Pass-ta-key, Silver Pass-ta-key e Golden Pass-ta-key mostram que um invasor capaz de executar código local ainda pode explorar falhas de lógica, estados intermediários da autenticação e informações temporariamente disponíveis na memória.
Isso torna ainda mais importante que desenvolvedores validem corretamente o bit User Verification (UV), que navegadores fortaleçam seus mecanismos internos de proteção e que usuários mantenham seus dispositivos livres de malwares.
À medida que as Passkeys substituem gradualmente as senhas tradicionais, pesquisas como essa ajudam toda a indústria a evoluir a segurança da autenticação moderna. O debate agora deixa de ser apenas sobre algoritmos criptográficos e passa a incluir arquitetura, implementação e proteção contra ataques pós-comprometimento, áreas que continuarão sendo fundamentais para a confiança no futuro da autenticação digital.
