Escalação de privilégios em Entra ID (anteriormente Azure AD)

Os ataques de escalonamento de privilégios são um dos problemas mais urgentes para as equipes de segurança em todo o mundo e são comumente usados ​​como parte de movimento lateral. Os agentes de ameaças sabem que contas privilegiadas são mais difíceis de comprometer porque normalmente são monitoradas e protegidas. No entanto, os invasores podem empregar vulnerabilidades de escalonamento de privilégios para assumir o controle de contas menos monitoradas e, subsequentemente, obter um alto nível de acesso – tudo isso enquanto permanecem sob o radar da equipe de segurança.

No ambiente híbrido atual, as empresas estão cada vez mais migrando seus recursos confidenciais para aplicativos SaaS. Azul Active Directory é um dos principais provedores de identidade em nuvem que permite às empresas gerenciar centralmente o acesso e o uso de tais aplicativos.

Descobrimos recentemente um problema de escalonamento de privilégios dentro Entra ID (anteriormente azuread) que poderia permitir que um invasor contornasse uma proteção de redefinição de senha, permitindo que administradores de nível inferior se tornassem administradores totalmente privilegiados. Relatamos esse problema ao Microsoft Security Response Center (MSRC), que o validou e aplicou uma correção. Embora já não represente um risco para Entra ID (antigo Azure AD), acreditamos que a comunidade de segurança mais ampla pode se beneficiar ao visualizar nossas análises e descobertas.

Análise Técnica

A Entra ID (anteriormente Azure AD) sistema de função privilegiada funciona como uma hierarquia, impedindo que administradores com privilégios mais baixos redefinam a senha de administradores com privilégios mais altos. Além da lógica operacional, isso também protege contra um cenário em que uma conta de administrador com privilégios mais baixos seja comprometida, garantindo que o invasor não possa modificar aqueles com privilégios mais elevados.

Esta salvaguarda se aplica quando a função do usuário é definida como “elegível” ou “ativa”. No entanto, Entra ID (anteriormente Azure AD) também permite contas de usuário a ser atribuído para uso futuro; ou seja, os privilégios de nível superior são concedidos em data e hora predefinidas.

Descobrimos que, neste caso, a proteção de senha não se aplica. Isso expõe Entra ID (anteriormente Azure AD) para o seguinte cenário:

1. Compromisso inicial: um invasor compromete uma conta de administrador com poucos privilégios.
2. Descoberta de atribuições de funções futuras: O invasor verifica Entra ID (anteriormente Azure AD) para encontrar contas que estão programadas para se tornarem administradores altamente privilegiados no futuro.
3. Redefinição de senha: o invasor agora redefine a senha dessas contas, comprometendo-as antes que a atribuição de função ocorra. Idealmente, o invasor realizaria essa redefinição o mais próximo possível do momento da mudança de função.
4. Escalonamento de privilégios: a mudança de função ocorre, proporcionando ao invasor controle total sobre uma conta de administrador ativa altamente privilegiada.

Vamos repassar esses estágios um por um:

Compromisso Inicial

Para efeitos desta análise, vamos supor que isso já tenha acontecido. O invasor comprometeu a conta de “Shay Katz”, que tem uma atribuição ativa de “Administrador de Helpdesk”.

Captura de tela 1: tela de funções atribuídas a Shay Katz

A tabela a seguir, retirada de Entra IDA página da Web de função integrada do (anteriormente Azure AD) mostra os direitos de redefinição de senha de várias funções dentro Entra ID (anteriormente Azure AD). Podemos ver que o “Administrador do Helpdesk” não pode redefinir as senhas das funções “Administrador de autenticação” e “Administrador de senha”.

Screenshot 2: Entra ID (anteriormente Azure AD) tabela de permissões de redefinição de senha

O invasor agora está logado em Entra ID (anteriormente Azure AD) como o usuário “Shay Katz”.

Descoberta futura de atribuições de funções

Antes da correção da Microsoft, havia duas opções para descobrir futuras atribuições administrativas por menos usuários privilegiados:

1. Através da Entra ID (anteriormente Azure AD), verificando a página “solicitação pendente” para uma futura atribuição de função de um administrador de nível superior.
2. Através de um script, usando o Resource Graph.

a) Permissões necessárias:

Listar solicitações de elegibilidade de função agendadas: Requer: ReadWrite.AzureAD

Uma lista com:

1. DeviceManagementApps.Read.All
2. DeviceManagementApps.ReadWrite.All
3. Diretório.Ler.Todos
4. Diretório.ReadWrite.All
5. Usuário.Ler.Tudo
6. Usuário.ReadBasic.All
7. Usuário.ReadWrite.All

b) Execute a consulta “https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests” para obter a solicitação agendada.
Filtrar por status = 'provisioned' AND scheduleInfo['startDateTime'] > currentTime AND roleDefinitionId em protectedRoleIdList.

c) Execute a consulta “https://graph.microsoft.com/beta/users?$select=displayName,id” para obter o display_name do usuário usando a chave principalId.

Com o Entra ID (anteriormente Azure AD) (opção A), o invasor descobre um exemplo de conta de teste que atualmente não tem atribuições de função “Ativas” ou “Elegíveis”.

Captura de tela 3: conta de 'teste' sem atribuições 'qualificadas' ou 'ativas'

No entanto, os campos “Hora da solicitação” e “Hora de início” nos mostram que esta conta de teste tem uma solicitação pendente para ser adicionada como Administrador Global no futuro.

Captura de tela 4: Solicitação pendente de conta de teste para se tornar Administrador Global

O invasor agora encontrou um alvo digno: uma conta de baixo privilégio com uma atribuição de função futura. Agora podemos passar para a próxima fase.

Resetar a senha

O invasor agora pode redefinir a senha da conta de teste usando o Entra ID (anteriormente Azure AD): portal:

Captura de tela 5: Redefinição de senha para conta de teste

Escalonamento de Privilégios

Missão cumprida. Quando chegar a hora de início definida, a conta de teste será atualizada para uma conta de Administrador Global – e o invasor terá controle total.

Correção da Microsoft

A Microsoft resolveu o problema implementando os seguintes controles:

• Um administrador com poucos privilégios não pode mais ver solicitações pendentes no portal.
• Se você tentar redefinir a senha para uma futura atribuição de função privilegiada, encontrará um erro. (Normalmente, se você não tiver permissão para redefinir uma senha, o botão de redefinição de senha estará bloqueado.)

Conclusão

Conforme declarado, a Microsoft corrigiu esse problema, portanto esta técnica de ataque não é mais eficaz. Deve-se notar, entretanto, que esses tipos de problemas nas salvaguardas de acesso Just-in-Time são conhecidos por atrair invasores. Neste caso, houve uma lacuna entre a atribuição de privilégios e a efetiva ativação de uma medida de segurança criada para protegê-lo. À medida que as empresas se tornam mais orientadas para a nuvem, aumenta o desejo dos agentes de ameaças de procurar tais pontos fracos na infraestrutura de gestão SaaS. Estamos satisfeitos por ter tido esta oportunidade de mitigar uma exposição no superfície de ataque e gostaríamos de agradecer à Microsoft pela sua resposta eficiente e rápida.