Pass-ta-key: o que o ataque às passkeys da Google realmente significa

As passkeys são afinal inseguras? É precisamente essa a pergunta levantada pelo Pass-ta-key.

A Palo Alto Networks Unit 42 descreve três cadeias de ataque com as quais malware pode abusar de passkeys sincronizadas pela Google, contornar a verificação do utilizador e, no cenário mais grave, extrair todas as chaves privadas de passkeys de uma conta.

Nenhuma técnica quebra WebAuthn, FIDO2 ou a criptografia de chave pública. Todas exigem malware já em execução no PC Windows da vítima. É uma limitação significativa. Ainda assim, dizer que num endpoint comprometido tudo já está perdido é uma análise demasiado cómoda: Golden Pass-ta-key pretende transformar uma intrusão local num pacote exportável e duradouro de todas as passkeys sincronizadas, muito além do roubo de uma sessão.

A avaliação resumida

Sim, é um tema de segurança novo e independente. Mas não é motivo para abandonar passkeys ou regressar exclusivamente às palavras-passe.

• O protocolo resiste: Origin Binding, challenge-response e criptografia assimétrica não são quebrados.
• Uma implementação concreta é atacada: Google Password Manager, Chrome, Windows e TPM na combinação estudada pela Unit 42.
• O endpoint tem de estar comprometido: um site arbitrário não executa isto pela Internet contra um computador limpo.
• O impacto pode ser elevado: desde uma assertion criada silenciosamente até à extração de todas as chaves privadas sincronizadas.
• Passkeys sincronizadas e vinculadas ao dispositivo têm riscos diferentes: ambas são passkeys, mas não o mesmo nível de assurance.
• As palavras-passe continuam piores: também podem sofrer phishing, reutilização, adivinhação e roubo de bases de dados.

A minha avaliação é: âmbito técnico limitado e pré-condições exigentes, mas impacto potencialmente muito elevado se o ataque resultar.

Âmbito técnico e evidência

O estado comprovado em 31 de agosto de 2026 inclui os fluxos da Unit 42, a especificação WebAuthn, a documentação Google, a issue pública do Chromium e as regras NIST para autenticadores sincronizáveis. Pass-the-Passkey da SpecterOps, CVE-2026-34348, o downgrade FIDO da Proofpoint e os resultados da Expel e SquareX completam a superfície analisada.

A investigação foi publicada a 3 de agosto e atualizada a 14. Refere-se expressamente ao Google Password Manager no Chrome sobre Windows, em dispositivos com Trusted Platform Module. Outros sistemas podem ter questões semelhantes, mas estes três ataques não foram demonstrados neles.

Não está documentada qualquer campanha ativa com estas técnicas específicas. A evidência consiste em investigação, Proofs of Concept e Responsible Disclosure. Demonstração técnica não significa exploração massiva.

O que uma passkey realmente protege

Uma passkey não é uma palavra-passe longa, mas uma credencial WebAuthn baseada em criptografia assimétrica.

private key -> remains with the authenticator
public key  -> is registered with the online service

A Relying Party guarda a chave pública, a Credential ID e a conta. No login envia um challenge novo e aleatório. O autenticador assina dados que ligam o challenge ao contexto do site, e o servidor verifica a assinatura.

A chave privada não é transmitida como palavra-passe. Uma fuga no serviço fornece idealmente apenas chaves públicas, incapazes de produzir assinaturas. A ligação à Relying Party ID e origem web impede uma passkey de example.com de produzir, num domínio semelhante, uma assertion válida para example.com. Não existe um segredo que o utilizador possa digitar no site errado ou revelar ao telefone.

Isto significa resistente ao phishing. O NIST exige que um verifier fraudulento não obtenha o segredo nem uma resposta reutilizável no serviço legítimo. WebAuthn garante-o através da ligação criptográfica ao nome do verifier. Pass-ta-key não altera essa propriedade: o malware já está no dispositivo confiável.

User Presence e User Verification não são iguais

• User Presence, UP: o utilizador realizou uma ação de presença, como tocar numa security key ou confirmar um diálogo.
• User Verification, UV: o autenticador verificou localmente o utilizador com Windows Hello, PIN ou biometria.

A assertion inclui os resultados nos flags de authenticatorData. Se o servidor pedir userVerification: "required", deve verificar o flag UV recebido. A Unit 42 não concluiu o ataque simples contra o GitHub por falta de UV. No eBay, o login funcionava inicialmente apesar do requisito, até a validação do servidor ser corrigida.

Uma assinatura correta não basta sempre para MFA corretamente implementada. A Relying Party deve validar as condições realmente confirmadas.

Porque a sincronização amplia a confiança

Uma passkey vinculada ao dispositivo permanece num autenticador específico. Uma sincronizada precisa de ser cifrada, transportada e restaurada noutros dispositivos autorizados.

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

