Malware abusa do endpoint OAuth do Google para 'reviver' cookies e sequestrar contas
Autores de malware estariam explorando um recurso não documentado do Google OAuth para “reviver” cookies de autenticação expirados, permitindo o sequestro persistente de contas mesmo após o usuário mudar a senha. Os comentaristas argumentam que isso expõe um problema mais profundo na forma como o Google gerencia sessões de longa duração e a revogação de tokens, criando uma lacuna entre a expectativa do usuário (“mudar a senha para expulsar o invasor”) e o comportamento real de segurança. A discussão também destaca uma inquietação mais ampla sobre a dependência excessiva de contas Google — para Gmail, Workspace e serviços em nuvem — diante de processos de recuperação difíceis, bloqueios de conta e controle limitado do usuário sobre a duração das sessões.
Problema central: sessões “zumbis” do Google via OAuth
- Malware pode, supostamente, usar um endpoint OAuth2 não documentado do Google / comportamento de extensão do Chrome para “reviver” cookies de autenticação do Google expirados e sequestrar contas.
- Principal preocupação: cookies de sessão permanecem válidos mesmo após mudanças de senha, enfraquecendo o conselho usual de “mude sua senha” após uma violação.
- Alguns observam que o atacante ainda precisa roubar cookies locais (por exemplo, via malware no Chrome/Windows; potencialmente também em Mac/Android).
Mudança de senha, invalidação de sessão e “teatro de segurança”
- Vários comentaristas argumentam que é uma falha de segurança fundamental se a rotação de senha não invalida sessões, comparando isso ao reuso de certificados TLS/chaves privadas não revogados.
- Outros respondem que, em sistemas complexos de SSO/OAuth, encerrar todas as sessões é difícil; revogar tokens bearer em muitos serviços é um problema de “consistência eventual” / em malha aberta.
- Melhor prática sugerida: no mínimo, perguntar ao usuário durante a troca de senha se deseja desconectar todos os outros dispositivos.
Sessões sem expiração: conveniência vs risco
- Alguns usuários preferem sessões de longa duração ou sem expiração e consideram os armazenamentos de cookies do navegador suficientemente protegidos; argumentam que, se os cookies forem roubados, a duração importa pouco.
- Outros contra-argumentam que:
- Sessões do lado do servidor não devem sobreviver aos cookies do cliente.
- Mudanças de senha, logouts e desativação de conta devem encerrar de forma confiável as sessões antigas.
- Sessões de longa duração são especialmente perigosas para alvos de alto valor (bancos, consoles de nuvem, ex-funcionários).
Bloqueios de conta Google, recuperação e confiança
- Várias anedotas descrevem dificuldade para recuperar o acesso mesmo sabendo a senha, tendo e-mail/telefone de recuperação, códigos ou sessões ativas; os processos são descritos como opacos e mutáveis.
- Alguns dizem que códigos de backup e o Advanced Protection / contas pagas do Workspace funcionam de forma mais confiável; outros relatam que até contas pagas podem esbarrar em barreiras de “não podemos verificar que é você”.
- Usuários descrevem estratégias: manter dispositivos antigos conectados, imprimir códigos de backup, usar seus próprios domínios, diversificar provedores ou sair do Google por completo.
Controles e opções
- Há divergência sobre o comportamento atual: alguns afirmam que mudar a senha do Google desconecta todos os logins; outros dizem que sessões antigas persistem a menos que sejam revogadas manualmente pelo portal de segurança.
- Administradores do Workspace podem impor políticas de duração de sessão; usuários comuns do Gmail, segundo relatos, não têm esse controle configurável.
Ceticismo e detalhes ausentes
- Alguns duvidam da gravidade da exploração devido à escassez de detalhes técnicos na reportagem inicial, enquanto outros apontam textos mais detalhados e relatos anteriores sobre sessões do Google que não expiram.
- Um comentarista sugere que o Google pode manter sessões intencionalmente para rastreamento; outros descartam isso como desnecessário e pedem evidências.