No ano passado, serviços populares como Box, Google e Zoom sofreram desvios de autenticação e ataques de engenharia social. Sabendo que a Okta é o padrão ouro para autenticação segura para dezenas de milhares de clientes, decidimos, assim como fizemos com o Box, Google e Zoom, procurar problemas semelhantes em seu conjunto de produtos de identidade.
Nossa busca por APIs não documentadas nos levou à toca do coelho das soluções de identidade híbrida da Okta – e a várias divulgações de segurança:
Como qualquer equipe de pesquisa, gostamos de contar nossas histórias e compartilhas nossas técnicas, mas também sabemos como esses detalhes podem causar danos nas mãos erradas. Embora tenhamos descoberto esses problemas no ano passado, decidimos adiar a publicação por mais tempo do que o normal para dar à incrível equipe da plataforma tempo suficiente para abordar cada descoberta
A equipe da Okta também criou um guia de práticas recomendadas detalhando como configurar suas instâncias com segurança e mitigar ataques como esses. Entre em contato com seu representante da plataforma para obter mais informações.
Agradecemos imensamente a parceria e o profissionalismo da equipe de segurança de produtos da Okta e seu compromisso em tornar sua suíte resiliente aos tipos de ataques que descobrimos.
A Okta fornece um mecanismo para os clientes enviarem mensagens SMS e e-mails para seus usuários. Administradores podem criar modelos e acionar mensagens quando ocorrem determinadas ações, por exemplo, enviar um código MFA quando um usuário tenta realizar login.
O Varonis Threat Labs descobriu o CrossTalk, um bug que permitia que um administrador da plataforma enviasse SMS e mensagens de e-mail para qualquer usuário da plataforma em qualquer organização. Ao explorar o CrossTalk, um agente de ameaça com acesso a qualquer usuário Okta poderia:
O usuário receberia a mensagem legítima do serviço Okta sem nenhuma indicação ou artefatos forenses sugerindo que a mensagem veio de outro usuário ou potencialmente de um ator mal-intencionado.
Para explorar o CrossTalk, um invasor precisa primeiro comprometer um usuário Okta, então tentamos criar uma conta gratuita na plataforma para preparar nossos ataques, entretanto, a personalização do modelo está desativada no plano gratuito.
As contas de desenvolvedor, por outro lado, são uma história diferente! Criamos uma conta de desenvolvedor gratuita na Okta e, em minutos, conseguimos enviar mensagens suspeitas à nossa equipe de marketing “da Okta”.
Observe como a mensagem do invasor é anexada ao histórico de mensagens do usuário com o serviço oficial de SMS da plataforma, tornando quase impossível para o funcionário detectar um problema.
Ao criar uma conta de desenvolvedor gratuita na Okta, um invasor anônimo pode enviar SMS ou mensagens de e-mail, aparentemente da conta real da plataforma, para a base de usuários. Isso pode ser usado para iniciar um ataque de phishing, ignorar o MFA, distribuir malware ou induzir os usuários a realizar ações privilegiadas.
Abusos de engenharia social são ótimos, mas queríamos nos aprofundar, então criamos nosso próprio ambiente Okta local para examinar as formas como a nuvem da suite se comunica com dispositivos locais.
A Okta fornece vários agentes para permitir comunicações com o domínio local. Decidimos focar nos agentes mais utilizados pelas empresas: Active Directory (AD) e LDAP. Veja como o agente de sincronização do AD funciona:
Depois de configurar o ambiente de pesquisa e implantar os agentes Okta, imediatamente tentamos remover a camada de soquetes seguros (SSL) da comunicação entre os endpoints da plataforma e nosso ambiente de laboratório. Descompilar a linguagem intermediária (IL) é sempre divertido, mas também demorado, por isso optamos por um método mais rápido que nos permitisse inspecionar o tráfego Okta em textos simples.
Este não foi o único comportamento incomum que notamos em nosso ambiente de pesquisa. Durante a instalação, os agentes da Okta exigem que um usuário privilegiado autorize as requisições para todos os usuários entre o site e a plataforma. Isso é comum, mas por um motivo desconhecido, o instalador da Okta salvou as credenciais privilegiadas em texto simples nos arquivos de log do instalador.
Esses arquivos de log podem ser lidos por todos os usuários na máquina e podem ser usados para movimentação lateral dentro da rede corporativa caso o servidor de sincronização Okta seja comprometido. Isso ressalta a necessidade de verificar continuamente os segredos expostos em todo o ambiente.
Desde então, a equipe da Okta atualizou seu instalador para incluir uma caixa de seleção chamada “Não faça login no instalador”, que impedirá que as credenciais sejam armazenadas nos logs do instalador.
Depois de realizar algumas análises de protocolo, tentamos replicar os processos de agentes Okta para garantir que entendemos o funcionamento interno.
Brincar com a integração LDAP nos levou a examinar o ponto de extremidade da API do LDAP na plataforma. É aqui que as solicitações de login e API seguem (sem muita manipulação) do dispositivo do usuário, pela nuvem, até o servidor LDAP local. Nosso primeiro pensamento foi tentar a injeção de LDAP e, isso funcionou.
Conseguimos passar nomes de usuários entre parênteses para o endpoint e, quando cuidadosamente elaborados, o servidor LDAP os interpretou. Embora isso não nos permitisse ignorar a autenticação, conseguimos evitar o mecanismo de proteção de força bruta da Okta fornecendo uma instrução AND TRUE no final do nome de usuário.
Nossa suspeita é que o código de proteção de força bruta incrementava um contador toda vez que não conseguia encontrar o nome de usuário fornecido no banco de dados. Ao adicionar AND TRUE (e fazer com que o código da API o interprete), o contador não seria incrementado.
Continuando com nossa crença de que a pesquisa de vulnerabilidade deve representar ataques práticos, concluímos que esse ataque era válido, mas impraticável devido aos requisitos modernos de complexidade de senha. Queríamos encontrar algo melhor.
Vamos nos concentrar no agente LDAP aqui para simplificar, mas também realizamos esses ataques em outros agentes de sincronização, incluindo o agente de sincronização do AD.
Existem dois arquivos confidenciais na máquina em que o agente de sincronização Okta está instalado. Um é o arquivo de configuração do agente, que contém um token SSWS criptografado de longa duração. O outro é o arquivo de log de instalação, que contém o nome de usuário e a senha da entidade privilegiada que o agente usa para autenticar no diretório local (essas credenciais também estão no arquivo de configuração).
A configuração do agente do Active Directory é criptografada usando o DPAPI (API de proteção de dados) da Microsoft. A configuração do agente LDAP é criptografada usando um método proprietário. Em ambos os casos, a descriptografia do token SSWS é trivial, pois podemos visualizar o código fonte descompilado do agente.
Explorando a API usada pelo serviço de nuvem da plataforma e o agente de sincronização local, descobrimos que é possível usar o token SSWS descriptografado que encontramos para registrar um agente de sincronização malicioso, e nosso agente malicioso pode pesquisar novas tentativas de login da Okta. Se a autenticação delegada estiver habilitada, quando um usuário tentar fazer login, o serviço de nuvem da suite enviará a solicitação de login ao agente malicioso para aprovação.
As configurações padrão para os agentes AD e LDAP, que exigem solicitações de ligação LDAP com senhas em texto sem formatação para autenticar o usuário com o diretório local, permitiram que nosso agente sequestrasse as credenciais de texto sem formatação de cada usuário que tentasse efetuar login.
Se a autenticação delegada não estiver habilitada, a sincronização de senha geralmente estará. Esse recurso realiza a sincronização entre as senhas da plataforma e do LDAP/Active Directory para que os funcionários não precisem atualizar suas senhas duas vezes.
O token SSWS pode ser usado indefinidamente, quantas vezes quisermos, sem afetar a funcionalidade do agente original. Isso significa que o mesmo token pode ser usado para pesquisar comandos Okta em todos os diretórios ativos e LDAP integrados.
Se o provisionamento just-in-time estiver habilitado na integração de diretório (implica autenticação delegada), todas as solicitações na plataforma serão encaminhadas para todos os agentes LDAP, tanto para usuários Okta existentes quanto para usuários não existentes. Conseguimos usar o token SSWS de uma gente LDAP para autorizar o acesso a todos os usuários do LDAP e do Active Directory. Também poderíamos usar o token SSWS para autenticar usuários inexistentes e provisioná-los como administradores de domínio, esperando que os administradores de domínio do Active Directory também recebam permissões privilegiadas na Okta automaticamente.
Com este método, também é possível ignorar o MFA, pois este será o primeiro login de um novo usuário sem o MFA ativado ainda. Este ataque deixará um artefato nos logs da Okta, porque a plataforma registrará o provisionamento de um novo usuário.
Quanto o provisionamento just-in-time está ativado, as solicitações de autenticação são delegadas somente para usuários Okta. Esses são usuários que existem na plataforma, mas não estão em nenhum LDAP ou AD. O superadministrador da Okta geralmente é esse usuário. Se atendermos a essa solicitação com nosso token SSWS comprometido podermos acessar a conta de superadministrador Okta.
Os novos agentes que cadastramos apareciam no painel administrativo da plataforma, bem como nos logs, então essa pode ser uma forma de detectar se algum agente secreto foi cadastrado em seu ambiente.
Um agente mal-intencionado pode ser executado de qualquer lugar, mas invasores experientes disfarçarão o roubo de senhas realizando o ataque no ambiente já comprometido da vítima, como demonstramos abaixo.
Pode ser difícil treinar os usuários finais para identificar ataques de phishing quando esses ataques vêm de um serviço legitimo. Nem é preciso dizer que o MFA, embora não seja perfeito, oferece grande resiliência contra phishing e ataques baseados em identidade. A Okta também fornece ampla funcionalidade para ajudar a reduzir riscos:
O Active Directory é conhecido por sua enorme superfície de ataque. O monitoramento do AD deve ser uma parte essencial de sua pilha de segurança para que seja possível identificar pontos fracos (por exemplo, contas de administrador com SPN), configurações incorretas e detectar anormalidades que podem resultar de ataques comuns como Kerberoasting ou novos ataques como o Secret Agent.
Cada serviço em nuvem possui ações críticas que as equipes de segurança devem conhecer imediatamente. Na Okta, é importante saber se um novo superadministrador foi criado ou, como vimos aqui, se um novo agente de sincronização foi cadastrado para que você possa validar sua legitimidade.
Para outros aplicativos como GitHub, Salesforce ou AWS, essas ações principais serão diferentes. Empregar uma solução de segurança SaaS como o DatAdvantage Cloud, com detecções prontas para uso e percepções de configuração incorreta adaptadas a cada serviço SaaS, pode ajudar a gerenciar sua postura de segurança entre nuvens e alertar quando algo anormal acontecer.
E como a Varonis pode te ajudar a reduzir esses riscos? Entre em contato com nossos especialistas e agende uma demonstração gratuita para entender como a plataforma de segurança Varonis torna seus dados mais seguros.