Okta Security

Support HackTricks

Basic Information

Okta, Inc. é reconhecida no setor de gerenciamento de identidade e acesso por suas soluções de software baseadas em nuvem. Essas soluções são projetadas para simplificar e proteger a autenticação de usuários em várias aplicações modernas. Elas atendem não apenas a empresas que buscam proteger seus dados sensíveis, mas também a desenvolvedores interessados em integrar controles de identidade em aplicações, serviços web e dispositivos.

A oferta principal da Okta é a Okta Identity Cloud. Esta plataforma abrange um conjunto de produtos, incluindo, mas não se limitando a:

  • Single Sign-On (SSO): Simplifica o acesso do usuário permitindo um conjunto de credenciais de login em várias aplicações.

  • Multi-Factor Authentication (MFA): Aumenta a segurança exigindo múltiplas formas de verificação.

  • Lifecycle Management: Automatiza a criação, atualização e desativação de contas de usuário.

  • Universal Directory: Permite o gerenciamento centralizado de usuários, grupos e dispositivos.

  • API Access Management: Protege e gerencia o acesso a APIs.

Esses serviços visam coletivamente fortalecer a proteção de dados e simplificar o acesso do usuário, melhorando tanto a segurança quanto a conveniência. A versatilidade das soluções da Okta as torna uma escolha popular em várias indústrias, beneficiando grandes empresas, pequenas empresas e desenvolvedores individuais. Até a última atualização em setembro de 2021, a Okta é reconhecida como uma entidade proeminente na área de Gerenciamento de Identidade e Acesso (IAM).

O principal objetivo da Okta é configurar o acesso a diferentes usuários e grupos para aplicações externas. Se você conseguir comprometer privilégios de administrador em um ambiente Okta, você provavelmente será capaz de comprometer todas as outras plataformas que a empresa está usando.

Para realizar uma revisão de segurança de um ambiente Okta, você deve solicitar acesso somente leitura de administrador.

Summary

Existem usuários (que podem ser armazenados na Okta, logados de Provedores de Identidade configurados ou autenticados via Active Directory ou LDAP). Esses usuários podem estar dentro de grupos. Existem também autenticadores: diferentes opções para autenticar como senha e vários 2FA como WebAuthn, email, telefone, okta verify (podem estar habilitados ou desabilitados)...

Então, existem aplicações sincronizadas com a Okta. Cada aplicação terá algum mapeamento com a Okta para compartilhar informações (como endereços de email, primeiros nomes...). Além disso, cada aplicação deve estar dentro de uma Política de Autenticação, que indica os autenticadores necessários para um usuário acessar a aplicação.

O papel mais poderoso é Super Administrador.

Se um atacante comprometer a Okta com acesso de Administrador, todos os apps que confiam na Okta provavelmente estarão comprometidos.

Attacks

Locating Okta Portal

Geralmente, o portal de uma empresa estará localizado em companyname.okta.com. Se não, tente variações simples de companyname. Se você não conseguir encontrá-lo, também é possível que a organização tenha um registro CNAME como okta.companyname.com apontando para o portal Okta.

Login in Okta via Kerberos

Se companyname.kerberos.okta.com estiver ativo, Kerberos é usado para acesso à Okta, geralmente contornando MFA para usuários Windows. Para encontrar usuários Okta autenticados por Kerberos no AD, execute getST.py com parâmetros apropriados. Após obter um ticket de usuário AD, injete-o em um host controlado usando ferramentas como Rubeus ou Mimikatz, garantindo que clientname.kerberos.okta.com esteja na zona "Intranet" das Opções da Internet. Acessar uma URL específica deve retornar uma resposta JSON "OK", indicando a aceitação do ticket Kerberos e concedendo acesso ao painel da Okta.

Comprometer a conta de serviço Okta com o SPN de delegação permite um ataque de Silver Ticket. No entanto, o uso de AES pela Okta para criptografia de tickets requer a posse da chave AES ou senha em texto simples. Use ticketer.py para gerar um ticket para o usuário vítima e entregá-lo via navegador para autenticar com a Okta.

Verifique o ataque em https://trustedsec.com/blog/okta-for-red-teamers.

Hijacking Okta AD Agent

