Az - Illicit Consent Grant
OAuth App Phishing
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) щодо їх здатності надавати згоду на додатки:
Вимкнення згоди користувачів: Ця настройка забороняє користувачам надавати дозволи додаткам. Ніяка згода користувачів на додатки не дозволяється.
Користувачі можуть надавати згоду на додатки від перевірених видавців або вашої організації, але лише на дозволи, які ви виберете: Ця настройка дозволяє всім користувачам надавати згоду лише на додатки, які опубліковані перевіреним видавцем та додатки, зареєстровані у вашому власному тенанті. Це додає рівень контролю, дозволяючи згоду лише на конкретні дозволи.
Користувачі можуть надавати згоду на всі додатки: Ця настройка є більш ліберальною і дозволяє всім користувачам надавати згоду на будь-які дозволи для додатків, якщо ці дозволи не вимагають адміністративної згоди.
Політика згоди на користувацькі додатки: Ця настройка вказує на те, що існує користувацька політика, яка може бути налаштована відповідно до специфічних вимог організації і може включати комбінацію обмежень на основі видавця додатка, дозволів, які запитує додаток, та інших факторів.
Розуміння атаки з незаконним наданням згоди
В атаці з незаконним наданням згоди зловмисники обманюють кінцевих користувачів, змушуючи їх надавати дозволи шкідливому додатку, зареєстрованому в Azure. Це робиться шляхом створення вигляду легітимності додатку, що призводить до того, що жертви без відома натискають кнопку "Прийняти". В результаті Azure AD видає токен на сайт зловмисника, що дозволяє їм отримувати доступ і маніпулювати даними жертви, такими як читання або надсилання електронних листів і доступ до файлів, без необхідності мати організаційний обліковий запис.
Огляд потоку атаки
Атака включає кілька етапів, націлених на загальну компанію. Ось як це може розвиватися:
Реєстрація домену та хостинг додатка: Зловмисник реєструє домен, що нагадує надійний сайт, наприклад, "safedomainlogin.com". Під цим доменом створюється піддомен (наприклад, "companyname.safedomainlogin.com") для хостингу додатку, призначеного для захоплення кодів авторизації та запиту токенів доступу.
Реєстрація додатку в Azure AD: Зловмисник потім реєструє багатокористувацький додаток у своєму тенанті Azure AD, називаючи його на честь цільової компанії, щоб виглядати легітимно. Вони налаштовують URL-адресу перенаправлення додатку, щоб вона вказувала на піддомен, що хостить шкідливий додаток.
Налаштування дозволів: Зловмисник налаштовує додаток з різними дозволами API (наприклад,
Mail.Read
,Notes.Read.All
,Files.ReadWrite.All
,User.ReadBasic.All
,User.Read
). Ці дозволи, після надання їх користувачем, дозволяють зловмиснику витягувати чутливу інформацію від імені користувача.Розповсюдження шкідливих посилань: Зловмисник створює посилання, що містить ідентифікатор клієнта шкідливого додатку, і ділиться ним з цільовими користувачами, обманюючи їх на надання згоди.
Використання інструментів для атаки
Атака може бути полегшена за допомогою інструментів, таких як 365-Stealer.
Підготовка до атаки:
Якщо зловмисник має певний рівень доступу до користувача в організації жертви, він може перевірити, чи дозволяє політика організації користувачу приймати додатки:
Для виконання атаки зловмиснику потрібно створити новий додаток у своєму Azure Tenant (в реєстраціях додатків), налаштований з такими дозволами:
User.ReadBasic.All
знаходиться в Microsoft Graph
у Делегованих дозволах
. (Дозволи додатка завжди потребуватимуть додаткового схвалення).
User.ReadBasic.All
- це дозвіл, який дозволить вам читати інформацію про всіх користувачів в організації, якщо буде надано.Пам'ятайте, що тільки
GA
,ApplicationAdministrator
,CloudApplication
Administrator
та спеціальна роль, що включаєдозвіл на надання дозволів додаткам
, можуть надати згоду на рівні орендаря. Тому вам слід фішити користувача з однією з цих ролей, якщо ви хочете, щоб він схвалив додаток, який потребує адміністративної згоди.
Ви також можете створити додаток через cli з:
Перевірте https://www.alteredsecurity.com/post/introduction-to-365-stealer, щоб дізнатися, як його налаштувати.
Зверніть увагу, що отриманий access token буде для graph endpoint з правами доступу: User.Read
та User.ReadBasic.All
(запитувані дозволи). Ви не зможете виконувати інші дії (але цього достатньо, щоб завантажити інформацію про всіх користувачів в організації).
Ви також можете використовувати цей інструмент для виконання цієї атаки.
Post-Exploitation
Якщо ви отримали доступ до користувача, ви можете робити такі речі, як крадіжка чутливих документів і навіть завантаження документів з бекдором.
References
Last updated