.
O 1Password está confirmando que foi atacado por criminosos cibernéticos depois que o Okta foi violado pela segunda vez em muitos anos, mas afirma que os detalhes de login dos clientes estão seguros.
A empresa disse que o ataque foi detectado inicialmente em 29 de setembro por um membro da equipe de TI do 1Password depois que eles receberam um e-mail indicando que haviam solicitado um relatório incluindo uma lista de todos os administradores do 1Password.
Sabendo que não haviam solicitado esse relatório, a equipe de resposta a incidentes da empresa foi rapidamente acionada. Eles encontraram um endereço IP suspeito e mais tarde perceberam que o invasor desconhecido acessou a instância Okta da empresa com privilégios de administrador.
A investigação não encontrou nenhuma evidência de exfiltração de dados ou acesso a quaisquer sistemas fora da Okta. Em vez disso, os invasores foram observados tentando “se manter discretos” e procurar informações que poderiam mais tarde levar a um ataque maior e mais sofisticado.
“Encerramos imediatamente a atividade, investigamos e não encontramos nenhum comprometimento dos dados do usuário ou de outros sistemas confidenciais, tanto voltados para funcionários quanto para usuários”, disse Pedro Canahuati, CTO da 1Password, em um comunicado. postagem no blog.
Antes de ser removido da rede, o invasor executou ações que incluíam:
- Tentativa de acesso ao painel de usuário do funcionário de TI do 1Password (Okta bloqueou isso)
- Atualizado um provedor de identidade (IDP) existente vinculado ao ambiente de produção do Google do 1Password para se passar pelos usuários da empresa
- Ativou aquele IDP
- Solicitou um relatório de todos os usuários administradores
Como o ataque 1Password se desenrolou
O ataque ao 1Password começou da mesma forma que outros nesta nova campanha, com o invasor acessando um arquivo HTTP Archive (HAR) carregado no portal de suporte ao cliente da Okta.
O upload de arquivos HAR para o portal de suporte ao cliente da Okta é uma prática comum quando o suporte da Okta está envolvido com um cliente.
Dentro deste arquivo HAR havia informações sobre o tráfego de e para os servidores do Okta a partir do navegador do membro da equipe de TI, mas também dentro dele havia outros dados, como o cookie de sessão.
Em algum momento depois que o 1Password contratou o suporte do Okta e antes que o agente de suporte interagisse com o arquivo HAR, um invasor conseguiu acessá-lo e usar a sessão para acessar o portal de administração do Okta, de acordo com a resposta ao incidente. relatório.
“Não se sabe como o ator obteve acesso a esta sessão, embora tenha sido confirmado que o arquivo HAR gerado continha as informações necessárias para um invasor sequestrar a sessão do usuário”, dizia o relatório.
“Isso foi confirmado pela TI criando um arquivo HAR e pela segurança usando o Burp Suite para forçar o navegador a usar os cookies de sessão capturados no arquivo HAR para reproduzir os eventos do incidente.”
Originalmente, houve alguma confusão sobre como isso foi realizado. As investigações iniciais se concentraram no lado da Okta, mas os registros revelaram que todas as ações dos invasores ocorreram antes que o agente de suporte da Okta acessasse o arquivo HAR, eliminando a possibilidade de haver um funcionário de suporte desonesto.
Então a atenção se voltou para o funcionário de TI do 1Password que carregou o arquivo HAR por meio de uma rede Wi-Fi pública em um hotel, mas esse caminho também se mostrou infrutífero.
“Com base em uma análise de como o arquivo foi criado e carregado, no uso de TLS e HSTS pela Okta e no uso anterior do mesmo navegador para acessar o Okta, acredita-se que não houve janela na qual esses dados pudessem ter sido expostos. rede Wi-Fi ou de outra forma sujeita a interceptação.”
Por fim, a máquina macOS do funcionário de TI foi verificada em busca de malware, mas não mostrou nenhum sinal de qualquer atividade desagradável, nem na máquina nem nas contas de usuário.
A principal suspeita continuou sendo malware até a semana passada, quando Okta divulgou os problemas que estava enfrentando com vários de seus clientes, incluindo 1Password. O invasor conseguiu comprometer os sistemas de suporte interno da Okta, e foi assim que eles conseguiram acessar o arquivo HAR do membro da equipe de TI do 1Password depois de enviá-lo ao suporte da Okta.
Depois de encerrar a intrusão, as credenciais do membro da equipe de TI foram alternadas e seu Yubikey foi a única maneira de completar as salvaguardas da MFA.
Uma série de alterações de configuração também foram feitas na instância Okta da empresa, incluindo o reforço de AMF regras, reduzindo o tempo de sessão do administrador e o número de contas de superadministrador, e negando logins de deslocados internos que não sejam da Okta.
Outro pesadelo de Okta
1Password se junta a BeyondTrust e Cloudflare na lista de clientes de alto perfil que mitigaram ataques causados por problemas de Okta.
A Cloudflare foi rápida em destacar que é a segunda vez que falhas de segurança na Okta levam a ataques à empresa de desempenho e segurança da web.
Em março de 2022 foi revelado que durante uma janela de cinco dias, um Atacante Lapsus$ tinha acesso remoto ao computador de um engenheiro de suporte da Okta, mas a Cloudflare não encontrou nenhuma evidência de comprometimento real de seu locatário da Okta.
Na época, de acordo com capturas de tela postadas pelos invasores, seu nível de acesso sugeria que eles tinham o poder de alterar as senhas dos usuários dos clientes, mas isso não teria impactado a Cloudflare, uma vez que usa uma combinação de senhas e chaves de hardware para MFA.
Semelhante ao caso 1Password, um token de sessão Cloudflare foi sequestrado após ser criado com suporte Okta. nuvemflare disse ele foi capaz de detectar e mitigar a intrusão de sua instância do Okta mais de 24 horas antes de o Okta notificá-lo.
Foi uma história semelhante no BeyondTrust: token de sessão roubado, detecção e remediação imediatas, aparentemente sabia disso antes de Okta.
“Levantamos nossas preocupações sobre uma violação à Okta em 2 de outubro”, BeyondTrust disse na sua divulgação.
“Não tendo recebido nenhum reconhecimento da Okta sobre uma possível violação, persistimos com os escalonamentos dentro da Okta até 19 de outubro, quando a liderança de segurança da Okta nos notificou que eles realmente haviam sofrido uma violação e que éramos um dos clientes afetados.
A Okta confirmou em sua divulgação de 20 de outubro que todos os clientes impactados pelo incidente foram notificados.
“A Okta trabalhou com os clientes afetados para investigar e tomou medidas para proteger nossos clientes, incluindo a revogação de tokens de sessão incorporados”, afirmou. disse.
“Em geral, a Okta recomenda limpar todas as credenciais e cookies/tokens de sessão em um arquivo HAR antes de compartilhá-lo.
“Ataques como este destacam a importância de permanecer vigilante e estar atento a atividades suspeitas”. ®
.
