1Password detecta “atividade suspeita” em conta interna do Okta
(arstechnica.com)- A 1Password detectou atividade suspeita em sua instância interna do Okta, usada para gerenciar o acesso a aplicativos de funcionários, em 29 de setembro, e não encontrou indícios de violação de dados de usuários nem de sistemas sensíveis
- Esse acesso foi ligado à violação do sistema de gestão de suporte ao cliente da Okta, e os invasores podem ter obtido cookies de autenticação e tokens de sessão a partir de arquivos HAR enviados por clientes
- Um relatório interno da 1Password no Notion resume que o invasor obteve um arquivo HAR criado por um funcionário de TI enquanto trabalhava com o suporte da Okta, e que esse arquivo continha tráfego do Okta e cookies de sessão
- O invasor solicitou um relatório de usuários administradores no tenant Okta da 1Password e atualizou e ativou um IDP usado para autenticação no ambiente de produção do Google, mas a tentativa de reutilização posterior falhou porque o IDP foi removido
- A violação da Okta tornou-se um caso de ataque subsequente, no qual a invasão de um fornecedor leva a ataques contra clientes, e a 1Password se tornou o segundo cliente da Okta conhecido a ser alvo
1Password detecta acesso interno ao Okta
- A 1Password é um gerenciador de senhas usado por milhões de usuários e mais de 100 mil empresas
- A empresa confirmou atividade suspeita em sua instância do Okta usada para gerenciar aplicativos de funcionários em 29 de setembro
- O CTO Pedro Canahuati afirmou que a atividade foi encerrada imediatamente e investigada, e que não foram encontrados indícios de comprometimento de dados de usuários nem de sistemas sensíveis de funcionários ou usuários
- Depois disso, a 1Password investigou junto com a Okta por qual caminho um invasor desconhecido acessou a conta
Violação do sistema de suporte da Okta e risco dos arquivos HAR
- Foi confirmado que o incidente da 1Password teve origem na violação do sistema de gestão de suporte ao cliente divulgada pela Okta
- A Okta informou que um agente malicioso acessou sem autorização o sistema de gestão de casos de suporte ao cliente e viu arquivos enviados por alguns clientes da Okta
- Entre os arquivos obtidos estavam arquivos HAR, usados pela equipe de suporte da Okta para reproduzir a atividade do navegador do cliente durante a solução de problemas
- Arquivos HAR podem armazenar informações sensíveis, como cookies de autenticação e tokens de sessão, e isso pode ser explorado por invasores para se passar por usuários legítimos
Segundo alvo conhecido depois da BeyondTrust
- A empresa de segurança BeyondTrust descobriu a invasão depois que um invasor tentou acessar sua conta Okta com cookies de autenticação válidos
- Na BeyondTrust, o invasor conseguiu realizar “algumas ações limitadas”, mas os controles de política de acesso bloquearam a atividade e impediram o acesso à conta
- A 1Password se tornou o segundo cliente conhecido da Okta a virar alvo de um ataque subsequente após a violação da Okta
Sequência do incidente descrita em relatório interno no Notion
- Um relatório datado de 18 de outubro e compartilhado no workspace interno da 1Password no Notion afirma que o invasor obteve um arquivo HAR criado por um funcionário de TI da empresa
- Esse funcionário havia criado o arquivo recentemente enquanto trabalhava com o suporte da Okta
- O arquivo continha todo o registro de tráfego entre o navegador do funcionário da 1Password e os servidores da Okta, além de cookies de sessão
- A 1Password não respondeu ao pedido de verificação da autenticidade do documento, fornecido por um funcionário anônimo em texto e capturas de tela
- Segundo o relatório, o invasor também acessou o tenant Okta da 1Password
- O tenant Okta é usado para gerenciar permissões de acesso a sistemas e níveis de privilégio atribuídos a funcionários, parceiros e clientes
- O invasor visualizou atribuições de grupos e realizou outras ações, mas algumas delas não foram registradas no log de eventos
- Ele atualizou o IDP (identity provider) usado no login para autenticação do ambiente de produção fornecido pelo Google
Ações realizadas pelo invasor e nova tentativa bloqueada
- A equipe de TI da 1Password descobriu o acesso em 29 de setembro ao receber um email inesperado que indicava uma solicitação de lista de usuários da 1Password com privilégios de administrador
- Os integrantes da equipe concluíram que nenhum funcionário autorizado havia feito a solicitação e alertaram a equipe de resposta de segurança da empresa
- As ações realizadas pelo invasor foram as seguintes
- Tentou acessar o dashboard Okta de um funcionário de TI, mas foi bloqueado
- Atualizou o IDP existente ligado ao ambiente Google de produção da 1Password
- Ativou esse IDP
- Solicitou um relatório de usuários administradores
- Em 2 de outubro, o invasor voltou a fazer login no tenant Okta da 1Password e tentou usar o Google IDP que havia ativado anteriormente, mas falhou porque o IDP havia sido removido
- Os dois acessos partiram de servidores LeaseWeb hospedados nos Estados Unidos e usaram uma versão do Chrome em uma máquina Windows
- Depois do incidente, a 1Password alterou a configuração do tenant Okta para recusar login por provedores de identidade que não sejam da própria Okta
Como uma violação de fornecedor leva a ataques contra clientes
- A violação da Okta é um dos vários ataques dos últimos anos contra fornecedores de software e serviços com grandes bases de clientes
- Depois de invadir o fornecedor, o atacante usa essa posição para executar ataques subsequentes contra empresas clientes
- É possível que mais clientes da Okta sejam identificados no futuro
1 comentários
Comentários do Hacker News
Terceirizar o SSO não é só uma questão de ser tecnicamente mais fácil ou de ter capacidade operacional. Um fator importante é poder dizer nos contratos com clientes que se usa um provedor de SSO respeitável, e que esse provedor também assume a responsabilidade pela documentação sobre o modelo de gerenciamento de chaves e a proteção do material de chaves
No caso da 1Password, é provável que ela já tenha essa estrutura, então é um pouco peculiar, mas em geral é muito mais fácil dizer “ninguém na organização tem acesso às chaves” do que “só o Bob é uma exceção; ele opera o servidor de SSO e nós confiamos nele”
É interessante que as vulnerabilidades de segurança de memória em C sejam as mais comentadas, mas, em muitos casos, o que tem impacto real maior é o chamado colapso de insight, causado por complexidade excessiva ao seguir o que se considera um bom design
Vejo a causa raiz como a limitação humana de não conseguir compreender uma complexidade gigantesca
Este último ponto provavelmente é complexo por envolver seres humanos, e por isso fica mais fácil buscar salvação na tecnologia
Pelo trecho “trocamos todas as credenciais de sistema do integrante da equipe de TI e mudamos o MFA para usar apenas YubiKey”, seria bom se isso virasse um motivo para exigir autenticação de dois fatores baseada em YubiKey de todos os funcionários. Qualquer coisa abaixo de FIDO2 é realmente fraca
Fico curioso por que as pessoas ainda escolhem a Okta. Pessoalmente, acho muito mais cômodo usar o GSuite como provedor de identidade. A Okta já sofreu uma violação bastante séria e, sinceramente, mesmo antes disso eu não ouvia coisas boas sobre as práticas de segurança dela
Obrigar MFA baseado em hardware é uma boa prática e pode impedir ataques como spear phishing no futuro, mas não tem relação com este incidente em si
As pessoas escolhem a Okta por algo próximo de “ninguém foi demitido por comprar IBM”. Se eu operar meu próprio Keycloak e ele for invadido, a culpa é minha; com a Okta, vira uma estrutura de terceirização em que o problema deixa de ser meu, e isso também pesa
Questiono se você já usou de fato o Google Workspace para algo sério. Ele é um dos provedores de identidade com menos recursos, enquanto a Okta está entre os mais completos. Compará-los só porque ambos têm duas rodas é como comparar uma bicicleta com uma motocicleta
Nunca imaginei que veria alguém em um fórum técnico recomendando o Google Workspace como provedor de identidade
Usar YubiKey faz com que todo o suporte ao cliente relacionado a problemas de senha fique com o departamento interno de TI, não com uma empresa terceirizada
MFA tem problemas técnicos e sociais; o aspecto técnico de segurança de implementações como chaves, tokens, celulares e SMS é quase trivial, enquanto os problemas sociais — suporte ao cliente, senhas perdidas, chaves que foram parar na máquina de lavar, impossibilidade de receber e-mails — são esmagadoramente maiores
Todo mundo quer terceirizar o papel enorme e idiota de suporte ao cliente em segurança, mas, depois que isso é feito, todos passam a ser incentivados a cortar custos. O resultado é a Okta
Por exemplo, em uma organização em que todos os funcionários estão no GSuite, a forma recomendada de fornecer acesso a uma organização AWS é o AWS SSO[1]. Ao configurar a conexão, o acesso passa a ser possível, mas há lacunas
Não há recurso para provisionar ou remover automaticamente usuários no AWS SSO com base nos grupos de usuários do GSuite. Com o suporte a SCIM do SSO, dá para escrever o código você mesmo, mas será preciso mantê-lo
Não há como forçar uma verificação de MFA ao criar uma sessão SSO, nem pelo lado do GSuite nem pelo lado do AWS SSO. O GSuite não consegue exigir verificação de MFA antes da autenticação de uma aplicação SAML, e o AWS SSO, ao usar um provedor de identidade, também não consegue impor verificação de MFA, ao contrário do que acontece quando se usa o Directory interno
A Okta e produtos semelhantes fazem esse tipo de coisa e, dizem, também podem exigir verificação de MFA dependendo do endpoint em uso. Não testei diretamente; isso é com base em materiais de marketing e explicações de vendas
Em resumo, a Okta oferece muito mais cola de automação e segurança entre o provedor de identidade e as aplicações usadas
[1] Aqui, AWS SSO significa o produto da AWS “AWS IAM Identity Center (Successor to AWS Single Sign-On)”
As evidências que vemos agora são basicamente que a Okta sofreu uma violação no ano passado, sofreu uma violação desta vez também, e que esta violação ocorreu no departamento ou nos sistemas de suporte ao cliente. A divulgação da violação pode ter atrasado, mas também pode ser que, por haver muitas denúncias falsas, eles não tenham encontrado evidências até recentemente. Talvez não tenham dado crédito ao cliente que fez o primeiro alerta e talvez não tenham se comunicado adequadamente com o cliente depois da denúncia
Há muito mais coisas que não sabemos. Não sabemos quão habilidoso era o invasor, quantas vezes cada provedor de identidade foi violado, quantas vezes detectou violações, se detectou e encobriu, quantos bugs de segurança cada serviço tem, quão graves são e quão fáceis são de encontrar, qual é a capacidade de detecção de violações, quão bom é o treinamento dos funcionários, nem qual proporção dos funcionários realmente se importa com segurança
Não dá para concluir que o produto é pior só porque a Okta relatou uma violação. Não sabemos quão bons são os outros produtos, e é possível que a Okta seja melhor que alguns ou todos os concorrentes; claro, também pode ser pior
Antigamente, eu comprava o 1Password pelo preço cheio, e o software funcionava totalmente offline, armazenando o cofre criptografado localmente ou no Dropbox. Como não havia nada online para roubar, também não era preciso se preocupar com hackers
Mas então alguém fez as contas e decidiu que o caminho para aumentar a rentabilidade era mover os dados de todo mundo para a nuvem e cobrar assinatura. E agora estamos preocupados se os dados vazaram
E, até onde sabemos agora, quão diferente isso é de deixar o cofre no Dropbox? O Dropbox também pode ser hackeado, e seus dados são famosos por não serem criptografados. Ainda não sabemos de nenhum caso em que um cofre do 1Password tenha sido realmente comprometido, certo?
https://blog.1password.com/okta-incident/
Relatório original do incidente: https://blog.1password.com/files/okta-incident/okta-incident...
Depois, um agente desconhecido acessou o portal de administração da Okta usando a mesma sessão da Okta que havia sido usada para criar aquele arquivo HAR
Como os bancos sempre dizem, não se deve entregar sua senha ao suporte
Desta vez, a responsabilidade é claramente da Okta. Ao exigir sessões HAR codificadas em texto puro para resolver problemas, ela fica esperando que o usuário final faça a limpeza corretamente.
Não daria para sanitizar os dados HAR no momento do upload, deixando apenas as partes relevantes e seguras para os técnicos de suporte que entram no sistema, mal pagos e com equipe insuficiente, visualizarem?
HAR é dado estruturado, então é muito fácil limpá-lo programaticamente. Não é ciência de foguetes
As pessoas continuam perguntando por que alguém usaria um gerenciador de senhas auto-hospedado e com sincronização própria em vez de um serviço online super simples e super amigável, e o motivo é o mesmo. É como não jogar as chaves do seu apartamento no cofre da estação de trem do bairro
Essas organizações corrigem os problemas semanas, às vezes meses, antes de emitir comunicados.
Se você usa open source e um bug crítico é descoberto, receberá o patch junto com o comunicado à imprensa, mas é bem provável que os grandes serviços já tenham corrigido esse problema. Para o usuário médio, a relação risco-benefício favorece as soluções como serviço
Também dá para usar em scripts.
Não há comprometimento de servidor, nem vulnerabilidade de extensão web, nem risco de perder todas as senhas por erro no servidor. Simplesmente funciona bem
A frase “o 1Password se tornou o segundo cliente conhecido da Okta a ser alvo de ataques subsequentes” é estranha. A Ars não sabe que a Cloudflare também foi vítima?
https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...
Fico curioso sobre as melhores práticas para monitorar comportamento suspeito em apps. Conheço o básico, como verificar taxa de requisições ou taxa de erros no escopo do serviço, mas, na prática, quão sofisticado isso fica?
Fico pensando se existem ferramentas inteligentes que recebem um fluxo de eventos e encontram comportamentos anômalos, ou se é preciso pensar previamente em tudo que deve ser monitorado e adicionar regras
Quando você tem esse fluxo de eventos, pode rodar ferramentas de análise de dados. Deve criar uma linha de base do normal com dias, semanas ou meses de atividade e fazer comportamentos fora da curva, como mudanças de senha em massa ou alterações de e-mail, dispararem alertas.
Mas é só uma hipótese de sofá; fico curioso para saber se há alguém que já tenha lidado na prática com logs de auditoria e seu uso
Detectaram de novo?
https://news.ycombinator.com/item?id=37991863