Hackers roubaram tokens de acesso da unidade de suporte da Okta
(krebsonsecurity.com)- Uma violação no sistema de suporte ao cliente da Okta expôs arquivos enviados por alguns clientes em chamados de suporte, e os invasores parecem ter acessado a plataforma de suporte por pelo menos duas semanas antes de serem bloqueados
- Usando credenciais roubadas, os invasores entraram no sistema de gerenciamento de chamados de suporte e conseguiram visualizar arquivos HAR enviados por clientes para solução de problemas
- Arquivos HAR podem conter cookies e tokens de sessão; se forem roubados, há o risco de que o invasor reutilize a sessão como se fosse um usuário legítimo
- A BeyondTrust detectou, em 2 de outubro, uma tentativa de criação de conta de administrador em seu ambiente Okta; 30 minutos antes, havia compartilhado com a Okta um arquivo HAR contendo um token de sessão Okta válido
- A Okta notificou cerca de 170 clientes, aproximadamente 1% de sua base de mais de 18.000 clientes; 1Password e Cloudflare também divulgaram comprometimento de suas plataformas de autenticação Okta, mas afirmaram que não houve impacto em informações de clientes ou sistemas
Arquivos de clientes expostos no sistema de gerenciamento de chamados de suporte
- A Okta fornece ferramentas de identidade, incluindo autenticação multifator e login único, para milhares de empresas, e este incidente começou com a violação da unidade de suporte ao cliente
- Em um aviso enviado a alguns clientes em 19 de outubro, a empresa informou que credenciais roubadas foram usadas para acessar o sistema de gerenciamento de chamados de suporte
- Os invasores conseguiram ver arquivos enviados por alguns clientes da Okta em chamados de suporte recentes
- O escopo do impacto foi inicialmente descrito como “um número muito pequeno” e, posteriormente, confirmou-se que cerca de 170 clientes, aproximadamente 1% da base de clientes, foram notificados
Por que os arquivos HAR se tornaram perigosos
- Ao resolver problemas de clientes, a Okta às vezes solicita arquivos HTTP Archive (HAR), que registram sessões do navegador web
- Arquivos HAR são sensíveis porque podem conter cookies e tokens de sessão do cliente
- Um invasor pode usar cookies ou tokens dentro do arquivo para se passar por um usuário válido
- A Okta trabalhou com os clientes afetados na investigação e adotou medidas de proteção, incluindo a revogação de tokens de sessão incorporados
- Antes de compartilhar arquivos HAR, todas as credenciais, cookies e tokens de sessão devem ser removidos
O fluxo de ataque detectado pela BeyondTrust
- A empresa de segurança BeyondTrust foi uma das clientes que receberam a notificação da Okta em 19 de outubro
- O CTO da BeyondTrust, Marc Maiffret, disse que a notificação chegou mais de duas semanas depois de a BeyondTrust ter alertado a Okta sobre um possível problema
- Em 2 de outubro, a equipe de segurança da BeyondTrust detectou uma tentativa de alguém criar uma conta de administrador com privilégios elevados dentro de seu ambiente Okta usando uma conta Okta atribuída a um de seus engenheiros
- Ao analisar a atividade da conta desse funcionário, constatou-se que, 30 minutos antes da atividade não autorizada, um engenheiro de suporte havia compartilhado com a Okta, a pedido dela, um arquivo HAR contendo um token de sessão Okta válido
- O invasor tentou usar cookies no histórico do navegador para realizar sequestro de sessão e agir em nome desse usuário
- A BeyondTrust informou a Okta em 3 de outubro que era altamente provável que a empresa tivesse sofrido uma violação, e reiterou essa avaliação em chamadas nos dias 11 e 13 de outubro
- A BeyondTrust afirmou que detectou o ataque enquanto ele estava em andamento e que seus clientes não foram afetados
A resposta da Okta e perguntas em aberto
- A Deputy CISO da Okta, Charlotte Wylie, disse que, inicialmente, a notificação da BeyondTrust em 2 de outubro não foi interpretada como resultado de uma violação de seus próprios sistemas
- Até 17 de outubro, a Okta havia identificado e bloqueado o incidente, desativado a conta comprometida de gerenciamento de chamados de clientes e invalidado os tokens de acesso Okta relacionados
- Wylie não revelou o número exato de clientes que receberam notificações sobre o possível problema de segurança, mas o descreveu como uma “parte muito, muito pequena” dos mais de 18.000 clientes
- Não foi divulgado por quanto tempo o invasor teve acesso à conta de gerenciamento de chamados da empresa nem quem estava por trás do ataque
- Wylie afirmou que o invasor era um ator de ameaça conhecido que já havia mirado a Okta e clientes específicos da Okta
Violações relacionadas e divulgações posteriores
- A divulgação da Okta veio poucas semanas após os ataques à Caesar’s Entertainment e à MGM Resorts
- Nos casos das duas empresas de cassino, os invasores usaram engenharia social contra funcionários para fazê-los redefinir os requisitos de login com autenticação multifator de contas de administrador da Okta
- Em março de 2022, a Okta divulgou uma violação relacionada ao grupo hacker LAPSUS$, especializado em ataques de engenharia social
- Segundo o relatório pós-incidente da Okta, o LAPSUS$ obteve acesso por engenharia social à estação de trabalho de um engenheiro de suporte da Sitel, empresa terceirizada de outsourcing que tinha permissão de acesso a recursos da Okta
- Depois disso, a Okta publicou um post no blog sobre o incidente e incluiu indicadores de comprometimento que permitem aos clientes verificar se foram afetados
- A empresa afirmou que notificou todos os clientes afetados
- Também enfatizou que ambientes ou tickets de suporte de clientes da Okta que não receberam contato separado não foram impactados
- A BeyondTrust também divulgou os resultados de sua própria investigação
- Em uma atualização de 24 de outubro, 1Password e Cloudflare divulgaram que suas plataformas de autenticação Okta foram comprometidas como resultado da violação da Okta
- Ambas as empresas afirmaram que, segundo suas investigações, informações de clientes e sistemas não foram afetados
- Um porta-voz da Okta disse ao TechCrunch que a empresa notificou cerca de 1% de sua base de clientes, aproximadamente 170 clientes
1 comentários
Opiniões do Hacker News
A parte engraçada deste artigo é que a Okta foi avisada por um terceiro sobre atividade suspeita em um tenant e, a princípio, não encontrou evidências de invasão; só depois que a BeyondTrust continuou insistindo é que investigou novamente e confirmou a invasão.
A Okta publicou este post no blog: https://sec.okta.com/harfiles
A frase de abertura é “Okta Security has identified adversarial activity”, mas não há menção ao aviso de um terceiro. Bela transparência
O título é horrível, e não é transparente nem direto. É realmente péssimo a Okta nem sequer mencionar o fato de que a BeyondTrust os avisou em 2 de outubro, 30 minutos depois de enviar um arquivo HAR ao Okta Support
“A vice-CISO da Okta, Charlotte Wylie, disse que a Okta inicialmente considerou que o alerta da BeyondTrust de 2 de outubro não era resultado de uma invasão de seus sistemas. Mas disse que, até 17 de outubro, a empresa havia identificado e bloqueado o incidente”
Ou seja, uma empresa que se diz especialista em cibersegurança e autenticação foi avisada de um hack em até 30 minutos, disse que a outra estava errada e, por 15 dias, não admitiu, enquanto o invasor ficou à solta
Wylie, precisa fazer melhor
Vale ler este post do blog linkado no artigo original. Uma empresa de segurança que era cliente da Okta detectou atividade suspeita em sua própria rede logo depois de compartilhar um arquivo HAR com a Okta e avisou a Okta sobre a invasão
https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...
Imagino que seja uma forma complicada de dizer que o IP mudou depois do login. Claro, a solução mais fácil é não compartilhar voluntariamente arquivos HAR de sessões ativas
Sei que isso não vai ser popular, mas fico pensando se o gateway central de SSO feito com OAuth, SAML e 2FA não deveria rodar on-premises, em vez de apertar o “botão fácil” do SaaS
Isso inclui não só a Okta, mas também Auth0 (adquirida pela Okta), Authy e Duo
Todo software tem bugs de segurança, e software on-premises não é exceção. Muitas organizações de TI não têm expertise para operar e proteger diretórios. Não é só instalar um software, criar algumas contas e deixar em um canto; é uma tarefa muito difícil que envolve recuperação de desastres, testes de backup e até determinar se houve comprometimento
Ninguém provou que a segurança de TI on-premises é melhor do que a segurança de provedores de nuvem. Entre departamentos de TI on-premises que vi pessoalmente, alguns tinham segurança péssima: lugares que, mesmo entre 2010 e 2020, operavam VPNs com certificados MD5; que implantaram serviços web em que usuários não autenticados conseguiam acessar dados pessoais como CPF/número fiscal, endereço, nome e telefone; que deram a enfermeiras um editor de texto com anúncios para escrever anotações de pacientes; que não atualizavam uma versão sem suporte do Redcap com bugs de segurança conhecidos; e assim por diante
Pelo que sei, o Redcap é um software que armazena informações usadas em pesquisa médica e no cálculo de estatísticas de saúde pública, e contém muitos dados sensíveis
O ponto principal é que mover da nuvem para on-premises pode ou não melhorar a segurança. Depende da capacidade de cada organização de TI, e muitas organizações não têm capacidade para operar serviços de identidade como a Okta. Além disso, provedores de nuvem geralmente têm orçamentos muito maiores e conseguem distribuir custos entre muitos clientes, podendo investir mais em especialistas de segurança, proteção de sistemas e detecção de invasões
Ninguém faz pergunta nenhuma a esses gerentes e executivos
Dá para escrever e testar software em sistemas que, de fato, nunca são conectados. Surpreendente, mas é verdade
Provedores de identidade, gerenciadores de senhas, empresas de VPN e afins nunca deveriam ser hackeados. São empresas que ganham dinheiro com produtos de segurança, e eu não usaria uma que foi comprometida. É bem provável que haja problemas mais profundos
A premissa básica é que tudo pode ser comprometido, e o ônus de provar que não serão comprometidos é deles. Em vez de conceder o benefício da dúvida a quem demonstrou incompetência repetidamente, parece mais prudente esperar por evidências positivas que sustentem a alegação extraordinária de que não serão hackeados
Se forem competentes e responsáveis o bastante, vão detectar e divulgar, mas acho que a maioria não fará isso. Porque pessoas como você parariam de usá-los. Por isso, qualquer pessoa minimamente preocupada deveria usar alternativas offline, auto-hospedadas e feitas por conta própria
Desafio da Okta de ficar um mês sem ser hackeada: dificuldade impossível
Brincadeiras à parte, parece que a Okta gosta de ser invadida. Seria de esperar que algo mudasse se incidentes assim continuassem derrubando o preço das ações, mas aparentemente não
O diabo está nos detalhes. Provavelmente estavam operando com zero trust
Por um lado, não foi um comprometimento do produto principal. Por outro, todo comprometimento de produto principal vem acompanhado de um comprometimento indireto de algo não essencial
Ainda bem que permitiram que ela adquirisse a concorrente Auth0
Um dia, em uma palestra de conferência, vou fazer um experimento pagando pessoas para entrarem em funções de suporte em várias empresas e, então, comprometê-las usando os acessos aos sistemas que lhes forem concedidos
No rodapé do e-mail estava escrito:
“Estas informações são confidenciais da Okta e não devem ser compartilhadas fora da sua organização”
Sinceramente, é bem engraçado