Cada camada exige regras de confiança, onboarding, recuperação, cifragem e revogação. O NIST trata por isso os autenticadores sincronizáveis separadamente: podem servir até Authentication Assurance Level 2; AAL3 exige chaves não exportáveis protegidas por hardware ou um autenticador separado. Não são fracos, mas comodidade e portabilidade criam outro modelo de assurance. Pass-ta-key atua precisamente aqui.

O âmbito exato da investigação

Os requisitos são: Google Password Manager gere as passkeys, Chrome corre no Windows, existe TPM, malware já corre como utilizador, o ambiente Google está configurado e certas variantes leem dados locais, alteram estados ou inspecionam memória do Chrome.

Não foi demonstrado um ataque universal nem uma extração remota de uma chave WebAuthn do TPM sem comprometer o endpoint. A formulação precisa é: a Unit 42 demonstrou três cadeias contra confiança, onboarding e recuperação de passkeys Google sincronizadas em endpoints Windows comprometidos.

Fase zero: o mapa local de passkeys

O malware lê primeiro a base de sincronização do Chrome. Os registos WebauthnCredentialSpecifics incluem Relying Party, utilizador, Credential ID e material cifrado das chaves privadas.

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

No teste, o acesso não exigia privilégios elevados. As chaves não estavam em claro, mas os metadados revelavam serviços, contas e Credential IDs. Um infostealer pode inventariar e selecionar alvos valiosos.

Pass-ta-key: uma assertion válida sem ação do utilizador

A primeira variante abusa da Identity Key com que o Chrome prova a identidade do dispositivo ao Google Cloud Authenticator. A chave é suportada pelo TPM e exportada via Windows CNG como NCRYPT_OPAQUE_KEY_BLOB, reutilizável no mesmo TPM.

Isso protege criptograficamente, mas não resolve autorização. Malware no contexto normal podia ler wrapped_identity_private_key ou obtê-la da memória e chamar Windows CNG. O TPM assina porque o pedido vem tecnicamente do dispositivo certo, sem saber se foi Chrome ou malware.

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

O dispositivo e a cloud tornam-se um serviço de assinatura sem exportar necessariamente a passkey. O limite é UV: a Identity Key prova posse do dispositivo, não PIN ou biometria. Um serviço que exige e verifica UV rejeita UV = 0. Muitos usam porém preferred ou validam mal, reduzindo o login ao acesso à identidade do dispositivo.

Silver Pass-ta-key: o atacante regista a sua identidade UV

Silver ultrapassa esse limite sem quebrar Windows Hello. O malware faz o Cloud Authenticator esquecer o dispositivo ou elimina passkey_enclave_state, forçando re-onboarding. No Windows, o Chrome pode usar primeiro o PIN de recuperação do Google Password Manager, definir uv_key_pending e criar a verdadeira UV Key apenas na utilização seguinte.

A vítima introduz o PIN GPM no processo inesperado, mas o malware não precisa de o roubar. O atacante gera um par de chaves e envia a pública como nova UV Key. Segundo a Unit 42, Cloud Authenticator não verificava uma origem de hardware confiável e associava-a à identidade legítima.

O atacante passa a assinar sozinho; Cloud Authenticator interpreta-o como verificação local e cria assertions com UV mesmo com o PC da vítima offline. A issue «GPM Passkeys Are Vulnerable to User Verification Key Abuse» estava marcada WAI quando a verifiquei. A regra mantém-se: onboarding e recuperação que vinculam novas chaves confiáveis são eventos críticos de autenticação.

Golden Pass-ta-key: da cloud para chaves exportáveis

A variante mais grave visa o Security Domain Secret, SDS, de 32 bytes, que protege as chaves privadas sincronizadas de uma conta Google Password Manager. O cliente deveria possuir apenas um wrapped_secret cifrado, decifrado no Cloud Authenticator por uma chave específica do dispositivo.

Durante onboarding e recuperação, porém, dispositivos têm de entrar na Security Domain. A Unit 42 descobriu que o Chrome recebe então o SDS de forma acessível ao cliente. Inicialmente surgia no log FIDO do Chrome. A Google removeu essa saída, mas o SDS continua a passar pela memória durante o processo.

O malware tem de forçar o percurso e ler a memória no instante correto:

1. Força novo onboarding.
2. Aguarda a criação ou alteração do estado local do enclave.
3. Lê a memória do Chrome e procura o SDS.
4. Combina-o com os registos de sincronização já lidos.
5. Decifra as chaves privadas.
6. Um autenticador independente do dispositivo da vítima produz assertions válidas.

Uma sessão pode expirar ou ser revogada. Golden pretende exportar todas as chaves já sincronizadas. A Unit 42 afirma ainda que o mesmo SDS protege futuras passkeys e que não havia rotação ou revogação visível. Isto descreve a implementação estudada, não todos os providers nem uma arquitetura imutável.

