Eric Woodruff Investigador de segurança sénior

Este artigo detalha uma série de descobertas da equipe de pesquisa de segurança da Semperis que resultaram na capacidade de executar ações no Entra ID além dos controles de autorização esperados, com base na análise do escopo (permissões) do OAuth 2.0. A nossa descoberta mais preocupante envolveu a capacidade de adicionar e remover utilizadores de funções privilegiadas, incluindo a função mais poderosa no Entra ID: Administrador Global. Comunicámos as nossas descobertas ao Centro de Resposta de Segurança da Microsoft (MSRC) e trabalhámos com a Microsoft para garantir que estas descobertas foram resolvidas.

Embora não se saiba se alguma organização foi comprometida anteriormente por meio dessa descoberta, um agente de ameaças poderia ter usado esse acesso para realizar a elevação de privilégios para Administrador Global e instalar outros meios de persistência em um locatário. Um atacante também poderia usar esse acesso para realizar movimento lateral em qualquer sistema no Microsoft 365 ou Azure, bem como em qualquer aplicativo SaaS conectado ao Entra ID.

A descoberta exige que o iniciador tenha a função Administrador de aplicativos ou Administrador de aplicativos em nuvem no Entra ID, que é considerada privilegiada. Em muitas empresas, a infeliz realidade é que os utilizadores a quem são atribuídas estas funções não são tratados como privilegiados, o que os torna alvos privilegiados para um atacante.

As organizações preocupadas devem saber como detetar se as suas aplicações Microsoft podem ter sido visadas, conforme documentado mais adiante neste artigo.

Manual de integração de aplicações

Para compreender este vetor de ataque, é necessário compreender os componentes fundamentais envolvidos.

Os clientes do Microsoft 365 e do Azure podem estar familiarizados com os sistemas e serviços com os quais interagem, incluindo o Microsoft Teams, o SharePoint Online, o Exchange Online, o Azure Key Vault e os portais de administração, como o portal do Azure e o Centro de Administração do Microsoft 365, e o conjunto de outros serviços da Microsoft. O que pode não ser do seu conhecimento são as centenas de aplicações Microsoft que mantêm o seu património Microsoft a funcionar. Fora da própria Microsoft, estas aplicações podem ser referidas como aplicações originais porque não são fornecidas por um ISV de terceiros.

Entra ID é a plataforma de identidade e o mecanismo de autorização de todos os ambientes do Microsoft 365 e do Azure. Os clientes que federam a autenticação para Okta, Ping Identity ou outros provedores de identidade com serviços da Microsoft ainda devem gerenciar o modelo de autorização que existe em sua propriedade da Microsoft. O Entra ID é o mecanismo de autorização subjacente que permite que esses aplicativos da Microsoft interajam e operem uns com os outros, usando os padrões do setor para autenticação e autorização modernas: OpenID Connect e OAuth 2.0.

Cada cliente Microsoft tem o seu próprio inquilino Entra (anteriormente conhecido como Azure AD). Em cada inquilino, cada aplicação Microsoft é representada por um objeto de entidade de segurança conhecido como entidade de serviço. Os utilizadores e os grupos são entidades de segurança com as quais estamos mais familiarizados; pode atribuir funções e permissões a estas entidades. Tal como os utilizadores e grupos, as funções e permissões podem ser atribuídas a aplicações através das suas entidades de serviço. Essas funções e permissões são avaliadas ao interagir com o Entra ID ou outros serviços do Microsoft 365.

Aplicações multitenant em Entra ID

A Entra ID normalmente considera todos os aplicativos Microsoft, mesmo aqueles que possuem propriedades exclusivas, como aplicativos multilocatários.

Com aplicativos multilocatário, o desenvolvedor define como o aplicativo deve operar no registro do aplicativo. Isso inclui ações como a definição das permissões da API do Microsoft Graph que o aplicativo precisa, bem como a credencial usada pelo aplicativo para acessar o Microsoft Graph. O Microsoft Graph é o ponto de extremidade da API unificada para vários serviços da Microsoft, incluindo o Entra ID.

Quando uma organização consome uma aplicação multilocatário, a aplicação é representada no locatário consumidor por uma entidade de serviço(Figura 1).

