Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

macOS xpc_connection_get_audit_token Attack

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Для отримання додаткової інформації перегляньте оригінальний пост: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. Це краткий огляд:

Основна інформація про Mach Messages

Якщо ви не знаєте, що таке Mach Messages, почніть з цієї сторінки:

pagemacOS IPC - Inter Process Communication

На даний момент запам'ятайте, що (визначення звідси): Повідомлення Mach надсилаються через mach port, який є каналом зв'язку одержувача, багатьох відправників, вбудованим у ядро mach. Декілька процесів можуть надсилати повідомлення на mach port, але в будь-який момент лише один процес може читати з нього. Так само, як файлові дескриптори та сокети, mach ports виділяються та керуються ядром, і процеси бачать лише ціле число, яке вони можуть використовувати для вказівки ядру, який з їхніх mach ports вони хочуть використовувати.

Підключення XPC

Якщо ви не знаєте, як встановлюється підключення XPC, перевірте:

pagemacOS XPC

Підсумок уразливості

Важливо знати, що абстракція XPC - це з'єднання один до одного, але вона базується на технології, яка може мати кілька відправників, отже:

  • Mach ports - це одержувач одного, багато відправників.

  • Аудитивний токен з'єднання XPC - це аудитивний токен, скопійований з останнього отриманого повідомлення.

  • Отримання аудитивного токену з'єднання XPC є критичним для багатьох перевірок безпеки.

Хоча попередня ситуація звучить перспективно, є сценарії, де це не викличе проблем (звідси):

  • Аудитивні токени часто використовуються для перевірки авторизації для вирішення прийняття з'єднання. Оскільки це відбувається за допомогою повідомлення на службовий порт, з'єднання ще не встановлено. Додаткові повідомлення на цьому порті будуть просто оброблятися як додаткові запити на з'єднання. Таким чином, перевірки перед прийняттям з'єднання не є вразливими (це також означає, що в межах -listener:shouldAcceptNewConnection: аудитивний токен є безпечним). Тому ми шукаємо з'єднання XPC, які перевіряють конкретні дії.

  • Обробники подій XPC обробляються синхронно. Це означає, що обробник подій для одного повідомлення повинен бути завершений перед його викликом для наступного, навіть на одночасних чергах розподілу. Таким чином, всередині обробника подій XPC аудитивний токен не може бути перезаписаний іншими звичайними (не-відповідь!) повідомленнями.

Два різних методи, як це може бути використано:

  1. Варіант1:

  • Експлойт підключається до служби A та служби B

  • Служба B може викликати привілейовану функціональність в службі A, яку користувач не може

  • Служба A викликає xpc_connection_get_audit_token поки не знаходиться всередині обробника подій для з'єднання в dispatch_async.

  • Таким чином, інше повідомлення може перезаписати аудитивний токен, оскільки воно розсилається асинхронно поза обробником подій.

  • Експлойт передає службі B право НАДСИЛАННЯ службі A.

  • Таким чином, svc B фактично надсилає повідомлення службі A.

  • Експлойт намагається викликати привілейовану дію. У RC svc A перевіряє авторизацію цієї дії, тоді як svc B перезаписав аудитивний токен (надаючи експлойту доступ до виклику привілейованої дії).

  1. Варіант 2:

  • Служба B може викликати привілейовану функціональність в службі A, яку користувач не може

  • Експлойт підключається до служби A, яка надсилає експлойту повідомлення з очікуванням відповіді на конкретний порт відповіді.

  • Експлойт надсилає службі B повідомлення, передаючи цей порт відповіді.

  • Коли служба B відповідає, вона надсилає повідомлення службі A, тоді як експлойт надсилає інше повідомлення службі A, намагаючись досягти привілейованої функціональності та очікує, що відповідь від служби B перезапише аудитивний токен у відповідний момент (Умова гонки).

Варіант 1: виклик xpc_connection_get_audit_token поза обробником подій