Porque malware local não torna o ataque irrelevante

Malware local pode já roubar cookies, ler o browser, manipular transações, exfiltrar ficheiros ou agir na conta. Nenhum método confia ilimitadamente num cliente comprometido, e infostealers roubam segredos de browsers há anos.

Ainda assim, a investigação mostra algo específico: processo sem privilégios usava uma chave Chrome ligada ao TPM; a fronteira dispositivo/utilizador dependia de UV; re-onboarding admitia uma UV Key hostil; o segredo central aparecia em log e memória; o pior caminho tornava chaves utilizáveis fora do dispositivo; contadores de assinatura nem sempre detetam clonagem de credenciais sincronizadas entre dispositivos.

«Endpoint comprometido» é requisito, não descrição do dano. Em Incident Response, uma sessão temporária e chaves privadas duradouras para muitos serviços são situações diferentes.

Pass-ta-key é apenas parte da nova superfície

Investigações de 2025 e 2026 mostram vários caminhos sem quebrar chaves: Pass-ta-key abusa da sincronização após infeção; Pass-the-Passkey combina uma assertion registada com replay no servidor; downgrade FIDO explora um fallback sujeito a phishing; Passkeys Pwned exige extensão ou script malicioso; infostealers roubam a sessão autenticada.

Todos atacam camadas de confiança em redor de WebAuthn, não a criptografia: recuperação, validação do servidor, browser ou sessão. Uma quebra do protocolo afetaria todas as implementações; estes casos exigem defesas distintas.

Pass-the-Passkey: reutilizar uma assertion válida

Para a Black Hat USA 2026, a SpecterOps identificou três vulnerabilidades em Windows 11 e Microsoft Entra ID e mais de 20 técnicas. O Windows registava assertions WebAuthn completas em Microsoft-Windows-WebAuthN/Operational, incluindo Credential ID, challenge, dados do autenticador e assinatura. Entra ID aceitava-as novamente numa janela limitada.

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

CVE-2026-34348 identifica a parte Windows. Em 14 de julho de 2026, a Microsoft reduziu a assinatura registada a poucos bytes e eliminou a fonte do replay. Também verificou contadores para certas security keys FIDO2, mas credenciais de plataforma ou sincronizadas podem devolver zero ou partilhar estado.

Assertions não pertencem aos logs. Challenges devem ser aleatórios, breves, únicos e ligados à sessão. Outra técnica envolve o Parent-Window-Handle da API Windows: um processo local pode fazer um diálogo real de passkey parecer pertencer ao browser ou cliente de email. Pedidos inesperados devem ser tratados como push MFA inesperados.

O fallback mais fraco define a segurança real

Em 2025, a Proofpoint demonstrou um downgrade FIDO contra Entra ID. Um fluxo Evilginx modificado fingia ser um browser sem FIDO. A plataforma oferecia SMS, OTP ou outro método sujeito a phishing, permitindo roubar credenciais e sessão no fluxo Adversary-in-the-Middle.

Origin Binding não é contornado: WebAuthn nem começa. É necessário um método mais fraco ainda permitido e não há exploração real documentada. Uma política só resiste ao phishing quando login, recuperação e helpdesk não permitem caminhos vulneráveis para esse nível.

O browser pertence ao modelo de segurança

Com Passkeys Pwned, a SquareX mostrou que extensão maliciosa ou script no browser pode influenciar navigator.credentials.create() e navigator.credentials.get(). No registo, o utilizador pode ver biometria genuína enquanto uma credencial do atacante é vinculada.

Não é um exploit universal: extensão ou script já precisam de intervir no percurso WebAuthn. Mas extensões, Content Scripts e proxies WebAuthn fazem parte da Trusted Computing Base. Allowlists e controlo de APIs privilegiadas também protegem identidade.

Passkeys protegem o login, não automaticamente a sessão

Após autenticação, o serviço usa cookie ou token. Se um infostealer o roubar e o servidor o aceitar noutro dispositivo, não precisa de palavra-passe nem passkey. É hoje mais prático do que muitos Proofs of Concept.

São necessários armazenamento seguro, duração baseada no risco, reautenticação, revogação e, se possível, ligação criptográfica ao dispositivo. Dizer que «MFA foi contornada» é impreciso: MFA funcionou e o resultado foi roubado depois.

PoisonSeed mostra como investigação se torna hype

Em julho de 2025, a Expel anunciou que um QR code legítimo retransmitido por phishing podia sequestrar Cross-Device Authentication. Dias depois retirou a alegação e pediu desculpa.

A verificação de proximidade não fora ultrapassada: sem proximidade, o fluxo expirava, todos os desafios MFA falhavam e não havia acesso. Comunicação rigorosa distingue account takeover observado, Proof of Concept reproduzível, ataque teórico e hipótese refutada.

