Az - OAuth Apps Phishing

Reading time: 9 minutes

Phishing de Aplicativos OAuth

Aplicações Azure são configuradas com as permissões que poderão usar quando um usuário consentir a aplicação (como enumerar o diretório, acessar arquivos ou realizar outras ações). Note que a aplicação estará agindo em nome do usuário, então mesmo que o app possa estar pedindo permissões de administração, se o usuário que consente não tiver essa permissão, o app não poderá realizar ações administrativas.

Permissões de consentimento do app

Por padrão, qualquer usuário pode dar consentimento a apps, embora isso possa ser configurado para que os usuários só possam consentir a apps de editores verificados para permissões selecionadas ou até mesmo remover a permissão para que os usuários consintam a aplicações.

Se os usuários não puderem consentir, administradores como GA, Application Administrator ou Cloud Application Administrator podem consentir as aplicações que os usuários poderão usar.

Além disso, se os usuários puderem consentir apenas a apps usando permissões de baixo risco, essas permissões são por padrão openid, profile, email, User.Read e offline_access, embora seja possível adicionar mais a essa lista.

E se eles puderem consentir a todos os apps, poderão consentir a todos os apps.

2 Tipos de ataques

• Não autenticado: A partir de uma conta externa, crie uma aplicação com as permissões de baixo risco User.Read e User.ReadBasic.All, por exemplo, phishing de um usuário, e você poderá acessar informações do diretório.
• Isso requer que o usuário phishing esteja capaz de aceitar apps OAuth de inquilinos externos.
• Se o usuário phishing for um administrador que pode consentir qualquer app com quaisquer permissões, a aplicação também poderá solicitar permissões privilegiadas.
• Autenticado: Tendo comprometido um principal com privilégios suficientes, crie uma aplicação dentro da conta e phishing de algum usuário privilegiado que pode aceitar permissões OAuth privilegiadas.
• Nesse caso, você já pode acessar as informações do diretório, então a permissão User.ReadBasic.All não é mais interessante.
• Você provavelmente está interessado em permissões que requerem um administrador para concedê-las, porque um usuário comum não pode dar permissões a apps OAuth, por isso você precisa phishing apenas aqueles usuários (mais sobre quais papéis/permissões concedem esse privilégio mais tarde).

Usuários podem consentir

Note que você precisa executar este comando a partir de um usuário dentro do inquilino, você não pode encontrar essa configuração de um inquilino externo. O seguinte cli pode ajudá-lo a entender as permissões dos usuários:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"

• Os usuários podem consentir a todos os aplicativos: Se dentro de permissionGrantPoliciesAssigned você encontrar: ManagePermissionGrantsForSelf.microsoft-user-default-legacy então os usuários podem aceitar todos os aplicativos.
• Os usuários podem consentir a aplicativos de editores verificados ou da sua organização, mas apenas para permissões que você selecionar: Se dentro de permissionGrantPoliciesAssigned você encontrar: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team então os usuários podem aceitar todos os aplicativos.
• Desativar o consentimento do usuário: Se dentro de permissionGrantPoliciesAssigned você encontrar apenas: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat e ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team então os usuários não podem consentir nada.

É possível encontrar o significado de cada uma das políticas comentadas em:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"

Administradores de Aplicativos

Verifique os usuários que são considerados administradores de aplicativos (podem aceitar novas aplicações):

# Get list of roles
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles"

# Get Global Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"

# Get Application Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"

# Get Cloud Applications Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"

Visão Geral do Fluxo de Ataque

O ataque envolve várias etapas direcionadas a uma empresa genérica. Veja como pode se desenrolar:

