Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Do ponto de vista de um atacante, isso é super interessante, pois você poderá ver todos os usuários registrados, seus endereços de e-mail, os grupos dos quais fazem parte, perfis e até dispositivos (móveis junto com seus sistemas operacionais).
Para uma revisão de caixa branca, verifique se não há várias "Ação do usuário pendente" e "Redefinição de senha".
Aqui é onde você encontra todos os grupos criados no Okta. É interessante entender os diferentes grupos (conjunto de permissões) que podem ser concedidos aos usuários. É possível ver as pessoas incluídas nos grupos e os aplicativos atribuídos a cada grupo.
Claro, qualquer grupo com o nome de admin é interessante, especialmente o grupo Administradores Globais, verifique os membros para saber quem são os membros mais privilegiados.
Em uma revisão de caixa branca, não deve haver mais de 5 administradores globais (melhor se houver apenas 2 ou 3).
Encontre aqui uma lista de todos os dispositivos de todos os usuários. Você também pode ver se está sendo gerenciado ativamente ou não.
Aqui é possível observar como informações chave, como nomes, sobrenomes, e-mails, nomes de usuário... são compartilhadas entre o Okta e outras aplicações. Isso é interessante porque, se um usuário puder modificar em Okta um campo (como seu nome ou e-mail) que depois é usado por uma aplicação externa para identificar o usuário, um insider poderia tentar assumir outras contas.
Além disso, no perfil User (default) do Okta, você pode ver quais campos cada usuário possui e quais são graváveis pelos usuários. Se você não conseguir ver o painel de administração, basta ir para atualizar suas informações de perfil e você verá quais campos pode atualizar (note que para atualizar um endereço de e-mail, você precisará verificá-lo).
Os diretórios permitem que você importe pessoas de fontes existentes. Eu imagino que aqui você verá os usuários importados de outros diretórios.
Eu não vi isso, mas imagino que seja interessante descobrir outros diretórios que o Okta está usando para importar usuários, então, se você comprometer esse diretório, poderia definir alguns valores de atributos nos usuários criados no Okta e talvez comprometer o ambiente do Okta.
Uma fonte de perfil é uma aplicação que atua como uma fonte de verdade para atributos de perfil de usuário. Um usuário pode ser originado apenas por uma única aplicação ou diretório de cada vez.
Eu não vi isso, então qualquer informação sobre segurança e hacking em relação a essa opção é apreciada.
Verifique na aba Domains desta seção os endereços de e-mail usados para enviar e-mails e o domínio personalizado dentro do Okta da empresa (que você provavelmente já conhece).
Além disso, na aba Setting, se você for administrador, pode "Usar uma página de logout personalizada" e definir uma URL personalizada.
Nada interessante aqui.
Você pode encontrar aqui aplicativos configurados, mas veremos os detalhes deles mais tarde em uma seção diferente.
Configuração interessante, mas nada super interessante do ponto de vista de segurança.
Aqui você pode encontrar todos os aplicativos configurados e seus detalhes: Quem tem acesso a eles, como está configurado (SAML, OpenID), URL para login, os mapeamentos entre Okta e a aplicação...
Na aba Sign On também há um campo chamado Password reveal que permitiria a um usuário revelar sua senha ao verificar as configurações do aplicativo. Para verificar as configurações de um aplicativo a partir do Painel do Usuário, clique nos 3 pontos:
E você poderia ver mais alguns detalhes sobre o aplicativo (como o recurso de revelação de senha, se está habilitado):
Use Access Certifications para criar campanhas de auditoria para revisar o acesso dos seus usuários a recursos periodicamente e aprovar ou revogar o acesso automaticamente quando necessário.
Eu não vi isso sendo usado, mas imagino que, do ponto de vista defensivo, seja um bom recurso.
E-mails de notificação de segurança: Todos devem estar habilitados.
Integração CAPTCHA: É recomendado definir pelo menos o reCaptcha invisível.
Segurança da Organização: Tudo pode ser habilitado e os e-mails de ativação não devem demorar muito (7 dias está ok).
Prevenção de enumeração de usuários: Ambos devem estar habilitados.
Note que a Prevenção de Enumeração de Usuários não tem efeito se qualquer uma das seguintes condições for permitida (veja Gerenciamento de usuários para mais informações):
Registro de Autoatendimento
Fluxos JIT com autenticação por e-mail
Configurações do Okta ThreatInsight: Registrar e impor segurança com base no nível de ameaça.
Aqui é possível encontrar configurações corretas e perigosas.
Aqui você pode encontrar todos os métodos de autenticação que um usuário poderia usar: Senha, telefone, e-mail, código, WebAuthn... Clicando no autenticador de Senha, você pode ver a política de senha. Verifique se é forte.
Na aba Enrollment você pode ver como os que são obrigatórios ou opcionais:
É recomendável desabilitar o telefone. Os mais fortes são provavelmente uma combinação de senha, e-mail e WebAuthn.
Cada aplicativo tem uma política de autenticação. A política de autenticação verifica se os usuários que tentam fazer login no aplicativo atendem a condições específicas e impõe requisitos de fator com base nessas condições.
Aqui você pode encontrar os requisitos para acessar cada aplicativo. É recomendado solicitar pelo menos senha e outro método para cada aplicativo. Mas se como atacante você encontrar algo mais fraco, pode ser capaz de atacá-lo.
Aqui você pode encontrar as políticas de sessão atribuídas a diferentes grupos. Por exemplo:
É recomendado solicitar MFA, limitar a duração da sessão a algumas horas, não persistir cookies de sessão em extensões de navegador e limitar a localização e o Provedor de Identidade (se isso for possível). Por exemplo, se cada usuário deve fazer login de um país específico, você poderia permitir apenas essa localização.
Os Provedores de Identidade (IdPs) são serviços que gerenciam contas de usuário. Adicionar IdPs no Okta permite que seus usuários finais se autoregistrem em suas aplicações personalizadas, primeiro autenticando-se com uma conta social ou um cartão inteligente.
Na página de Provedores de Identidade, você pode adicionar logins sociais (IdPs) e configurar o Okta como um provedor de serviços (SP) adicionando SAML de entrada. Depois de adicionar IdPs, você pode configurar regras de roteamento para direcionar usuários a um IdP com base no contexto, como a localização do usuário, dispositivo ou domínio de e-mail.
Se algum provedor de identidade estiver configurado, do ponto de vista de um atacante e defensor, verifique essa configuração e se a fonte é realmente confiável, pois um atacante comprometendo-a também poderia obter acesso ao ambiente do Okta.
A autenticação delegada permite que os usuários façam login no Okta inserindo credenciais para o Active Directory (AD) ou servidor LDAP de sua organização.
Novamente, verifique isso, pois um atacante comprometendo o AD de uma organização poderia ser capaz de pivotar para o Okta graças a essa configuração.
Uma zona de rede é um limite configurável que você pode usar para conceder ou restringir acesso a computadores e dispositivos em sua organização com base no endereço IP que está solicitando acesso. Você pode definir uma zona de rede especificando um ou mais endereços IP individuais, intervalos de endereços IP ou locais geográficos.
Depois de definir uma ou mais zonas de rede, você pode usá-las em Políticas de Sessão Global, políticas de autenticação, notificações de VPN e regras de roteamento.
Do ponto de vista de um atacante, é interessante saber quais IPs são permitidos (e verificar se algum IP é mais privilegiado que outros). Do ponto de vista de um atacante, se os usuários devem acessar de um endereço IP ou região específica, verifique se esse recurso está sendo usado corretamente.
Gerenciamento de Endpoint: O gerenciamento de endpoint é uma condição que pode ser aplicada em uma política de autenticação para garantir que dispositivos gerenciados tenham acesso a um aplicativo.
Eu ainda não vi isso sendo usado. TODO
Serviços de notificação: Eu ainda não vi isso sendo usado. TODO
Você pode criar tokens de API do Okta nesta página e ver os que foram criados, suas permissões, tempo de expiração e URLs de Origem. Note que os tokens de API são gerados com as permissões do usuário que criou o token e são válidos apenas se o usuário que os criou estiver ativo.
As Origens Confiáveis concedem acesso a sites que você controla e confia para acessar sua organização Okta através da API do Okta.
Não deve haver muitos tokens de API, pois, se houver, um atacante poderia tentar acessá-los e usá-los.
As automações permitem que você crie ações automatizadas que são executadas com base em um conjunto de condições de gatilho que ocorrem durante o ciclo de vida dos usuários finais.
Por exemplo, uma condição poderia ser "Inatividade do usuário no Okta" ou "Expiração da senha do usuário no Okta" e a ação poderia ser "Enviar e-mail para o usuário" ou "Alterar o estado do ciclo de vida do usuário no Okta".
Baixe logs. Eles são enviados para o endereço de e-mail da conta atual.
Aqui você pode encontrar os logs das ações realizadas pelos usuários com muitos detalhes, como login no Okta ou em aplicativos através do Okta.
Isso pode importar logs de outras plataformas acessadas com o Okta.
Verifique os limites de taxa da API alcançados.
Aqui você pode encontrar informações genéricas sobre o ambiente do Okta, como o nome da empresa, endereço, contato de cobrança por e-mail, contato técnico por e-mail e também quem deve receber atualizações do Okta e que tipo de atualizações do Okta.
Aqui você pode baixar agentes do Okta para sincronizar o Okta com outras tecnologias.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