A minha avaliação de segurança

O âmbito limita-se ao Google Password Manager no Chrome sobre Windows com TPM. A probabilidade é média a baixa porque malware já tem de executar e manipular estados ou memória. O impacto pode ser alto a muito alto: tomada de conta, acesso remoto persistente ou extração de várias chaves. O risco para o protocolo permanece baixo.

Para utilizadores comuns, uma passkey sincronizada continua geralmente mais segura do que palavra-passe com SMS ou TOTP, eliminando muitos caminhos de phishing, Credential Stuffing e roubo de palavras-passe. Para administradores, aprovações financeiras, produção ou sistemas regulados, uma chave de plataforma vinculada ao dispositivo ou security key FIDO2 separada pode ser mais adequada. É segurança graduada, não rejeição da sincronização.

O que os serviços web devem verificar

Os servidores devem:

• definir userVerification: "required" quando necessário e verificar UV em authenticatorData,
• validar challenge, Origin, Relying Party ID e assinatura,
• tornar cada challenge aleatório, breve, de uso único e ligado à sessão,
• excluir de logs assertions, assinaturas e artefactos reutilizáveis,
• registar criação e remoção de passkeys e account recovery como alto risco,
• exigir reautenticação forte antes de novos autenticadores privilegiados,
• recolher, quando possível, origem e propriedades do autenticador,
• considerar attestation e autenticadores geridos em alta segurança,
• detetar mudanças de dispositivo, geografia e novas associações,
• revogar sessões após alterações arriscadas e reautenticar ações críticas,
• usar sessões vinculadas ao dispositivo quando houver suporte fiável.

Uma biblioteca WebAuthn consolidada reduz erros, mas a configuração continua a exigir revisão. eBay mostra o efeito de um flag ignorado; Pass-the-Passkey, o de uma ligação incorreta entre challenge e sessão.

O que as empresas devem mudar nos rollouts

Um projeto de passkeys é simultaneamente IAM, endpoint, browser e recuperação. Contas comuns podem usar sincronização em dispositivos geridos com proteção endpoint e Conditional Access. Contas sensíveis exigem autenticadores geridos ou sincronização restrita. Admin, Break Glass e outras contas de alto valor devem usar security keys FIDO2 separadas, recuperação rigidamente controlada e nenhuma sincronização cloud não gerida.

As empresas devem ainda atualizar Chrome e Windows, verificar CVE-2026-34348, controlar armazenamento por Enterprise Policies, aplicar allowlists de extensões, monitorizar proxies WebAuthn, estender EDR e Application Control aos processos de utilizador, detetar acessos a bases sync e dumps de Chrome, investigar passkey_enclave_state, tratar pedidos PIN inesperados como alertas, testar perda e recuperação, remover fallbacks sujeitos a phishing, investigar prompts e novos credentials e inventariar passkeys sincronizadas ou vinculadas.

Se o autenticador vive no browser e no cliente, Endpoint Detection faz parte do modelo de autenticação.

O que os utilizadores devem fazer agora

Não há motivo para apagar preventivamente passkeys. É sensato atualizar Chrome e Windows, instalar apenas software e extensões confiáveis, manter Windows Hello e antimalware, rejeitar pedidos inesperados, rever dispositivos e passkeys, considerar uma security key para contas valiosas e isolar endpoints suspeitos.

Perante malware, estados Chrome manipulados ou dump de memória, mudar a palavra-passe não basta. É preciso reconstruir ou limpar o endpoint, revogar sessões, rever recuperação, remover passkeys desconhecidas e registar autenticadores confiáveis novamente.

Num possível incidente Golden, não está documentada uma rotação SDS simples para o utilizador. Não se deve prometer que mudar PIN ou uma passkey resolve tudo. Após limpeza, eu registaria novas credenciais vinculadas, removeria as sincronizadas antigas e envolveria provider ou equipa de Incident Response.

A verdadeira lição

Passkeys não protegem contra todo o comprometimento. Resolvem um problema enorme: pessoas deixam de entregar um segredo reutilizável a um servidor ou site falso. A sincronização acrescenta cifragem, confiança do dispositivo e recuperação, onde podem existir falhas mesmo com WebAuthn correto.

Declarar as passkeys fracassadas seria errado, tal como banalizar ataques após infeção local. Devemos continuar o rollout com promessas precisas: sincronizadas, são excelentes contra phishing; vinculadas a hardware, dão uma fronteira mais forte a contas valiosas; nenhuma substitui endpoint limpo, recuperação controlada e validação correta no servidor.

As passkeys fecharam muito melhor a porta ao phishing. Pass-ta-key lembra que um atacante já dentro de casa exige outra defesa.

Até à próxima,
Joe

FAQ