1. Registro de Domínio e Hospedagem de Aplicação: O atacante registra um domínio que se assemelha a um site confiável, por exemplo, "safedomainlogin.com". Sob este domínio, um subdomínio é criado (por exemplo, "companyname.safedomainlogin.com") para hospedar uma aplicação projetada para capturar códigos de autorização e solicitar tokens de acesso.
2. Registro da Aplicação no Azure AD: O atacante então registra uma Aplicação Multi-Tenant em seu Tenant do Azure AD, nomeando-a após a empresa alvo para parecer legítima. Eles configuram a URL de Redirecionamento da aplicação para apontar para o subdomínio que hospeda a aplicação maliciosa.
3. Configuração de Permissões: O atacante configura a aplicação com várias permissões de API (por exemplo, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Essas permissões, uma vez concedidas pelo usuário, permitem que o atacante extraia informações sensíveis em nome do usuário.
4. Distribuição de Links Maliciosos: O atacante cria um link contendo o id do cliente da aplicação maliciosa e o compartilha com usuários alvo, enganando-os para conceder consentimento.

Exemplo de Ataque

1. Registre uma nova aplicação. Pode ser apenas para o diretório atual se você estiver usando um usuário do diretório atacado ou para qualquer diretório se este for um ataque externo (como na imagem a seguir).
2. Também defina a URI de redirecionamento para a URL esperada onde você deseja receber o código para obter tokens (http://localhost:8000/callback por padrão).

2. Em seguida, crie um segredo da aplicação:

3. Selecione permissões de API (por exemplo, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)

4. Execute a página da web (azure_oauth_phishing_example) que solicita as permissões:

# From https://github.com/carlospolop/azure_oauth_phishing_example
python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client-id <client-id> --scopes "email,Files.ReadWrite.All,Mail.Read,Notes.Read.All,offline_access,openid,profile,User.Read"

5. Envie a URL para a vítima
6. Neste caso http://localhost:8000
7. As vítimas precisam aceitar o aviso:

7. Use o token de acesso para acessar as permissões solicitadas:

export ACCESS_TOKEN=<ACCESS_TOKEN>

# List drive files
curl -X GET \
https://graph.microsoft.com/v1.0/me/drive/root/children \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List eails
curl -X GET \
https://graph.microsoft.com/v1.0/me/messages \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List notes
curl -X GET \
https://graph.microsoft.com/v1.0/me/onenote/notebooks \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

Outras Ferramentas

• 365-Stealer: Confira https://www.alteredsecurity.com/post/introduction-to-365-stealer para aprender como configurá-lo.
• O365-Attack-Toolkit

Pós-Exploração

Phishing Pós-Exploração

Dependendo das permissões solicitadas, você pode ser capaz de acessar diferentes dados do locatário (listar usuários, grupos... ou até mesmo modificar configurações) e informações do usuário (arquivos, notas, e-mails...). Então, você pode usar essas permissões para realizar essas ações.

Admin de Aplicações do Entra ID

Se você conseguiu comprometer de alguma forma um principal do Entra ID que pode gerenciar Aplicações no Entra ID, e há aplicações que estão sendo usadas por usuários do locatário. Um administrador poderia modificar as permissões que o aplicativo está solicitando e adicionar um novo endereço de redirecionamento permitido para roubar os tokens.

• Note que é possível adicionar URIs de redirecionamento (não é necessário excluir a real) e então enviar um link HTTP usando a URI de redirecionamento do atacante, para que quando o usuário seguir o link, a autenticação ocorra automaticamente e o atacante receba o token.
• Também é possível alterar as permissões que o aplicativo solicita para obter mais permissões dos usuários, mas nesse caso o usuário precisará aceitar novamente o prompt (mesmo que já estivesse logado).
• Para realizar esse ataque, o atacante NÃO PRECISA controlar o código do aplicativo, pois ele poderia apenas enviar o link para login no aplicativo para o usuário com a nova URL no parâmetro redirect_uri.

Pós Exploração de Aplicações

Verifique as seções de Aplicações e Principal de Serviço da página:

Az - EntraID Privesc

Referências

• https://www.alteredsecurity.com/post/introduction-to-365-stealer
• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/