Figura 1. Exemplo de registo de uma aplicação e da sua relação com o serviço principal.

O caso das credenciais múltiplas

O Entra ID permite a atribuição e utilização de dois tipos de credenciais para autenticação: segredos (palavras-passe) e chaves (certificados). Qualquer um dos tipos de credenciais funcionou no contexto da nossa descoberta. De agora em diante, referir-me-ei coletivamente a segredos e chaves simplesmente como credenciais.

O que se torna interessante é que o Entra ID permite o armazenamento de credenciais em dois locais: no registo da aplicação (que, como mencionado, o programador gere) e na entidade de serviço. No caso de aplicações multilocatário, a entidade de serviço está no locatário do cliente e sob controlo do cliente, que pode então atribuir credenciais à entidade de serviço(Figura 2).

Figura 2. Diagrama que mostra que o inquilino Fabrikam definiu uma credencial na entidade de serviço.

Para proteger contra a atribuição ou o uso de segredos em entidades de serviço, os desenvolvedores de aplicativos podem usar um mecanismo no Entra ID chamado bloqueio de propriedade de instância de aplicativo. A partir de nossa pesquisa e discussão com a Microsoft, a Microsoft utiliza um mecanismo diferente que pode fornecer o mesmo resultado final: não permitir a autenticação usando uma credencial em uma entidade de serviço.

Quer uma credencial seja atribuída a um registo de aplicação ou a uma entidade de serviço, ambas podem ser utilizadas para executar um fluxo de concessão de credenciais de cliente OAuth 2.0 para atuar como essa aplicação no Microsoft Graph(Figura 3).

Figura 3. Fluxo de concessão de credenciais de cliente OAuth 2.0 no Entra ID.

Durante um fluxo de concessão de credenciais de cliente, ocorrem as seguintes etapas:

  1. A aplicação utiliza a sua ID de cliente e credencial para se autenticar na Entra ID. Um aplicativo é efetivamente qualquer coisa que conheça o ID do cliente, o ID do locatário e a credencial. Assim, para efeitos deste abuso, embora a aplicação nomeada possa ser uma aplicação Microsoft, a aplicação que actua é o atacante.
  2. A Entra ID valida a ID e a credencial do cliente e responde com um token de acesso.
  3. A aplicação solicita dados do Microsoft Graph, passando o token.
  4. O Microsoft Graph valida o token de acesso.
  5. Se o token for válido, o Microsoft Graph fornecerá os dados ou a ação solicitados.

Para mais informações sobre este fluxo, consulte a documentação da Microsoft "Plataforma de identidade da Microsoft e o fluxo de credenciais de cliente OAuth 2.0".

Como o Microsoft Graph é uma API REST, ações como GET podem ser usadas para solicitar dados do Entra ID, e ações como POST e PATCH podem ser usadas para criar ou modificar dados no Entra ID.

Se um aplicativo tiver a permissão de aplicativo Group.Create atribuída a ele e você tiver a credencial para esse aplicativo, poderá criar um grupo, e os logs de auditoria do Entra ID mostrarão que o grupo foi criado pelo principal de serviço para esse aplicativo.

Como exemplo, suponha que você tenha um aplicativo de terceiros chamado Aplicativo Personalizado, que você usa para acessar o Microsoft Graph por meio do SDK do PowerShell do Microsoft Graph. As credenciais que são passadas como $creds contêm o ID do aplicativo e a credencial(Figura 4).

Figura 4. Conexão com o Microsoft Graph como aplicativo personalizado.

Se você executasse ações usando permissões consentidas para este aplicativo - neste caso, Group.Create - essasações aparecem nos logs de auditoria do Entra ID como sendo executadas pelo aplicativo. Como pode ser visto na Figura 5, o aplicativo é a entidade de segurança responsável pela operação "Adicionar grupo".

Figura 5. Resultados da criação de um grupo como Aplicação personalizada.

Atuar como aplicações Microsoft

No Entra ID, a Microsoft historicamente permitiu que os clientes atribuíssem credenciais a quase todas as entidades de serviço de aplicativo da Microsoft. Em instâncias limitadas, essas credenciais podem ser usadas em fluxos de concessão de credenciais de cliente OAuth 2.0 para acessar o Microsoft Graph, atuando como o aplicativo Microsoft dentro do próprio locatário do cliente.