Esta técnica envolve acessar o Okta AD Agent em um servidor, que sincroniza usuários e lida com autenticação. Ao examinar e descriptografar configurações em OktaAgentService.exe.config, notavelmente o AgentToken usando DPAPI, um atacante pode potencialmente interceptar e manipular dados de autenticação. Isso permite não apenas monitorar e capturar credenciais de usuário em texto simples durante o processo de autenticação da Okta, mas também responder a tentativas de autenticação, permitindo assim acesso não autorizado ou fornecendo autenticação universal através da Okta (semelhante a uma 'chave mestra').

Verifique o ataque em https://trustedsec.com/blog/okta-for-red-teamers.

Hijacking AD As an Admin

Esta técnica envolve sequestrar um Okta AD Agent obtendo primeiro um Código OAuth, e então solicitando um token de API. O token está associado a um domínio AD, e um conector é nomeado para estabelecer um agente AD falso. A inicialização permite que o agente processe tentativas de autenticação, capturando credenciais via API da Okta. Ferramentas de automação estão disponíveis para agilizar esse processo, oferecendo um método contínuo para interceptar e lidar com dados de autenticação dentro do ambiente Okta.

Verifique o ataque em https://trustedsec.com/blog/okta-for-red-teamers.

Okta Fake SAML Provider

Verifique o ataque em https://trustedsec.com/blog/okta-for-red-teamers.

A técnica envolve implantar um provedor SAML falso. Ao integrar um Provedor de Identidade (IdP) externo dentro da estrutura da Okta usando uma conta privilegiada, os atacantes podem controlar o IdP, aprovando qualquer solicitação de autenticação à vontade. O processo envolve configurar um IdP SAML 2.0 na Okta, manipulando a URL de Single Sign-On do IdP para redirecionamento via arquivo de hosts local, gerando um certificado autoassinado e configurando as configurações da Okta para corresponder ao nome de usuário ou email. Executar com sucesso esses passos permite a autenticação como qualquer usuário da Okta, contornando a necessidade de credenciais individuais de usuário, elevando significativamente o controle de acesso de maneira potencialmente não percebida.

Phishing Okta Portal with Evilgnix

No este post do blog é explicado como preparar uma campanha de phishing contra um portal Okta.

Colleague Impersonation Attack

Os atributos que cada usuário pode ter e modificar (como email ou primeiro nome) podem ser configurados na Okta. Se uma aplicação estiver confiando como ID um atributo que o usuário pode modificar, ele poderá impersonar outros usuários nessa plataforma.

Portanto, se o app estiver confiando no campo userName, você provavelmente não conseguirá mudá-lo (porque geralmente não é possível alterar esse campo), mas se estiver confiando, por exemplo, em primaryEmail, você pode ser capaz de mudá-lo para o endereço de email de um colega e impersoná-lo (você precisará ter acesso ao email e aceitar a mudança).

Note que essa impersonação depende de como cada aplicação foi configurada. Apenas aquelas que confiam no campo que você modificou e aceitam atualizações serão comprometidas. Portanto, o app deve ter esse campo habilitado se existir:

Eu também vi outros apps que eram vulneráveis, mas não tinham esse campo nas configurações da Okta (no final, diferentes apps são configurados de maneira diferente).

A melhor maneira de descobrir se você poderia impersonar alguém em cada app seria tentar!

Evading behavioural detection policies

As políticas de detecção comportamental na Okta podem ser desconhecidas até serem encontradas, mas contorná-las pode ser alcançado direcionando aplicações Okta diretamente, evitando o painel principal da Okta. Com um token de acesso Okta, reproduza o token na URL específica da aplicação Okta em vez da página de login principal.

As principais recomendações incluem:

  • Evite usar proxies e serviços VPN populares ao reproduzir tokens de acesso capturados.

  • Garanta strings de agente de usuário consistentes entre o cliente e os tokens de acesso reproduzidos.

  • Evite reproduzir tokens de diferentes usuários do mesmo endereço IP.

  • Tenha cautela ao reproduzir tokens contra o painel da Okta.

  • Se souber os endereços IP da empresa vítima, restrinja o tráfego para esses IPs ou seu intervalo, bloqueando todo o outro tráfego.

Okta Hardening

A Okta tem muitas configurações possíveis, nesta página você encontrará como revisá-las para que sejam o mais seguras possível:

References

Support HackTricks

Last updated