Az - Device Registration
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Коли пристрій приєднується до AzureAD, у AzureAD створюється новий об'єкт.
При реєстрації пристрою користувача просять увійти зі своїм обліковим записом (запит на MFA, якщо потрібно), потім запитуються токени для служби реєстрації пристроїв і потім з'являється запит на остаточне підтвердження.
Потім у пристрої генеруються дві пари ключів RSA: ключ пристрою (публічний ключ), який надсилається до AzureAD, і транспортний ключ (приватний ключ), який зберігається в TPM, якщо це можливо.
Потім у AzureAD генерується об'єкт (не в Intune), і AzureAD повертає пристрою сертифікат, підписаний ним. Ви можете перевірити, що пристрій приєднано до AzureAD та інформацію про сертифікат (наприклад, чи захищений він TPM).
Після реєстрації пристрою Primary Refresh Token запитується модулем LSASS CloudAP і передається пристрою. Разом з PRT також доставляється ключ сесії, зашифрований так, що тільки пристрій може його розшифрувати (використовуючи відкритий ключ транспортного ключа) і він необхідний для використання PRT.
Для отримання додаткової інформації про те, що таке PRT, перегляньте:
TPM захищає від витоку ключа з витягування з вимкненого пристрою (якщо захищено PIN-кодом) та від витягування приватного матеріалу з рівня ОС. Але він не захищає від перехоплення фізичного з'єднання між TPM і ЦП або використання криптографічного матеріалу в TPM, поки система працює з процесу з правами SYSTEM.
Якщо ви переглянете наступну сторінку, ви побачите, що викрадення PRT може бути використано для доступу як користувач, що чудово, оскільки PRT розташовані на пристроях, тому їх можна вкрасти (або, якщо не вкрадені, зловживати для генерації нових підписних ключів):
Зловмисник міг би запитати токен для служби реєстрації пристроїв Microsoft з скомпрометованого пристрою та зареєструвати його:
Який надасть вам сертифікат, який ви можете використовувати для запиту PRT у майбутньому. Таким чином, підтримуючи постійність і обминаючи MFA, оскільки оригінальний токен PRT, використаний для реєстрації нового пристрою, вже мав дозволи на MFA.
Зверніть увагу, що для виконання цієї атаки вам знадобляться дозволи на реєстрацію нових пристроїв. Також реєстрація пристрою не означає, що пристрій буде дозволено зареєструватися в Intune.
Цю атаку виправили у вересні 2021 року, оскільки ви більше не можете реєструвати нові пристрої, використовуючи токени SSO. Однак все ще можливо легітимно реєструвати пристрої (маючи ім'я користувача, пароль і MFA, якщо потрібно). Перевірте: roadtx.
Було можливим запитати квиток пристрою, перезаписати поточний квиток пристрою, і під час процесу викрасти PRT (тому немає потреби викрадати його з TPM. Для отримання додаткової інформації перевірте цю доповідь.
Однак це було виправлено.
Перевірте оригінальні слайди тут
Резюме атаки:
Можливо перезаписати зареєстрований ключ WHFB з пристрою через SSO
Це обминає захист TPM, оскільки ключ перехоплюється під час генерації нового ключа
Це також забезпечує постійність
Користувачі можуть змінювати свою власну властивість searchableDeviceKey через Azure AD Graph, однак атакуючий повинен мати пристрій у тенанті (зареєстрований на льоту або викрадений сертифікат + ключ з легітимного пристрою) і дійсний токен доступу для AAD Graph.
Тоді можливо згенерувати новий ключ за допомогою:
і потім PATCH інформацію про searchableDeviceKey:
Можливо отримати токен доступу від користувача через фішинг кодом пристрою та зловживати попередніми кроками, щоб викрасти його доступ. Для отримання додаткової інформації перегляньте:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