Сценарій:

  • Дві служби mach A та B, до яких ми можемо підключитися обома (на основі профілю пісочниці та перевірок авторизації перед прийняттям з'єднання).

  • A повинна мати перевірку авторизації для конкретної дії, яку B може передати (але нашому додатку не вдасться).

  • Наприклад, якщо у B є деякі привілеї або він працює як root, це може дозволити йому попросити A виконати привілейовану дію.

  • Для цієї перевірки авторизації A асинхронно отримує аудитивний токен, наприклад, викликаючи xpc_connection_get_audit_token з dispatch_async.

У цьому випадку зловмисник може спровокувати Умову гонки, створивши експлойт, який просить A виконати дію кілька разів, одночасно змушуючи B надсилати повідомлення A. Коли Умова гонки успішна, аудитивний токен B буде скопійований в пам'ять під час обробки запиту нашим експлойтом A, надаючи йому доступ до привілейованої дії, яку міг запросити лише B.

Це сталося з A як smd та B як diagnosticd. Функцію SMJobBless з smb можна використовувати для встановлення нового привілейованого допоміжного інструменту (як root). Якщо процес, що працює як root, зв'язується з smd, інші перевірки не виконуються.

Отже, служба B - це diagnosticd, оскільки вона працює як root і може бути використана для моніторингу процесу, тому після початку моніторингу вона надсилає кілька повідомлень на секунду.

Для виконання атаки:

  1. Ініціюйте підключення до служби з назвою smd, використовуючи стандартний протокол XPC.

  2. Сформуйте додаткове підключення до diagnosticd. Навпаки, замість створення та надсилання двох нових mach ports, право надсилання клієнтського порту замінюється на копію права надсилання, пов'язаного з підключенням до smd.

  3. В результаті повідомлення XPC можуть бути розсилані до diagnosticd, але відповіді від diagnosticd перенаправляються до smd. Для smd здається, що повідомлення як від користувача, так і від diagnosticd походять з одного з'єднання.

Варіант 2: пересилання відповіді

У середовищі XPC (міжпроцесова комунікація) хоча обробники подій не виконуються одночасно, обробка повідомлень відповіді має унікальну поведінку. Зокрема, існують два відмінних методи для відправлення повідомлень, які очікують відповіді:

  1. xpc_connection_send_message_with_reply: Тут XPC-повідомлення отримується та обробляється на визначеній черзі.

  2. xpc_connection_send_message_with_reply_sync: Навпаки, у цьому методі XPC-повідомлення отримується та обробляється на поточній черзі виклику.

Ця відмінність є критичною, оскільки вона дозволяє можливість одночасного розбору відповідних пакетів з виконанням обробника подій XPC. Зокрема, хоча _xpc_connection_set_creds реалізує блокування для захисту від часткового перезапису аудит-токена, воно не розповсюджує цей захист на весь об'єкт підключення. В результаті цього створюється вразливість, де аудит-токен може бути замінений протягом інтервалу між розбором пакета та виконанням його обробника подій.

Для експлуатації цієї вразливості потрібно наступне налаштування:

  • Два служби mach, позначені як A та B, обидві можуть встановлювати з'єднання.

  • Служба A повинна включати перевірку авторизації для конкретної дії, яку може виконати лише B (додаток користувача не може).

  • Служба A повинна відправити повідомлення, яке очікує відповіді.

  • Користувач може відправити повідомлення до B, на яке він відповість.

Процес експлуатації включає наступні кроки:

  1. Зачекати, поки служба A відправить повідомлення, яке очікує відповіді.

  2. Замість прямої відповіді A, порт відповіді перехоплюється та використовується для відправлення повідомлення службі B.

  3. Подальше відправлення повідомлення, що включає заборонену дію, з очікуванням, що воно буде оброблено одночасно з відповіддю від B.

Нижче наведено візуальне представлення описаного сценарію атаки:

![https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/variant2.png](../../../../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png)

Проблеми виявлення

  • Складнощі у Виявленні Екземплярів: Пошук використання xpc_connection_get_audit_token був складним як статично, так і динамічно.

  • Методологія: Для перехоплення функції xpc_connection_get_audit_token використовувався Frida, фільтруючи виклики, що не походили від обробників подій. Однак цей метод був обмежений до перехопленого процесу та вимагав активного використання.

  • Інструменти Аналізу: Інструменти, такі як IDA/Ghidra, використовувалися для дослідження досяжних служб mach, але процес був часомістким, ускладненим викликами, що включали кеш спільних бібліотек dyld.

  • Обмеження Сценаріїв: Спроби написати скрипт для аналізу викликів xpc_connection_get_audit_token з блоків dispatch_async були ускладнені складностями у розборі блоків та взаємодії з кешем спільних бібліотек dyld.

Виправлення

  • Повідомлені Проблеми: Було надіслано звіт Apple з деталями загальних та конкретних проблем, виявлених у smd.

  • Відповідь Apple: Apple виправила проблему в smd, замінивши xpc_connection_get_audit_token на xpc_dictionary_get_audit_token.

  • Характер Виправлення: Функція xpc_dictionary_get_audit_token вважається безпечною, оскільки вона отримує аудит-токен безпосередньо з mach-повідомлення, пов'язаного з отриманим XPC-повідомленням. Однак вона не є частиною публічного API, подібно до xpc_connection_get_audit_token.

  • Відсутність Ширшого Виправлення: Невідомо, чому Apple не реалізувала більш комплексне виправлення, таке як відкидання повідомлень, які не відповідають збереженому аудит-токену підключення. Можливість легітимних змін аудит-токену в певних сценаріях (наприклад, використання setuid) може бути фактором.

  • Поточний Статус: Проблема залишається в iOS 17 та macOS 14, створюючи виклик для тих, хто намагається ідентифікувати та зрозуміти її.

PreviousmacOS PID ReuseNextmacOS Thread Injection via Task port

Last updated