Tal como na aplicação personalizada do exemplo anterior, atribuímos uma credencial à entidade de serviço para a aplicação Microsoft Device Registration Service. Conseguimos então autenticar e aceder ao Microsoft Graph como Device Registration Service(Figura 6).

Figura 6. Ligação ao Microsoft Graph como serviço de registo de dispositivos.

Elevação de privilégios através de aplicações Microsoft

Através da nossa investigação, descobrimos que determinadas entidades de serviços de aplicações da Microsoft tinham permissão para executar determinadas acções que não estavam definidas na lista de permissões autorizadas. Ou seja, fomos autorizados a executar determinadas acções privilegiadas, apesar de não parecermos ter permissão para o fazer.

No Microsoft Graph, as permissões disponíveis podem ser determinadas examinando os escoposatribuídos - otermo OAuth 2.0 para permissões.

Em nosso exemplo mostrado na Figura 6, você pode ver que os escopos estão vazios para o Serviço de Registro de Dispositivo (Figura 7). Isso deve significar que esse aplicativo não tem permissão para fazer nada por meio da API do Graph, e deveríamos ter recebido uma resposta 403 não autorizada ao tentar uma ação não autorizada.

Figura 7. Os nossos âmbitos de aplicação vazios (permissões) para o serviço de registo de dispositivos.

No entanto, quando tentámos executar determinadas acções privilegiadas, conseguimos fazê-lo. Neste exemplo, a Figura 8 e a Figura 9 mostram uma tentativa bem sucedida de adicionar um utilizador à função de Administrador Global como Serviço de Registo de Dispositivos.

Figura 8. Adição de um utilizador à função de Administrador Global como Serviço de Registo de Dispositivos.
Figura 9. Resultados do registo de auditoria do Entra ID que mostram uma gestão de funções bem sucedida.

As nossas conclusões

Através da nossa investigação, descobrimos as seguintes capacidades para cada um dos serviços especificados. O âmbito do impacto está dentro do inquilino Entra visado.

Viva Engage (Yammer)

A capacidade de eliminar e eliminar permanentemente utilizadores, incluindo utilizadores privilegiados como os Administradores Globais. O MSRC classificou esta capacidade como uma vulnerabilidade de gravidade média.

Serviço de Gestão de Direitos Microsoft

A capacidade de criar utilizadores. O MSRC classificou esta capacidade como de baixa gravidade. A explicação para a baixa gravidade deveu-se ao facto de os objectos de utilizador criados não serem privilegiados.

Serviço de registo de dispositivos

A capacidade de modificar a associação de funções privilegiadas, incluindo a função de Administrador Global. O MSRC classificou esta capacidade como de gravidade importante, elevação de privilégios em Identidade (Entra ID).

Utilizar o mecanismo de elevação e persistência de privilégios

Todas as nossas descobertas são preocupantes na medida em que contornam controlos de autorização conhecidos. No entanto, a descoberta do Device Registration Service é o ponto focal para a elevação de privilégios e potencial persistência de um atacante.

Em um locatário Entra, os Administradores de aplicativos, Administradores de aplicativos em nuvem, Administradores globais e usuários atribuídos como Proprietário de um aplicativo podem atribuir credenciais ao principal do serviço.

O Administrador de aplicativos e o Administrador de aplicativos de nuvem são considerados funções privilegiadas pela Microsoft, conforme observado em sua documentação "Funções internas do Microsoft Entra". Em muitas empresas, as integrações de aplicativos de terceiros podem fornecer outros caminhos de elevação de privilégios e abuso se um Administrador de aplicativos ou Administrador de aplicativos em nuvem for comprometido, independentemente de a organização estar ou não ciente de que está configurando esses caminhos.

No entanto, em um locatário Entra greenfield (novo), nem o Administrador de aplicativos nem o Administrador de aplicativos em nuvem têm os direitos em um locatário Entra para gerenciar a atribuição de funções privilegiadas.

Também é importante observar que essas funções não têm a capacidade de consentir com as permissões da API do Microsoft Graph, o que é um mal-entendido comum por aqueles que trabalham no Entra ID.

