“Nosso foco era apenas em clientes da Okta”, diz Lapsus$ ao publicar capturas de tela de suposta invasão

Na manhã desta terça-feira (22), capturas de tela supostamente atribuídas ao sistema interno da Okta, fornecedora de serviços de autenticação corporativa, foram publicadas no canal do grupo Lapsus$, responsável por invasões confirmadas de gigantes da tecnologia nas últimas semanas.

Imagem: Tecmasters

Na mensagem, eles afirmam ter adquirido acesso “superuser/Admin” do Okta.com, além de outros sistemas, o que daria acesso ao dados de clientes da empresa-alvo. Ao fim da mensagem, o grupo alegou não ter acessado ou roubado a base de dados: “nosso foco estava apenas nos clientes da Okta”, escreveu.

A empresa de capital aberto avaliada em US$ 6 bilhões emprega mais de 5 mil pessoas e fornece serviços de software para grandes companhias como Siemens, ITV, Pret a Manger, Starling Bank, entre outras companhias e também universidades e agências governamentais em todo o mundo. A Okta disse estar investigando o caso.

Ao avaliarem as screenshots divulgadas pelo grupo, especialistas de segurança cibernética ouvidos pela Reuters disseram que “definitivamente acreditam que é confiável”.

Chris Hollis, oficial da Okta, comentou em uma declaração que as capturas de tela compartilhadas estão conectadas a “este” evento de janeiro. “Com base em nossa investigação até o momento, não há evidências de atividade maliciosa contínua além da atividade detectada em janeiro”, afirmou. A declaração foi confirmada por Todd McKinnon, CEO e cofundador da Okta, no Twitter.

In late January 2022, Okta detected an attempt to compromise the account of a third party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor. (1 of 2)

— Todd McKinnon (@toddmckinnon) March 22, 2022

Eles se referem à data do sistema visível em algumas screenshots, definida em 21 de janeiro de 2022. Isso pode indicar que a invasão pode ter ocorrido meses atrás e só agora veio a público.

Imagem: Lapsus$

Fornecedora nega violação e Lapsus$ ironiza: “me divirto realmente com as mentiras apresentadas pela Okta”

Após anunciar a conclusão das investigações sobre o caso de violação reivindicado pelo grupo Lapsus$, a Okta afirmou que o seu serviço não foi violado e permanece totalmente em operação. “Não há medidas corretivas que precisem ser tomadas por nossos clientes”, escreveu David Bradbury, CSO da empresa, em um post no blog.

“O relatório destacou que houve um período de cinco dias entre 16 e 21 de janeiro de 2022, no qual um atacante teve acesso ao laptop de um engenheiro de suporte. Isto é consistente com as capturas de tela de que tomamos conhecimento ontem. O impacto potencial para os clientes da Okta está limitado ao acesso que os engenheiros de suporte têm. Estes engenheiros não podem criar ou excluir usuários, ou fazer download de bancos de dados de clientes. Os engenheiros de suporte têm acesso a dados limitados – por exemplo, ingressos Jira e listas de usuários – que foram vistos nas capturas de tela. Os engenheiros de suporte também são capazes de facilitar a redefinição de senhas e fatores AMF para os usuários, mas não conseguem obter essas senhas”, explicou Bradbury.

Imagem: Tecmasters

Ao tomar conhecimento da declaração, o grupo rebateu com várias questões e ironizou dizendo que “aprecia as mentiras apresentadas pela Okta”. Abaixo, a mensagem traduzida na íntegra.

1. Não comprometemos nenhum laptop? Foi um cliente pequeno [sistema de baixo desempenho que se conecta remotamente a um ambiente virtual para realizar tarefas]
2. “A Okta detectou uma tentativa fracassada de comprometer a conta de um engenheiro de suporte ao cliente que trabalhava para um fornecedor terceirizado”. – Eu AINDA estou incerto sobre uma tentativa fracassada? Logado no portal do super usuário com a capacidade de redefinir a Senha e o MFA de ~95% dos clientes não é bem sucedido?
3. Para uma empresa que apoia a Zero-Trust. Os engenheiros de suporte parecem ter acesso excessivo ao Slack? 8,6k de canais?
4. Os engenheiros de suporte também são capazes de facilitar a redefinição de senhas e fatores AMF aos usuários, mas não conseguem obter essas senhas. – Uhm? Espero que ninguém consiga ler senhas? não apenas engenheiros de suporte, LOL. – vocês estão insinuando que as senhas são armazenadas em texto claro?
5. Vocês alegam que um laptop foi comprometido? Nesse caso, *que endereço IP suspeito* vocês têm disponível para relatar?
6. O impacto potencial para os clientes da Okta NÃO é limitado, tenho certeza de que redefinir senhas e o MFA resultariam em total comprometimento de muitos sistemas de cliente
7. Se vocês estão comprometidos com a transparência, que tal contratarem uma empresa como a Mandiant e PUBLICAREM o relatório? Tenho certeza de que seria muito diferente do relatório de vocês 🙂

21. Gerenciamento da quebra de segurança. a) Notificação: No caso de uma quebra de segurança, a Okta notifica os clientes afetados por tal quebra de segurança. Okta coopera com um pedido razoável do cliente impactado de informações relativas a tal quebra de segurança, e a Okta fornece atualizações regulares sobre qualquer quebra de segurança e as medidas investigativas e corretivas tomadas.

Mas os clientes só souberam hoje? Por que esperar tanto tempo?

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

b. Controles para garantir que todo o pessoal da Okta a quem é concedido acesso a quaisquer dados de clientes se baseiem nos princípios de privilégios mínimos;

kkkkkkkkkkkkkkkk

1. Normas de Segurança. O ISMP da Okta inclui aderência e testes regulares dos principais controles, sistemas e procedimentos de seu ISMP para validar que eles são devidamente implementados e eficazes para enfrentar as ameaças e riscos identificados. Tais testes incluem: a) Avaliações internas de risco; b) Certificações ISO 27001, 27002, 27017 e 27018; c) orientação NIST; e d) Auditorias SOC2 Tipo II (ou padrão sucessor) realizadas anualmente por auditores terceirizados credenciados (“Auditoria de Relatório”).

Não acho que o armazenamento de chaves AWS no Slack estaria de acordo com alguma dessas normas?