Okta admite incidente, Lapsus$ contesta explicação

Empresa anunciou para hoje um webinar no qual o CSO David Bradbury relatará as providências já tomadas e em andamento para proteger os clientes
Da Redação
23/03/2022

Num post em seu canal do Telegram na tarde de ontem, o grupo Lapsus$ contestou vários pontos do comunicado da Okta feito horas antes para explicar e dimensionar o incidente causado pelo grupo, ao revelar ter obtido acesso a um ambiente da empresa. Assinado pelo CSO David Bradbury, o comunicado da Okta informa que a empresa está conduzindo uma investigação sobre as alegações do grupo e possíveis impactos aos clientes, acrescentando que “não há ações corretivas que nossos clientes precisem tomar”. Mas admite que “uma pequena porcentagem de clientes – aproximadamente 2,5% – foi potencialmente impactada e cujos dados podem ter sido visualizados”. O CSO anunciou para hoje um webinar no qual relatará suas providências. A publicação de Bradbury, a segunda sobre o assunto, está em “hxxps://www.okta.com/blog/2022/03/updated-okta-statement-on-lapsus”

Veja isso
US$ 6,5 bilhões é o preço pago pela Okta na compra da Auth0
Lapsus$ vaza material atribuído a Microsoft, Okta e LG

Os resultados da investigação do incidente, segundo a Okta, mostraram que os invasores tiveram acesso ao laptop de um engenheiro entre 16 e 21 de janeiro de 2022, período em que puderam acessar o painel de suporte ao cliente Okta e o servidor Slack da empresa. Capturas de tela postadas pelo Lapsus$ mostram o endereço de e-mail de um funcionário da Okta que aparentemente tinha privilégios de “superusuário” para listar usuários, redefinir senhas, redefinir MFA e acessar tickets de suporte.

Entre as telas existe também uma da Cloudflare, utilizando e-mail de um funcionário da empresa cuja senha estava prestes a ser redefinida pelos hackers. A conta de e-mail foi suspensa aproximadamente 90 minutos depois que a equipe de Resposta a Incidentes de Segurança (SIRT) foi notificada sobre um possível problema, informou o CEO da Cloudflare no Twitter.

A Cloudflare observou que os serviços da Okta são usados ​​internamente para identificar funcionários, integrados à pilha de autenticação, e seus clientes não precisam se preocupar “a menos que eles próprios usem a Okta”. Para eliminar qualquer possibilidade de acesso não autorizado às contas de seus funcionários, a Cloudflare revisou todas as redefinições de senha ou alterações de MFA desde 1º de dezembro de 2021.

Em resposta às declarações de Okta, o grupo Lapsus$ compartilhou sua parte da história. De acordo com os criminosos, eles comprometeram não o laptop de um funcionário da Okta, mas seu ‘thin client’ (um sistema de baixo desempenho que se conecta remotamente a um ambiente virtual para realizar tarefas). Os hackers contestam a afirmação de Okta de que o hack não teve sucesso. Segundo eles, eles “se conectaram ao portal do superusuário com a capacidade de redefinir a senha e MFA de aproximadamente 95% dos clientes”.

Esta é a tradução do post do grupo:

Eu gosto das mentiras da Okta.

Não comprometemos nenhum laptop? Era um thin client. “A Okta detectou uma tentativa malsucedida de comprometer a conta de um engenheiro de suporte ao cliente que trabalha para um provedor terceirizado.” –
AINDA não tenho certeza como é uma tentativa mal sucedida? Conectado ao portal do superusuário com a capacidade de redefinir a senha e o MFA de ~ 95% dos clientes não é bem-sucedido?

Para uma empresa que suporta Zero-Trust. Engenheiros de suporte parecem ter acesso excessivo ao Slack? 8,6 mil canais? (Você pode pesquisar AKIA* no seu Slack, uma prática de segurança ruim para armazenar chaves da AWS em canais do Slack 😉)

Os engenheiros de suporte também podem facilitar a redefinição de senhas e fatores de MFA para usuários, mas não conseguem obter essas senhas. –
Uhm? Espero que ninguém possa ler senhas? não apenas engenheiros de suporte, LOL. – você está sugerindo que as senhas são armazenadas em texto simples?

Você alega que um laptop foi comprometido? Nesse caso, quais endereços IP suspeitos você tem disponíveis para denunciar?

O impacto potencial para os clientes do Okta NÃO é limitado, tenho certeza de que a redefinição de senhas e MFA resultaria no comprometimento completo de muitos sistemas de clientes.

Se você está comprometido com a transparência, que tal contratar uma empresa como a Mandiant e PUBLICAR seu relatório? Tenho certeza que seria bem diferente do seu relato 🙂

21. Gerenciamento de violação de segurança. a) Notificação: No caso de uma Violação de Segurança, a Okta notifica os clientes impactados sobre tal Violação de Segurança. Okta coopera com a solicitação razoável de um cliente afetado por informações sobre tal violação de segurança, e a Okta fornece atualizações regulares sobre qualquer violação de segurança e as ações investigativas e ações corretivas tomadas.

Mas os clientes só descobriram hoje? Por que esperar tanto?

Controles de acesso. A Okta possui políticas, procedimentos e controles lógicos que são projetados:

b. Controles para garantir que todo o pessoal da Okta que tenha acesso a quaisquer Dados do Cliente seja baseado em princípios de privilégios mínimos;

kkkkkkkkkkkkkk

Padrões de Segurança. O ISMP da Okta inclui aderência e testes regulares dos principais controles, sistemas e procedimentos de
seu ISMP para validar se eles estão implementados adequadamente e são eficazes no tratamento das ameaças e riscos identificados. Tal
teste inclui:
a) Avaliações internas de risco;
b) certificações ISO 27001, 27002, 27017 e 27018;
c) orientação do NIST; e
d) Auditorias SOC2 Tipo II (ou padrão sucessor) realizadas anualmente por auditores terceirizados credenciados (“Auditoria
Relatório”).

Acho que o armazenamento de chaves da AWS no Slack não atenderia a nenhum desses padrões?

Compartilhar:

Últimas Notícias