Se um atacante ciente da falha no Serviço de Registo de Dispositivos comprometesse um utilizador a quem fosse atribuída a função de Administrador de Aplicações ou de Administrador de Aplicações na Nuvem, o atacante poderia utilizar esse acesso para ganhar uma posição na função de Administrador Global ou em qualquer outra função desejada.

Embora possa parecer um pouco rudimentar para um atacante persistir com a função de Administrador Global, a persistência pode ser instalada com estes privilégios criando um novo registo de aplicação e uma entidade de serviço com permissões de aplicação privilegiadas. Da mesma forma, um atacante poderia instalar novas permissões de aplicação privilegiadas numa aplicação de inquilino único existente ou encontrar uma aplicação privilegiada existente e instalar credenciais adicionais. As organizações que não estão a monitorizar continuamente este tipo de alterações e que não têm a maturidade necessária para determinar operações conhecidas de operações maliciosas na Entra ID provavelmente não teriam conhecimento da instalação de acesso persistente ou da modificação temporária da atribuição de funções na Entra ID.

A correção e o elo perdido escondido

Agradecemos as conversas que tivemos com o MSRC e a equipa do Microsoft Identity durante a resolução das nossas descobertas. A nossa preocupação prendeu-se principalmente com a falta de âmbito (permissão) no nosso acesso ao Microsoft Graph.

Durante a nossa conversa, a Microsoft referiu que tem outros mecanismos de autorização que existem nos bastidores das aplicações Microsoft. Estes mecanismos permitiram-nos executar as acções descritas neste artigo.

A Microsoft salientou, com razão, que esta capacidade não constitui, por conseguinte, uma falha material em nenhum dos seus modelos de autorização. No entanto, reconheceu que externamente, com base no que podemos ver e ter acesso, as capacidades podem parecer estar erradas. Externamente à Microsoft, os âmbitos do OAuth 2.0 são absolutos quando se interage com o Microsoft Graph, pelo que, sem conhecimento de outros sistemas de autorização, apenas podemos inferir.

Além disso, a nossa investigação resultou em muitas alterações por parte da Microsoft, restringindo ainda mais a capacidade de utilizar credenciais em aplicações Microsoft. A Microsoft tem vindo a implementar controlos que restringem a capacidade de utilizar credenciais em entidades de serviço. Observámos que a lista de entidades de serviço como as quais podemos autenticar tem vindo a diminuir continuamente

Quando tentamos agora autenticar como Serviço de Registo de Dispositivos, recebemos um erro do Microsoft Graph(Figura 10).

Figura 10. Falha na autenticação como Serviço de Registo de Dispositivos.

Deteção de abusos anteriores

É provável que as aplicações que estão no centro das nossas descobertas existam na maioria das propriedades dos clientes da Microsoft. Temos a forte convicção de que esta falha existe pelo menos há tanto tempo como estas aplicações, o que remonta a vários anos.

Os dois métodos de deteção deste abuso são os registos de auditoria do Entra ID e as credenciais persistentes nas aplicações abusadas. Infelizmente, ambos os métodos têm seus limites. Os registos de auditoria fornecem valor apenas durante o tempo em que são retidos, e um atacante poderia ter removido a credencial nas aplicações iniciais abusadas depois de instalar mais persistência.

Se uma organização encontrar dados que indiquem que foram atribuídas credenciais ao Serviço de Registo de Dispositivos ou descobrir dados de auditoria para o Serviço de Registo de Dispositivos, deve ter um elevado nível de preocupação. Não conhecemos nenhuma razão válida para que o Serviço de Registo de Dispositivos tenha uma credencial atribuída.

Credenciais persistentes

Pode utilizar o Microsoft Graph para inspecionar as entidades de serviço afectadas, para que possa determinar se foram adicionadas credenciais adicionais às mesmas.

Para essas consultas do Graph, inspecione a saída para determinar se os valores foram definidos ou se a credencial é retornada como nula.

O ID do aplicativo é um valor globalmente exclusivo. Esses comandos do PowerShell e a consulta do Microsoft Graph funcionarão em qualquer locatário Entra.

Serviço de registo de dispositivos

SDK do Microsoft Graph PowerShell

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").KeyCredentials).count

