Az - Illicit Consent Grant
OAuth App Phishing
Azure Applications запитують дозволи на доступ до даних користувача (базова інформація, але також доступ до документів, надсилання електронних листів...).
Якщо дозволено, звичайний користувач може надати згоду лише на "Low Impact" permissions. У всіх інших випадках потрібна згода адміністратора.
GA
, ApplicationAdministrator
, CloudApplication
Administrator
та спеціальна роль, що включає permission to grant permissions to applications
, можуть надати згоду на рівні орендаря.
Тільки дозволи, які не потребують згоди адміністратора, класифікуються як low impact. Це дозволи, необхідні для базового входу: openid, profile, email, User.Read та offline_access. Якщо організація дозволяє згоду користувачів для всіх додатків, співробітник може надати згоду додатку на читання вищезазначеного з їх профілю.
Таким чином, зловмисник може підготувати шкідливий додаток і за допомогою фішингу змусити користувача прийняти додаток і вкрасти його дані.
2 Типи Атак Illicit Consent Grant
Unauthenticated: З зовнішнього облікового запису створити додаток з дозволами
User.Read
таUser.ReadBasic.All
, наприклад, фішити користувача, і ви зможете отримати доступ до інформації каталогу.Це вимагає, щоб фішений користувач міг приймати OAuth додатки з зовнішніх середовищ!
Authenticated: Маючи скомпрометований обліковий запис з достатніми привілеями, створити додаток всередині облікового запису і фішити деякого привілейованого користувача, який може прийняти привілейовані OAuth дозволи.
У цьому випадку ви вже можете отримати доступ до інформації каталогу, тому дозвіл
User.ReadBasic.All
більше не цікавий.Вас, ймовірно, цікавлять дозволи, які потребують згоди адміністратора, оскільки звичайний користувач не може надати OAuth додаткам жодного дозволу, тому вам потрібно фішити тільки цих користувачів (докладніше про те, які ролі/дозволи надають цей привілей пізніше)
Перевірка, чи дозволено користувачам надавати згоду
Наступна команда PowerShell використовується для перевірки конфігурації згоди для користувачів в Azure Active Directory (Azure AD) щодо їх здатності надавати згоду додаткам:
Вимкнути згоду користувачів: Ця настройка забороняє користувачам надавати дозволи додаткам. Жодна згода користувачів на додатки не дозволена.
Користувачі можуть надавати згоду додаткам від перевірених видавців або вашої організації, але тільки для дозволів, які ви обираєте: Ця настройка дозволяє всім користувачам надавати згоду тільки додаткам, які опубліковані перевіреним видавцем і зареєстровані у вашому власному орендарі. Вона додає рівень контролю, дозволяючи згоду тільки для конкретних дозволів.
Користувачі можуть надавати згоду всім додаткам: Ця настройка є більш дозволяючою і дозволяє всім користувачам надавати згоду на будь-які дозволи для додатків, якщо ці дозволи не вимагають адміністративної згоди.
Користувацька політика згоди на додатки: Ця настройка вказує на наявність користувацької політики, яка може бути налаштована відповідно до конкретних вимог організації і може включати комбінацію обмежень на основі видавця додатка, дозволів, які запитує додаток, та інших факторів.
Розуміння атаки Illicit Consent Grant
В атаці Illicit Consent Grant зловмисники обманюють кінцевих користувачів, змушуючи їх надавати дозволи шкідливому додатку, зареєстрованому в Azure. Це робиться шляхом створення вигляду, що додаток є легітимним, що призводить до того, що жертви несвідомо натискають кнопку "Прийняти". В результаті, Azure AD видає токен на сайт зловмисника, дозволяючи їм отримувати доступ і маніпулювати даними жертви, такими як читання або відправка електронних листів і доступ до файлів, без необхідності мати організаційний обліковий запис.
Огляд потоку атаки
Атака включає кілька кроків, націлених на загальну компанію. Ось як це може відбуватися:
Реєстрація домену та хостинг додатка: Зловмисник реєструє домен, що нагадує надійний сайт, наприклад, "safedomainlogin.com". Під цим доменом створюється піддомен (наприклад, "companyname.safedomainlogin.com") для хостингу додатка, призначеного для захоплення кодів авторизації та запиту токенів доступу.
Реєстрація додатка в Azure AD: Потім зловмисник реєструє Multi-Tenant Application у своєму Azure AD Tenant, називаючи його на честь цільової компанії, щоб виглядати легітимно. Вони налаштовують Redirect URL додатка, щоб він вказував на піддомен, де розміщено шкідливий додаток.
Налаштування дозволів: Зловмисник налаштовує додаток з різними API дозволами (наприклад,
Mail.Read
,Notes.Read.All
,Files.ReadWrite.All
,User.ReadBasic.All
,User.Read
). Ці дозволи, після надання користувачем, дозволяють зловмиснику отримувати конфіденційну інформацію від імені користувача.Розповсюдження шкідливих посилань: Зловмисник створює посилання, що містить client id шкідливого додатка, і ділиться ним з цільовими користувачами, обманюючи їх на надання згоди.
Використання інструментів для атаки
Атака може бути полегшена за допомогою інструментів, таких як 365-Stealer.
Підготовка до атаки:
Якщо зловмисник має певний рівень доступу до користувача в організації-жертві, вони можуть перевірити, чи дозволяє політика організації користувачеві приймати додатки:
Для виконання атаки, зловмиснику потрібно створити новий App у своєму Azure Tenant (у App registrations), налаштований з дозволами:
User.ReadBasic.All
знаходиться в Microsoft Graph
у Delegated permissions
. (Application permissions завжди потребуватимуть додаткового схвалення).
User.ReadBasic.All
— це дозвіл, який дозволить вам читати інформацію про всіх користувачів в організації, якщо його надано.Пам'ятайте, що лише
GA
,ApplicationAdministrator
,CloudApplication
Administrator
та спеціальна роль, що включаєдозвіл на надання дозволів додаткам
, можуть надати згоду на рівні орендаря. Тому, вам слід фішити користувача з однією з цих ролей, якщо ви хочете, щоб він схвалив App, який потребує згоди адміністратора.
Ви також можете створити App через cli за допомогою:
Перевірте https://www.alteredsecurity.com/post/introduction-to-365-stealer, щоб дізнатися, як налаштувати його.
Зверніть увагу, що отриманий access token буде для graph endpoint з обсягами: User.Read
і User.ReadBasic.All
(запитувані дозволи). Ви не зможете виконувати інші дії (але цього достатньо, щоб завантажити інформацію про всіх користувачів в організації).
Ви також можете використовувати цей інструмент для виконання цієї атаки.
Post-Exploitation
Отримавши доступ до користувача, ви можете робити такі речі, як крадіжка конфіденційних документів і навіть завантаження документів з бекдором.
References
Last updated