Na sua palestra TROOPERS19 ("I'm in your cloud ... reading everyone's email"), Dirk-jan Mollema discutiu um problema que descobriu e que permitia a utilização de correspondência SMTP (também designada por correspondência suave) para sincronizar utilizadores do Active Directory (AD) para o Azure AD, com o objectivo de sequestrar contas não sincronizadas. Jan afirmou que a Microsoft bloqueou a capacidade de sincronizar contas no local que tinham atribuições activas a funções administrativas no Azure AD.
Investigámos esta declaração. Más notícias: A nossa investigação mostra que qualquer pessoa com privilégios de criação de conta num ambiente AD pode modificar a palavra-passe de um utilizador do Azure AD e - com alguns pré-requisitos - obter acesso privilegiado através de atribuições de funções elegíveis.
O que conduz a esta vulnerabilidade do Azure AD?
A maioria das organizações utiliza o Active Directory para gerir as permissões e o acesso aos recursos de rede. Muitas destas organizações também estão a começar a utilizar o Azure AD, um serviço de gestão de identidade e acesso baseado na nuvem, para gerir identidades de utilizador e privilégios de acesso a recursos como o portal do Azure e o Office 365.
Nas implementações de identidade híbrida, os objectos são sincronizados entre os ambientes do AD no local e os inquilinos do Azure AD. Nesses ambientes, os utilizadores podem utilizar a mesma identidade para o AD no local e para o Azure AD.
Conexão do Azure AD
O Azure AD Connect é uma aplicação da Microsoft concebida para obter uma identidade híbrida através da sincronização de objectos AD no local com objectos Azure AD. O Azure AD Connect inclui muitas funcionalidades, sendo as mais importantes a sincronização de hash de palavra-passe, a autenticação de passagem, a integração de federação (com o ADFS) e a sincronização (com o Azure AD Connect Sync). A sincronização de hash de palavra-passe e a sincronização geral são mais relevantes para esta discussão.
Durante uma instalação do Azure AD Connect Express, são criadas novas contas para suportar a sincronização.
- Conta do conector AD DS:
- Utilizado para ler e escrever no AD
- Concedidas as permissões Replicar Alterações de Directório e Replicar Alterações de Directório Todas para utilização da Password Hash Sync
- Com o prefixo MSOL_########
- Conta do serviço ADSync: Utilizada para a sincronização e para aceder à base de dados SQL
- Conta do Conector do Azure AD:
- Utilizado para escrever informações no Azure AD
- Concedida a função especial Contas de Sincronização de Diretório, que tem permissões apenas para executar tarefas de sincronização de diretório
- Prefixado com Sync_*
Numa implementação de identidade híbrida, a integridade entre ambientes no local e inquilinos do Azure AD é importante. Para atingir este objectivo, o Azure AD Connect faz corresponder objectos de utilizador entre o Azure AD e o AD.
Durante a configuração e sincronização iniciais do Azure AD Connect, é escolhido um atributo de âncora de origem. Este atributo identifica de forma exclusiva um objecto de utilizador entre o AD e o Azure AD. O Azure AD Connect efectua a correspondência olhando para este atributo e faz a correspondência de objectos de utilizador entre o Azure AD e o AD utilizando uma de duas técnicas:
- Correspondência difícil
- Correspondência suave (SMTP)
Correspondência difícil
Se deixar o Azure gerir a âncora de origem, o Azure AD Connect procura um de dois atributos sourceAnchor possíveis:
- O Azure AD Connect versão 1.1.486.0 e anteriores utilizam objectGUID.
- O Azure AD Connect versão 1.1.524.0 e mais recente utilizam mS-DS-ConsistencyGuid.
Quando o atributo mS-DS-ConsistencyGuid é desempatado, o Azure AD Connect escreve o objectGUID do utilizador nesse atributo. O ImmutableID é o valor correspondente no objecto do Azure AD - essencialmente, o objectGUID codificado em base64. A Figura 1 mostra um exemplo de obtenção do ImmutableID de um objecto do Azure AD a partir do objectGUID do utilizador do AD local.
Correspondência suave (SMTP)
A correspondência suave (SMTP) utiliza dois atributos que existem tanto no AD como no Azure AD:
- userPrincipalName
- endereço proxy
A correspondência suave é bem sucedida quando os objectos do utilizador são correspondidos, desde que se verifiquem duas condições:
- O atributo userPrincipalName no Azure AD corresponde ao do AD.
- O atributo proxyAddress primário no AD corresponde ao proxyAddress no Azure AD.
Quando uma correspondência directa ou indirecta é bem sucedida, o objecto de utilizador correspondente é actualizado. Se não houver correspondência, é criado um objecto de utilizador no inquilino do Azure AD para corresponder ao objecto de utilizador do AD local, utilizando os atributos da conta.
Sincronização de hash de palavra-passe
A sincronização do hash da palavra-passe é um método de autenticação implementado em ambientes de identidade híbrida do Azure AD. Este método, que está activado por predefinição, sincroniza o hash da palavra-passe do utilizador do AD local com o Azure AD a cada dois minutos. A sincronização do hash da palavra-passe permite que os utilizadores utilizem a mesma palavra-passe para iniciar sessão no AD e no Azure AD. (Para obter uma explicação mais detalhada da sincronização de hash de senha, consulte Semperis - Understanding Azure AD Password Hash Sync).
Funções activas versus funções elegíveis
Aos utilizadores do Azure AD podem ser atribuídas funções que concedem permissões para gerir vários recursos do Azure AD. As funções podem ser atribuições activas ou elegíveis.
As atribuições elegíveis requerem que o utilizador active a função. Para tal, o utilizador tem de executar uma acção MFA, fornecer uma justificação comercial ou solicitar a aprovação dos aprovadores designados. As funções elegíveis podem ser atribuídas permanentemente ou por um período específico(Figura 2). Não existe um limite de tempo para a activação de uma função elegível atribuída permanentemente.
As atribuições activas não requerem qualquer acção do utilizador para a utilização da função. Os utilizadores têm os privilégios associados a uma função enquanto permanecerem atribuídos a essa função(Figura 3).
Como a correspondência SMTP se torna uma vulnerabilidade do Azure AD
Um objecto no Azure AD pode ser gerido no Azure AD ou no AD local. Cada objecto tem um sinalizador que mostra se a conta foi sincronizada com uma conta no local. O exemplo seguinte mostra este sinalizador no painel Utilizadores do Azure. O utilizador Lee Gu está sincronizado(Figura 4); o utilizador Lynne Robbins não está(Figura 5).
Figura 5Tambémpode ver estas definições no painel Utilizadores Activos do Office 365, na coluna Estado da Sincronização(Figura 6 e Figura 7).
Figura 7
Às vezes, você pode querer transferir a fonte de autoridade de uma conta de usuário gerenciada na nuvem. Por exemplo, suponha que uma conta de usuário seja criada diretamente do Office 365, o que torna o usuário gerenciado na nuvem. Mas você deseja gerenciar esse usuário por meio do AD local, como fazemos com o restante dos seus usuários.
Para o fazer, pode utilizar a sincronização de directórios. Este método utiliza a correspondência SMTP para sincronizar a conta de utilizador do Office 365 com uma conta de utilizador no local, com base no atributo proxyAddress.
Para sincronizar contas utilizando a correspondência SMTP, são necessários dois passos:
- Crie uma conta do AD com o mesmo userPrincipalName que a conta do Azure AD.
- Configurar o atributo proxyAddress para corresponder ao proxyAddress do utilizador do Azure AD
A Figura 8 mostra as propriedades do usuário Lee Gu no AD local. Aqui, cria-se o utilizador e atribui-se-lhe o mesmo proxyAddress e userPrincipalName que o utilizador Lee Gu gerido na nuvem.
A Figura 9 mostra as propriedades do utilizador Lee Gu no Azure AD.
Se o Azure AD Connect encontrar um objecto no Azure AD com os atributos userPrincipalName e proxyAddress correspondentes, ocorre a correspondência SMTP. Se a sincronização de hash de palavra-passe estiver configurada, o que acontece por predefinição, este processo substitui a palavra-passe existente para a conta do Azure AD pela palavra-passe para a conta no local.
Notas importantes sobre o processo de correspondência SMTP:
- O utilizador do AD tem de ser sincronizado de novo.
- Dirk-jan descobriu que, se o utilizador do Azure AD for um utilizador activo com privilégios elevados, a sincronização não funciona. Por exemplo, não é possível sincronizar um utilizador no local com um utilizador Administrador Global activo do Azure AD. (Este problema foi corrigido depois de Dirk-jan o ter descoberto).
- Se o userPrincipalName do utilizador no local não corresponder ao utilizador baseado na nuvem, é criado um novo utilizador na nuvem. Este utilizador é sincronizado com o utilizador local e tem um endereço de correio electrónico válido do Office 365, que é determinado pelo seu atributo userPrincipalName e não pelo seu proxyAddress
Por exemplo, se tentar sincronizar o utilizador Megan Bowen utilizando o atributo proxyAddress mas um userPrincipalName diferente, o resultado é um novo utilizador do Azure AD - mesmo que não tenha acesso ou permissões no Azure AD(Figura 10).
Se criar um novo utilizador local com o mesmo atributo proxyAddress, mas com um userPrincipalName diferente(Figura 11), acabará por ter dois objectos de utilizador com o nome Megan Bowen, cada um com um userPrincipalName diferente. O objeto mais recente é sincronizado e o objeto original é gerenciado na nuvem pelo Azure AD(Figura 12).
Figura 12
É possível iniciar sessão com a nova conta de utilizador na nuvem e a palavra-passe no local e configurar a MFA(Figura 13).
Como a correspondência SMTP pode levar a abusos
A equipa de investigação da Semperis descobriu que é possível utilizar a correspondência SMTP para sincronizar utilizadores no local com utilizadores do Azure AD elegíveis para funções administrativas. Os atacantes que obtiveram acesso no local podem usar essa abordagem para comprometer o Azure AD.
O processo de correspondência SMTP funciona para utilizadores com privilégios elevados que são elegíveis para um privilégio que não foi activado. O abuso é possível se a função administrativa tiver sido tornada elegível directamente para o utilizador ou através de um grupo do Azure que seja elegível para activar a função.
Para abusar da correspondência SMTP, o MFA não deve ser utilizado ou a activação da função não deve exigir uma verificação do MFA. Criámos uma lista de todas as funções com privilégios elevados que não requerem a verificação MFA para a activação da função(Tabela 1).
Tabela 1. Funções altamente privilegiadas e requisitos de verificação MFA
| Exigir MFA | Não requerem MFA |
| Administrador de Protecção de Informação do Azure Administrador de facturação Administrador de aplicações na nuvem Administrador de conformidade Administrador de acesso condicional Aprovador de acesso à caixa de bloqueio do cliente Escritores de directórios Administrador do Dynamics 365 Administrador do Exchange Administrador Global Administrador do Intune Suporte de Nível 1 de Parceiro Suporte de Nível 2 de Parceiro Administrador do Power BI Administrador de Funções Privilegiadas Administrador de segurança Administrador do SharePoint Administrador do Skype for Business Administrador de utilizadores |
Utilizador convidado Utilizador convidado restrito Convidado Convidador Administrador do serviço de assistência Administrador do suporte de serviços Utilizador Leitores de directório Utilizadores de dispositivos Administrador local do dispositivo aderido ao Azure AD Aderir ao dispositivo Adesão de dispositivo do local de trabalho Contas de sincronização de directórios Gestores de dispositivos Administrador de aplicações Programador de aplicações Leitor de segurança Leitor de relatórios Leitor do Centro de Mensagens Administrador do Desktop Analytics Administrador de licenças Administrador de dispositivos na nuvem Administrador de autenticação Administrador de autenticação privilegiada Administrador de comunicações do Teams Engenheiro de suporte das comunicações Teams Especialista em suporte de comunicações de equipas Administrador de equipas Administrador do Insights Leitor de privacidade do centro de mensagens Administrador do fluxo de utilizadores com ID externo Administrador de atributos de fluxo de utilizadores de ID externa Administrador do conjunto de chaves B2C IEF Administrador de políticas B2C IEF Administrador do fornecedor de identidade externo Administrador de dados de conformidade Operador de segurança Administrador Kaizala Leitor global Administrador de pesquisa Editor de pesquisa Administrador de palavras-passe Administrador da impressora Técnico de impressoras Administrador de políticas de autenticação Administrador de grupos Administrador da Power Platform Administrador de DevOps do Azure Administrador de Identidade Híbrida Administrador de aplicações do Office Administrador de rede Líder empresarial do Insights Administrador de dispositivos de equipas Administrador de simulação de ataques Autor de carga útil de ataque Relatórios de resumo de utilização Leitor Administrador de conhecimentos Gestor de conhecimentos Administrador de nomes de domínio Administrador de Definição de Atributos Administrador de Atribuição de Atributos Leitor de definição de atributos Leitor de Atribuição de Atributos Administrador do destinatário do Exchange Administrador da governação da identidade Administrador de segurança de aplicações na nuvem Administrador de implementação do Windows Update Administrador do Windows 365 Administrador do Edge Administrador de visitas virtuais Analista de Insights |
Por exemplo, suponha que o utilizador gerido na nuvem Lidia Holloway é elegível para a função de Administrador global(Figura 14).
Utiliza a correspondência SMTP para sincronizar este utilizador com um novo utilizador local(Figura 15).
Depois de utilizar a palavra-passe local da Lidia para iniciar sessão no Azure AD, a função de Administrador Global pode ser activada(Figura 16). Para o fazer, é necessário utilizar a MFA ("Verificação adicional necessária"). Se o utilizador original da nuvem não necessitar de MFA, pode simplesmente configurá-lo e, em seguida, activar a função(Figura 17).
Figura 17
Pode activar uma função que não requer verificação adicional MFA, mas que pode ser elevada a Administrador Global, como Administrador de Aplicações. E, tal como Dirk-jan descreve, essa função pode então ser directamente escalada para a função de Administrador Global.
Usando o Semperis DSP para detectar esta vulnerabilidade do Azure AD
A Semperis Directory Services Protector (DSP ) recolhe dados de alteração do Azure AD. Para detectar uma tentativa de explorar esta vulnerabilidade, o DSP procura o padrão de ataque específico, que inclui a sincronização de um utilizador do AD com um utilizador do Azure AD elegível para uma função de elevado privilégio, seguido da activação dessa função. O indicador de segurança (SI) DSP "Azure AD Role activation after synchronization" identifica este padrão. DSP O indicador de segurança (SI) "AAD user eligible for a high-privilege role that is not synced to AD" também identifica o SI "AAD user eligible for a high-privilege role that is not synced to AD", que indica os utilizadores do Azure AD que são elegíveis para uma função de elevado privilégio e têm o atributo proxyAddress, mas não estão sincronizados com uma conta no local, tornando-os vulneráveis a este ataque.
Outras detecções de abuso de correspondência SMTP
Outra opção é utilizar os registos de auditoria do Azure para procurar qualquer sincronização e activação de função no seu ambiente(Figura 18).
Neste exemplo, pode ver que o Nome do Cliente da Acção é "DirectorySync" e que o Valor Antigo para LastDirSyncTime está vazio. Esta informação indica que esta é a primeira vez que o utilizador sincronizou com o AD local.
O seguinte registo mostra a activação da função(Figura 19). Utilizando o atributo RoleDefinitionOriginId, é possível procurar a função activada.
Correcção de abusos de correspondência SMTP
Para evitar esta exploração, a Microsoft recomenda a exigência de MFA para todos os utilizadores ("Fortaleça o seu servidor Azure AD Connect"). A mitigação é conseguida garantindo que os utilizadores têm MFA configurado antes de lhes conceder uma função elegível. Também pode desactivar a opção de utilizar a correspondência suave para sincronização.
Divulgação
Este problema foi comunicado através do Centro de Resposta de Segurança da Microsoft (MSRC) em 10 de Junho de 2022. A Microsoft respondeu em 13 de Julho: "[B]aseado na nossa avaliação, existem controlos atenuantes que um utilizador pode utilizar para evitar esta vulnerabilidade. Determinámos que o comportamento é intencional".
Saiba mais
Para saber mais sobre como proteger a sua organização contra vulnerabilidades do AD e do Azure AD, consulte os seguintes recursos:
