macOS Launch/Environment Constraints & Trust Cache
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)
Обмеження запуску в macOS були введені для підвищення безпеки шляхом регулювання того, як, ким і звідки може бути ініційований процес. Введені в macOS Ventura, вони надають структуру, яка категоризує кожен системний бінарний файл у різні категорії обмежень, які визначені в кеші довіри, списку, що містить системні бінарні файли та їх відповідні хеші. Ці обмеження поширюються на кожен виконуваний бінар у системі, що передбачає набір правил, які визначають вимоги для запуску конкретного бінарного файлу. Правила охоплюють самостійні обмеження, які бінарний файл повинен задовольнити, обмеження батьківського процесу, які повинні бути виконані його батьківським процесом, та відповідальні обмеження, які повинні дотримуватися інші відповідні суб'єкти.
Механізм поширюється на сторонні програми через обмеження середовища, починаючи з macOS Sonoma, що дозволяє розробникам захищати свої програми, вказуючи набір ключів і значень для обмежень середовища.
Ви визначаєте обмеження середовища запуску та бібліотеки в словниках обмежень, які ви або зберігаєте в файлах списку властивостей launchd, або в окремих файлах списку властивостей, які ви використовуєте для підписування коду.
Існує 4 типи обмежень:
Самостійні обмеження: Обмеження, що застосовуються до запущеного бінарного файлу.
Батьківський процес: Обмеження, що застосовуються до батька процесу (наприклад, launchd, що запускає службу XP)
Відповідальні обмеження: Обмеження, що застосовуються до процесу, що викликає службу в комунікації XPC
Обмеження завантаження бібліотеки: Використовуйте обмеження завантаження бібліотеки, щоб вибірково описати код, який може бути завантажений
Отже, коли процес намагається запустити інший процес — викликом execve(_:_:_:) або posix_spawn(_:_:_:_:_:_:) — операційна система перевіряє, що виконуваний файл задовольняє своє власне самостійне обмеження. Вона також перевіряє, що виконуваний файл батьківського процесу задовольняє обмеження батька виконуваного файлу, і що виконуваний файл відповідального процесу задовольняє обмеження відповідального процесу виконуваного файлу. Якщо будь-яке з цих обмежень запуску не задовольняється, операційна система не запускає програму.
Якщо під час завантаження бібліотеки будь-яка частина обмеження бібліотеки не є істинною, ваш процес не завантажує бібліотеку.
LC складається з фактів та логічних операцій (і, або..), які поєднують факти.
Факти, які може використовувати LC, задокументовані. Наприклад:
is-init-proc: Логічне значення, яке вказує, чи повинен виконуваний файл бути процесом ініціалізації операційної системи (launchd).
is-sip-protected: Логічне значення, яке вказує, чи повинен виконуваний файл бути файлом, захищеним захистом цілісності системи (SIP).
on-authorized-authapfs-volume: Логічне значення, яке вказує, чи завантажила операційна система виконуваний файл з авторизованого, аутентифікованого обсягу APFS.
on-authorized-authapfs-volume: Логічне значення, яке вказує, чи завантажила операційна система виконуваний файл з авторизованого, аутентифікованого обсягу APFS.
Обсяг Cryptexes
on-system-volume: Логічне значення, яке вказує, чи завантажила операційна система виконуваний файл з поточного завантаженого системного обсягу.
Всередині /System...
...
Коли бінарний файл Apple підписується, він призначає його до категорії LC всередині кешу довіри.
Категорії LC iOS 16 були перевернуті та задокументовані тут.
Поточні категорії LC (macOS 14 - Somona) були перевернуті, і їх описи можна знайти тут.
Наприклад, категорія 1 є:
(on-authorized-authapfs-volume || on-system-volume): Повинен бути в системному або Cryptexes обсязі.
launch-type == 1: Повинен бути системною службою (plist в LaunchDaemons).
validation-category == 1: Виконуваний файл операційної системи.
is-init-proc: Launchd
У вас є більше інформації про це тут, але в основному, вони визначені в AMFI (AppleMobileFileIntegrity), тому вам потрібно завантажити набір для розробки ядра, щоб отримати KEXT. Символи, що починаються з kConstraintCategory, є цікавими. Витягуючи їх, ви отримаєте DER (ASN.1) закодований потік, який вам потрібно буде декодувати за допомогою ASN.1 Decoder або бібліотеки python-asn1 та її скрипта dump.py, andrivet/python-asn1, що надасть вам більш зрозумілий рядок.
Це обмеження запуску, налаштовані в додатках третіх сторін. Розробник може вибрати факти та логічні операнди для використання у своєму додатку, щоб обмежити доступ до нього.
Можливо перерахувати обмеження середовища додатка за допомогою:
В macOS є кілька кешів довіри:
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/BaseSystemTrustCache.img4
/System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/StaticTrustCache.img4
/System/Library/Security/OSLaunchPolicyData
А в iOS, здається, це знаходиться в /usr/standalone/firmware/FUD/StaticTrustCache.img4.
На macOS, що працює на пристроях Apple Silicon, якщо бінарний файл, підписаний Apple, не знаходиться в кеші довіри, AMFI відмовиться його завантажити.
Попередні файли кешу довіри мають формат IMG4 та IM4P, причому IM4P є секцією корисного навантаження формату IMG4.
Ви можете використовувати pyimg4 для витягнення корисного навантаження баз даних:
(Інший варіант - використати інструмент img4tool, який працюватиме навіть на M1, навіть якщо випуск старий, і для x86_64, якщо ви встановите його в правильні місця).
Тепер ви можете використовувати інструмент trustcache, щоб отримати інформацію в читабельному форматі:
Кеш довіри має таку структуру, тому категорія LC є 4-м стовпцем
Тоді ви можете використовувати скрипт, такий як цей, щоб витягти дані.
З цих даних ви можете перевірити програми з значенням обмежень запуску 0, які не мають обмежень (перевірте тут, що означає кожне значення).
Обмеження запуску могли б пом'якшити кілька старих атак, переконавшись, що процес не буде виконуватись в несподіваних умовах: Наприклад, з несподіваних місць або за запитом несподіваного батьківського процесу (якщо тільки launchd не повинен його запускати).
Більше того, обмеження запуску також пом'якшують атаки з пониженням рівня.
Однак вони не пом'якшують загальні зловживання XPC, впровадження коду Electron або впровадження dylib без валідації бібліотек (якщо тільки ідентифікатори команди, які можуть завантажувати бібліотеки, не відомі).
У випуску Sonoma важливим моментом є конфігурація відповідальності служби демонів XPC. Служба XPC відповідає за себе, на відміну від підключеного клієнта, який несе відповідальність. Це задокументовано у звіті зворотного зв'язку FB13206884. Ця конфігурація може здаватися недосконалою, оскільки дозволяє певні взаємодії зі службою XPC:
Запуск служби XPC: Якщо вважати це помилкою, ця конфігурація не дозволяє ініціювати службу XPC через код зловмисника.
Підключення до активної служби: Якщо служба XPC вже працює (можливо, активована її оригінальним додатком), немає перешкод для підключення до неї.
Хоча впровадження обмежень на службу XPC може бути корисним, звужуючи вікно для потенційних атак, це не вирішує основну проблему. Забезпечення безпеки служби XPC вимагає ефективної валідації підключеного клієнта. Це залишається єдиним способом зміцнити безпеку служби. Також варто зазначити, що згадана конфігурація відповідальності наразі діє, що може не відповідати запланованому дизайну.
Навіть якщо вимагається, щоб додаток був відкритий через LaunchService (в обмеженнях батьків). Це можна досягти, використовуючи open (який може встановлювати змінні середовища) або використовуючи API Launch Services (де можуть бути вказані змінні середовища).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