((Get-MGServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'").PasswordCredentials).count

Consulta do Microsoft Graph

https://graph.microsoft.com/v1.0/servicePrincipals(appId='01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9')?$select=keyCredentials,passwordCredentials

Entradas do registo de auditoria

As organizações podem examinar os dados do registo de auditoria do Entra ID que correspondem a determinados padrões. Note que a capacidade de pesquisar dados de registo de auditoria só será viável desde que a organização tenha armazenado esses registos.

Procura de acções pelo serviço de registo de dispositivos

AuditLogs

| where parse_json(tostring(InitiatedBy.app)).displayName == "Device Registration Service"

Caça à atribuição de segredos ao serviço de registo de dispositivos

AuditLogs

| where OperationName == "Add service principal credentials"

| where TargetResources[0].displayName == " Device Registration Service"

Proteger os clientes da Semperis

Para os utilizadores do Semperis Directory Services Protector ( DSP) ou Purple Knightestamos a lançar um indicador de segurança, Credenciais suspeitas na entidade de serviço da Microsoft, que irá verificar e comunicar as credenciais atribuídas aos Serviços de Registo de Dispositivos e ao Viva Engage. Numa abordagem à segurança da identidade em camadas, as organizações podem também verificar os seus registos de auditoria SIEM em busca de marcadores.

Impedir ataques que visem aplicações privilegiadas

As aplicações privilegiadas e os seus mandantes de serviço na Entra ID são um dos meios mais comuns que os atacantes têm para se instalarem e manterem a persistência na Entra ID e para se deslocarem para outras propriedades na nuvem, como o Microsoft 365, o Azure e as aplicações multicloud e SaaS que se integram na Entra ID.

Uma das melhores defesas que as organizações podem adotar é garantir que o Administrador de Aplicações e o Administrador de Aplicações na Nuvem são tratados como altamente privilegiados como os Administradores Globais, e que as melhores práticas como a separação de privilégios, estações de trabalho de acesso privilegiado e autenticação forte resistente a phishing são tratadas como requisitos e não como opções.

Investigação relacionada e agradecimentos

A pesquisa no espaço de aplicativos Entra ID e diretores de serviço não é um conceito novo. Nossa pesquisa se sobrepõe a uma pesquisa semelhante de 2019 por Dirk-jan Mollema, que explorou a atribuição de credenciais a entidades de serviço e o aproveitamento de permissões de aplicativo OAuth 2.0 para executar funções que um administrador de aplicativo não deve ser capaz de executar. Desde então, a lista de aplicações que podem ser utilizadas diminuiu e foi ainda mais reduzida em julho de 2024 como resultado da resposta da Microsoft às nossas descobertas.

Divulgação e calendário

As descobertas descritas neste post foram comunicadas ao MSRC conforme documentado na seguinte cronologia. Como se trata de uma descoberta complexa, foi necessário algum tempo para analisar as descobertas com o MSRC. Apreciamos a rapidez com que a descoberta do Serviço de Registo de Dispositivos foi resolvida e o empenho da Microsoft em proteger ainda mais as suas aplicações com base no nosso trabalho de colaboração.

  • 11 de janeiro de 2024: Criação dos casos MSRC
  • 30 de janeiro de 2024: A MSRC deu uma resposta inicial de baixa gravidade
  • 6 de fevereiro de 2024: Resposta fornecida à MSRC relativamente à atribuição de gravidade
  • 4 de março de 2024: Serviço de Registo de Dispositivos reclassificado como de gravidade importante
  • 4 de março de 2024: Viva Engage classificado como de baixa gravidade
  • 4 de março de 2024: Serviços de Gestão de Direitos da Microsoft classificados como de baixa gravidade
  • 4 de março de 2024: Caso do Microsoft Rights Management Services resolvido e encerrado
  • 4 de março de 2024: Caso do Serviço de Registo de Dispositivos resolvido e encerrado
  • 1 de abril de 2024: Viva Engage reclassificado como de gravidade média
  • 17 de abril de 2024: Forneceu uma notificação inicial à MSRC relativamente à divulgação
  • 19 de abril de 2024: Caso Viva Engage resolvido e encerrado
  • 5 de junho de 2024: Envio do projeto de artigo de divulgação ao MSRC
  • 13 de junho de 2024: Reunião com o MSRC sobre casos e divulgação
  • 7 de agosto de 2024: Divulgação pública