Okta Security
Informações Básicas
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 do usuário em várias aplicações modernas. Elas atendem não apenas a empresas que visam proteger seus dados sensíveis, mas também a desenvolvedores interessados em integrar controles de identidade em aplicativos, serviços da web e dispositivos.
A oferta principal da Okta é a Okta Identity Cloud. Esta plataforma engloba uma série 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.
Autenticação Multifator (MFA): Aumenta a segurança exigindo múltiplas formas de verificação.
Gerenciamento de Ciclo de Vida: Automatiza a criação, atualização e desativação de contas de usuário.
Diretório Universal: Permite o gerenciamento centralizado de usuários, grupos e dispositivos.
Gerenciamento de Acesso a API: Protege e gerencia o acesso a APIs.
Esses serviços têm como objetivo fortalecer a proteção de dados e simplificar o acesso do usuário, aprimorando 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 no campo de Gerenciamento de Identidade e Acesso (IAM).
O principal objetivo da Okta é configurar o acesso de diferentes usuários e grupos a aplicações externas. Se você conseguir comprometer privilégios de administrador em um ambiente Okta, é altamente provável que consiga 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.
Resumo
Existem usuários (que podem ser armazenados no Okta, logados a partir de Provedores de Identidade configurados ou autenticados via Active Directory ou LDAP). Esses usuários podem estar dentro de grupos. Também existem autenticadores: diferentes opções de autenticação como senha e várias formas de autenticação em duas etapas como WebAuthn, e-mail, telefone, okta verify (podem estar habilitados ou desabilitados)...
Em seguida, existem aplicações sincronizadas com o Okta. Cada aplicação terá algum mapeamento com o Okta para compartilhar informações (como endereços de e-mail, 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 é o de Super Administrador.
Se um atacante comprometer o Okta com acesso de Administrador, todas as aplicações que confiam no Okta provavelmente serão comprometidas.
Ataques
Localizando o Portal do Okta
Normalmente, o portal de uma empresa estará localizado em nomedaempresa.okta.com. Se não, tente variações simples de nomedaempresa. Se você não conseguir encontrar, também é possível que a organização tenha um registro CNAME como okta.nomedaempresa.com apontando para o portal do Okta.
Login no Okta via Kerberos
Se nomedaempresa.kerberos.okta.com estiver ativo, o Kerberos é usado para acesso ao Okta, geralmente contornando a MFA para usuários do Windows. Para encontrar usuários do Okta autenticados por Kerberos no AD, execute getST.py com os parâmetros apropriados. Ao obter um ticket de usuário AD, injete-o em um host controlado usando ferramentas como Rubeus ou Mimikatz, garantindo que nomedocliente.kerberos.okta.com esteja na zona "Intranet" das Opções da Internet. Acesso a uma URL específica deve retornar uma resposta JSON "OK", indicando a aceitação do ticket Kerberos e concedendo acesso ao painel do Okta.
Comprometer a conta de serviço do Okta com a SPN de delegação permite um ataque de Silver Ticket. No entanto, o uso do Okta do AES para criptografia de tickets requer possuir a chave AES ou a senha em texto simples. Use ticketer.py para gerar um ticket para o usuário vítima e entregue-o via navegador para autenticar com o Okta.
Verifique o ataque em https://trustedsec.com/blog/okta-for-red-teamers.
Sequestro do Agente AD do Okta
Essa técnica envolve acessar o Agente AD do Okta em um servidor, que sincroniza usuários e lida com autenticação. Ao examinar e descriptografar configurações em OktaAgentService.exe.config, especialmente 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 do Okta, mas também responder a tentativas de autenticação, permitindo assim acesso não autorizado ou fornecendo autenticação universal por meio do Okta (semelhante a uma 'chave mestra').
Verifique o ataque em https://trustedsec.com/blog/okta-for-red-teamers.
Sequestro do AD como Administrador
Essa técnica envolve sequestrar um Agente AD do Okta obtendo primeiro um Código OAuth, e em seguida 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 processar tentativas de autenticação, capturando credenciais por meio da API do Okta. Ferramentas de automação estão disponíveis para simplificar esse processo, oferecendo um método contínuo para interceptar e lidar com dados de autenticação dentro do ambiente do Okta.
Verifique o ataque em https://trustedsec.com/blog/okta-for-red-teamers.
Provedor SAML Falso do Okta
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 externo (IdP) dentro do framework do Okta usando uma conta privilegiada, os atacantes podem controlar o IdP, aprovando qualquer solicitação de autenticação a seu critério. O processo envolve configurar um IdP SAML 2.0 no Okta, manipular a URL de Logon Único do IdP para redirecionamento via arquivo hosts local, gerar um certificado autoassinado e configurar as configurações do Okta para corresponder ao nome de usuário ou e-mail. Executar com sucesso essas etapas permite a autenticação como qualquer usuário do Okta, contornando a necessidade de credenciais de usuário individuais, elevando significativamente o controle de acesso de forma potencialmente imperceptível.
Phishing no Portal Okta com Evilgnix
No post do blog é explicado como preparar uma campanha de phishing contra um portal Okta.
Ataque de Impersonação de Colega
Os atributos que cada usuário pode ter e modificar (como email ou primeiro nome) podem ser configurados no Okta. Se uma aplicação está confiando em um atributo que o usuário pode modificar, ele será capaz de impersonar outros usuários naquela plataforma.
Portanto, se a aplicação está confiando no campo userName, provavelmente você não poderá alterá-lo (porque geralmente não é possível alterar esse campo), mas se estiver confiando, por exemplo, em primaryEmail, você pode ser capaz de alterá-lo para o endereço de email de um colega e se passar por ele (você precisará ter acesso ao email e aceitar a alteração).
Observe 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, a aplicação deve ter esse campo habilitado se ele existir:
Também vi outras aplicações vulneráveis que não tinham esse campo nas configurações do Okta (no final, diferentes aplicações são configuradas de forma diferente).
A melhor maneira de descobrir se você poderia se passar por alguém em cada aplicação seria tentar!
Evitando políticas de detecção comportamental
As políticas de detecção comportamental no Okta podem ser desconhecidas até encontradas, mas burlá-las pode ser alcançado direcionando-se diretamente às aplicações do Okta, evitando o painel principal do Okta. Com um token de acesso do Okta, replique o token no URL específico da aplicação do Okta em vez da página principal de login.
Recomendações-chave incluem:
Evitar o uso de proxies anonimizadores populares e serviços VPN ao reproduzir tokens de acesso capturados.
Garantir cadeias de agente do usuário consistentes entre o cliente e os tokens de acesso reproduzidos.
Abster-se de reproduzir tokens de diferentes usuários do mesmo endereço IP.
Ter cautela ao reproduzir tokens no painel do Okta.
Se ciente dos endereços IP da empresa da vítima, restringir o tráfego para esses IPs ou sua faixa, bloqueando todo o tráfego restante.
Reforço de Segurança do Okta
O Okta possui muitas configurações possíveis, nesta página você encontrará como revisá-las para que sejam o mais seguras possível:
pageOkta HardeningReferências
Última actualización
