Visão

Recentemente, Varonis pesquisador Eric Saraga publicou um post no blog anunciando um novo ataque contra Azure Active Directory (Azure AD) que pode permitir que um invasor faça logon como qualquer usuário sincronizado. O método de ataque explora uma falha no método de verificação de senha de autenticação de passagem (PTA) de permitir que os usuários usem suas credenciais do Active Directory no local para fazer login no Azure e no Office 365.

o PTA é um mecanismo disponível para as organizações permitirem que os usuários usem seu Active Directory local (também conhecido como serviços do Active Directory ou “AD DS” e não deve ser confundido com o Azure AD, que é o serviço de diretório baseado em nuvem da Microsoft-claro como lama?)

o PTA simplesmente passa o nome de usuário e a senha do Usuário e o transmite com segurança para o AD DS local da organização para verificação. Os outros dois métodos disponíveis são:

  • Sincronização de Hash de Senha: este método sincroniza os hashes de senha do AD local para o Azure AD (como um aparte, este método não é recomendado pelo Assura).
  • Federação através do Active Directory Federation Services( ADFS): este método baseia-se na função SAML (security Assertion Markup Language) da Microsoft disponível Microsoft Windows Server.

o PTA é facilitado por meio do Microsoft Azure AD Connect que facilita um monte de serviços, incluindo a sincronização de usuários e grupos do on-prem AD para o Azure AD/Office 365. Obviamente, com apenas um servidor on-prem facilitando o PTA, isso apresenta às organizações um único ponto de falha que, se offline, impediria os usuários de fazer login nos Serviços do Azure e do Office 365. Portanto, para resolver esse problema, a Microsoft desenvolveu um agente autônomo que pode ser executado em um servidor diferente e criar um mecanismo de autenticação de alta disponibilidade para o PTA.

para ficar claro, o ataque não explora uma fraqueza no próprio PTA, ele explora uma fraqueza na maneira como o agente faz sua coisa. No entanto, e para ser claro, o servidor que executa o agente deve ser comprometido primeiro para que o ataque contra o agente possa ter sucesso. Portanto, um invasor precisa de acesso à rede local ou precisa explorar uma máquina local remotamente e girar para o agente por meio do host comprometido. O invasor também precisa obter privilégios administrativos para o servidor que hospeda o agente.

depois que um invasor compromete com sucesso um servidor executando o agente do Azure, ele manipula o fluxo de autenticação conectando a função de API LogonUserW. Depois que o invasor se conecta com sucesso à função API, ele pode comprometer as senhas de usuários sincronizados que se conectam ao Azure AD/Office 365. Varonis deu um passo adiante e automatizou a coleta de credenciais injetando uma DLL personalizada (Dynamic Link Library) no fluxo de processo que ainda autenticará o usuário, mas, além disso, grava o nome de usuário e a senha do indivíduo em um arquivo de texto especificado. Embora isso dê ao invasor muitas maneiras de se autenticar, ele não fornece a “chave esqueleto”.”Para conseguir isso, precisamos de mais.

modificar o valor de retorno na função API, LogonUserW, para aceitar qualquer senha como correta para qualquer usuário é a chave para transformar este ataque em um ataque de chave esqueleto. LogonUserW é uma função booleana que requer a população do token do Usuário. Se esse token retornar um valor verdadeiro, a autenticação será bem-sucedida. O processo que o agente do Azure usa para autenticar usuários tem seu próprio token e a função API LogonUserW está sendo chamada dentro desse processo, então os pesquisadores da Varonis se perguntaram: “Por que não usar o próprio token do processo do agente?”E pronto, a chave esqueleto do Azure AD foi criada: o próprio token do processo permitirá que um invasor faça login como usuário, incluindo uma conta de Administrador Global.

os detalhes sangrentos podem ser encontrados no post de Saraga aqui: https://blogvaronis2.wpengine.com/azure-skeleton-key/

gorjeta de chapéu para nosso amigo Steven Rennard na Varonis por nos alertar para esta pesquisa.

Assura’s Take

embora este seja certamente um ataque de alto impacto, parece da comunicação da Varonis com a Microsoft que não há planos para corrigir essa vulnerabilidade tão cedo. Como tal, torna-se ainda mais importante garantir que seu ambiente e usuários estejam completamente protegidos por meio de práticas de configuração seguras e tecnologias de segurança modernas.

detectar um invasor entrando em sua rede por meio de uma tecnologia IDS/IPS ou SIEM, limitando a capacidade do invasor de escalar privilégios ou pivotar por meio de uma ferramenta de detecção e Resposta de Endpoint e evitando esse ataque de chave-esqueleto por meio da implementação da tecnologia de Autenticação Multifator (MFA) são opções viáveis e práticas para mitigar essa ameaça.

se você é um Assura Managed SIEM, Managed Endpoint Protection ou Managed Multi-Factor Authentication client, estamos ativamente tomando medidas para protegê-lo desses ataques. Se você é um cliente Assura existente, entre em contato com seu ISO virtual ou Assura POC para obter mais orientações.

Mantenha-se seguro, Mantenha-se saudável e, como sempre, sinta-se à vontade para enviar quaisquer perguntas que você possa ter sobre este ou qualquer outro assunto de segurança cibernética através de nosso site ou para [email protected]

sinceramente,

a equipe Assura

Deixe uma resposta

O seu endereço de email não será publicado.