Okta: um perfil pessoal do Chrome num portátil de trabalho expôs 134 clientes, incluindo a 1Password e a Cloudflare
Um funcionário da Okta guardou credenciais de uma conta de serviço no Google pessoal. Quando essa conta caiu, os atacantes leram ficheiros de suporte com tokens de sessão ativos, e sequestraram sessões de administrador que já tinham passado pelo MFA.
São Francisco, Entre 28 de setembro e 17 de outubro de 2023, um atacante teve acesso não autorizado ao sistema de suporte a clientes da Okta, a empresa que gere a identidade e o single sign-on de milhares de organizações. Foram acedidos ficheiros associados a 134 clientes, e as sessões Okta legítimas de cinco deles foram sequestradas. Três tornaram o caso público: 1Password, BeyondTrust e Cloudflare.
O ponto de partida, revelado na análise de causa raiz da própria Okta, é desconcertantemente familiar: um funcionário iniciou sessão no seu perfil Google pessoal no Chrome do portátil de trabalho, e as credenciais de uma conta de serviço da Okta ficaram guardadas nessa conta pessoal. Quando a conta Google pessoal foi comprometida, o atacante herdou as credenciais da conta de serviço.
O tesouro escondido nos ficheiros de suporte
A conta de serviço dava acesso ao sistema de gestão de casos de suporte. E é aqui que o caso ganha relevância para qualquer equipa: quando os clientes pediam ajuda, a Okta pedia-lhes o upload de ficheiros HAR, gravações do tráfego do browser, usadas para diagnosticar problemas. O que muita gente não sabe é que os ficheiros HAR capturam cookies de sessão e cabeçalhos de autenticação em texto simples.
O atacante vasculhou esses ficheiros, extraiu tokens de sessão ainda válidos e usou-os para sequestrar sessões de administrador Okta nos clientes afetados. O detalhe crucial: um token de sessão representa uma autenticação já concluída. A password foi introduzida, o MFA foi cumprido, tudo pelo utilizador legítimo. O atacante limitou-se a continuar a sessão dele. Nenhum código foi pedido, nenhum alerta de login disparou.
Falhas de logging fizeram com que o acesso passasse despercebido durante 14 dias, apesar de a BeyondTrust ter detetado atividade suspeita logo a 2 de outubro e escalado o caso junto da Okta repetidamente. Após o incidente, a Okta desativou a conta de serviço, bloqueou perfis Google pessoais no Chrome dos portáteis geridos e passou a revalidar sessões de administrador quando a rede muda.
As lições: sessões são segredos, e o pessoal contamina o profissional
Este caso condensa três verdades incómodas para equipas de qualquer tamanho:
- A fronteira pessoal/profissional cai sozinha se não for imposta por arquitetura. Tal como no caso Cisco (credenciais no browser) e no caso Retool (seeds no Google Authenticator), aqui foi um perfil de Chrome. Ninguém violou uma política por maldade, a conveniência fez o resto. Se as credenciais e códigos da tua equipa podem parar a contas pessoais, vão parar.
- Tokens e sessões valem tanto como códigos 2FA. Um MFA impecável no login não protege nada se a sessão resultante puder ser copiada de um ficheiro, de um cookie ou de um portátil desbloqueado. Sessões curtas, revalidação em mudanças de contexto e revogação no offboarding são parte do mesmo pacote que o 2FA.
- Cuidado com o que partilhas «para debug». Ficheiros HAR, screenshots de consolas, exports de logs, tudo isto pode conter material de autenticação vivo. Antes de anexar seja o que for a um ticket de suporte, a regra é limpar tokens e cookies.
A ironia de o incidente ter atingido a 1Password e a Cloudflare, duas referências em segurança, através do fornecedor de identidade delas é o lembrete final: a tua segurança nunca é melhor do que a higiene de credenciais do elo mais conveniente da cadeia.
Partilhe 2FA na equipa sem repetir estes erros.
Códigos por SMS (número SIM real) e de apps (TOTP) num só painel, com acesso por serviço, expiração e auditoria.
Reservar o meu lugar