macOS SIP

Support HackTricks

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

Захист цілісності системи (SIP) в macOS є механізмом, призначеним для запобігання навіть найбільш привілейованим користувачам вносити несанкціоновані зміни до ключових системних папок. Ця функція відіграє важливу роль у підтримці цілісності системи, обмежуючи дії, такі як додавання, модифікація або видалення файлів у захищених зонах. Основні папки, захищені SIP, включають:

  • /System

  • /bin

  • /sbin

  • /usr

Правила, які регулюють поведінку SIP, визначені в конфігураційному файлі, розташованому за адресою /System/Library/Sandbox/rootless.conf. У цьому файлі шляхи, які починаються з зірочки (*), позначаються як винятки з інакше суворих обмежень SIP.

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

/usr
* /usr/libexec/cups
* /usr/local
* /usr/share/man

Цей фрагмент вказує на те, що хоча SIP зазвичай захищає /usr директорію, є специфічні підкаталоги (/usr/libexec/cups, /usr/local, і /usr/share/man), де зміни дозволені, як вказано зірочкою (*) перед їхніми шляхами.

Щоб перевірити, чи директорія або файл захищені SIP, ви можете використовувати команду ls -lOd для перевірки наявності прапорця restricted або sunlnk. Наприклад:

ls -lOd /usr/libexec/cups
drwxr-xr-x  11 root  wheel  sunlnk 352 May 13 00:29 /usr/libexec/cups

У цьому випадку прапорець sunlnk означає, що каталог /usr/libexec/cups сам по собі не може бути видалений, хоча файли в ньому можуть бути створені, змінені або видалені.

З іншого боку:

ls -lOd /usr/libexec
drwxr-xr-x  338 root  wheel  restricted 10816 May 13 00:29 /usr/libexec

Тут restricted прапорець вказує на те, що директорія /usr/libexec захищена SIP. У директорії, захищеній SIP, файли не можуть бути створені, змінені або видалені.

Більше того, якщо файл містить атрибут com.apple.rootless розширений атрибут, цей файл також буде захищений SIP.

SIP також обмежує інші дії root, такі як:

  • Завантаження ненадійних розширень ядра

  • Отримання task-ports для процесів, підписаних Apple

  • Модифікація змінних NVRAM

  • Дозвіл на налагодження ядра

Опції зберігаються у змінній nvram як бітовий прапорець (csr-active-config на Intel і lp-sip0 читається з завантаженого Device Tree для ARM). Ви можете знайти прапорці в вихідному коді XNU у csr.sh:

Статус SIP

Ви можете перевірити, чи увімкнено SIP на вашій системі, за допомогою наступної команди:

csrutil status

Якщо вам потрібно вимкнути SIP, ви повинні перезавантажити комп'ютер у режимі відновлення (натискаючи Command+R під час запуску), а потім виконати наступну команду:

csrutil disable

Якщо ви хочете зберегти SIP увімкненим, але видалити захисти від налагодження, ви можете зробити це за допомогою:

csrutil enable --without debug

Інші обмеження

  • Забороняє завантаження непідписаних розширень ядра (kexts), забезпечуючи, щоб лише перевірені розширення взаємодіяли з ядром системи.

  • Запобігає налагодженню процесів системи macOS, захищаючи основні компоненти системи від несанкціонованого доступу та модифікації.

  • Гальмує інструменти на кшталт dtrace від перевірки системних процесів, ще більше захищаючи цілісність роботи системи.

Дізнайтеся більше про інформацію SIP у цій доповіді.

Обхід SIP

Обхід SIP дозволяє зловмиснику:

  • Отримати доступ до даних користувача: Читати чутливі дані користувача, такі як електронна пошта, повідомлення та історія Safari з усіх облікових записів користувачів.

  • Обхід TCC: Прямо маніпулювати базою даних TCC (Прозорість, Згода та Контроль), щоб надати несанкціонований доступ до веб-камери, мікрофона та інших ресурсів.

  • Встановити постійність: Розмістити шкідливе ПЗ в захищених SIP місцях, роблячи його стійким до видалення, навіть з правами root. Це також включає можливість підробки Інструменту видалення шкідливого ПЗ (MRT).

  • Завантажувати розширення ядра: Хоча є додаткові запобіжники, обхід SIP спрощує процес завантаження непідписаних розширень ядра.

Пакети установників

Пакети установників, підписані сертифікатом Apple, можуть обійти його захист. Це означає, що навіть пакети, підписані стандартними розробниками, будуть заблоковані, якщо вони намагатимуться змінити каталоги, захищені SIP.

Невідомий файл SIP

Однією з потенційних лазівок є те, що якщо файл вказано в rootless.conf, але наразі не існує, його можна створити. Шкідливе ПЗ може скористатися цим, щоб встановити постійність в системі. Наприклад, шкідлива програма може створити файл .plist у /System/Library/LaunchDaemons, якщо він вказаний у rootless.conf, але не присутній.

com.apple.rootless.install.heritable

Право com.apple.rootless.install.heritable дозволяє обійти SIP

Було виявлено, що можливо поміняти пакет установника після того, як система перевірила його код підпису, і тоді система встановлювала б шкідливий пакет замість оригінального. Оскільки ці дії виконувалися system_installd, це дозволяло обійти SIP.

Якщо пакет було встановлено з змонтованого образу або зовнішнього диска, установник виконував двійковий файл з цього файлового системи (замість захищеного місця SIP), змушуючи system_installd виконувати довільний двійковий файл.

CVE-2021-30892 - Shrootless

Дослідники з цього блогу виявили вразливість у механізмі захисту цілісності системи (SIP) macOS, названу вразливістю 'Shrootless'. Ця вразливість зосереджена навколо демона system_installd, який має право com.apple.rootless.install.heritable, що дозволяє будь-якому з його дочірніх процесів обійти обмеження файлової системи SIP.

Демон system_installd буде встановлювати пакети, які були підписані Apple.

Дослідники виявили, що під час установки пакета, підписаного Apple (.pkg файл), system_installd виконує будь-які скрипти після установки, включені в пакет. Ці скрипти виконуються за допомогою стандартної оболонки, zsh, яка автоматично виконує команди з файлу /etc/zshenv, якщо він існує, навіть у неінтерактивному режимі. Цю поведінку можуть використовувати зловмисники: створивши шкідливий файл /etc/zshenv і чекаючи, поки system_installd викличе zsh, вони можуть виконувати довільні операції на пристрої.

Більше того, було виявлено, що /etc/zshenv може використовуватися як загальна техніка атаки, не лише для обходу SIP. Кожен профіль користувача має файл ~/.zshenv, який поводиться так само, як /etc/zshenv, але не вимагає прав root. Цей файл може використовуватися як механізм постійності, спрацьовуючи щоразу, коли запускається zsh, або як механізм підвищення привілеїв. Якщо адміністратор підвищує привілеї до root, використовуючи sudo -s або sudo <command>, файл ~/.zshenv буде спрацьовувати, ефективно підвищуючи привілеї до root.

У CVE-2022-22583 було виявлено, що той же процес system_installd все ще можна зловживати, оскільки він поміщав скрипт після установки в папку з випадковою назвою, захищену SIP у /tmp. Справа в тому, що /tmp сам по собі не захищений SIP, тому було можливим змонтувати віртуальний образ на ньому, потім установник помістив би туди скрипт після установки, зняв би віртуальний образ, відтворив би всі папки та додав би скрипт після установки з payload для виконання.

Виявлено вразливість, при якій fsck_cs був введений в оману, що призвело до пошкодження важливого файлу, через його здатність слідувати символічним посиланням. Зокрема, зловмисники створили посилання з /dev/diskX на файл /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist. Виконання fsck_cs на /dev/diskX призвело до пошкодження Info.plist. Цілісність цього файлу є важливою для SIP (Захист цілісності системи) операційної системи, яка контролює завантаження розширень ядра. Після пошкодження здатність SIP управляти виключеннями ядра порушується.

Команди для використання цієї вразливості:

ln -s /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist /dev/diskX
fsck_cs /dev/diskX 1>&-
touch /Library/Extensions/
reboot

The exploitation of this vulnerability has severe implications. The Info.plist file, normally responsible for managing permissions for kernel extensions, becomes ineffective. This includes the inability to blacklist certain extensions, such as AppleHWAccess.kext. Consequently, with the SIP's control mechanism out of order, this extension can be loaded, granting unauthorized read and write access to the system's RAM.

Було можливим змонтувати нову файлову систему через захищені папки SIP, щоб обійти захист.

mkdir evil
# Add contento to the folder
hdiutil create -srcfolder evil evil.dmg
hdiutil attach -mountpoint /System/Library/Snadbox/ evil.dmg

Система налаштована на завантаження з вбудованого образу диска установника в Install macOS Sierra.app для оновлення ОС, використовуючи утиліту bless. Використовується наступна команда:

/usr/sbin/bless -setBoot -folder /Volumes/Macintosh HD/macOS Install Data -bootefi /Volumes/Macintosh HD/macOS Install Data/boot.efi -options config="\macOS Install Data\com.apple.Boot" -label macOS Installer

Безпека цього процесу може бути скомпрометована, якщо зловмисник змінює образ оновлення (InstallESD.dmg) перед завантаженням. Стратегія полягає в заміні динамічного завантажувача (dyld) на шкідливу версію (libBaseIA.dylib). Ця заміна призводить до виконання коду зловмисника, коли ініціюється інсталятор.

Код зловмисника отримує контроль під час процесу оновлення, експлуатуючи довіру системи до інсталятора. Атака продовжується шляхом зміни образу InstallESD.dmg за допомогою методу swizzling, особливо націлюючись на метод extractBootBits. Це дозволяє інжектувати шкідливий код перед використанням образу диска.

Більше того, в InstallESD.dmg є BaseSystem.dmg, який слугує кореневою файловою системою коду оновлення. Інжекція динамічної бібліотеки в цей файл дозволяє шкідливому коду працювати в процесі, здатному змінювати файли на рівні ОС, що значно підвищує потенціал для компрометації системи.

У цій доповіді з DEF CON 31 показано, як systemmigrationd (який може обійти SIP) виконує bash та perl скрипти, які можуть бути зловживані через змінні середовища BASH_ENV та PERL5OPT.

CVE-2023-42860

Як детально описано в цьому блозі, скрипт postinstall з пакетів InstallAssistant.pkg дозволяв виконання:

/usr/bin/chflags -h norestricted "${SHARED_SUPPORT_PATH}/SharedSupport.dmg"

and it was possible to create a symlink in ${SHARED_SUPPORT_PATH}/SharedSupport.dmg that would allow a user to unrestrict any file, bypassing SIP protection.

com.apple.rootless.install

The entitlement com.apple.rootless.install allows to bypass SIP

The entitlement com.apple.rootless.install is known to bypass System Integrity Protection (SIP) on macOS. This was notably mentioned in relation to CVE-2022-26712.

In this specific case, the system XPC service located at /System/Library/PrivateFrameworks/ShoveService.framework/Versions/A/XPCServices/SystemShoveService.xpc possesses this entitlement. This allows the related process to circumvent SIP constraints. Furthermore, this service notably presents a method that permits the movement of files without enforcing any security measures.

Sealed System Snapshots

Sealed System Snapshots are a feature introduced by Apple in macOS Big Sur (macOS 11) as a part of its System Integrity Protection (SIP) mechanism to provide an additional layer of security and system stability. They are essentially read-only versions of the system volume.

Here's a more detailed look:

  1. Незмінна система: Sealed System Snapshots роблять об'єм системи macOS "незмінним", що означає, що його не можна змінювати. Це запобігає будь-яким несанкціонованим або випадковим змінам системи, які можуть загрожувати безпеці або стабільності системи.

  2. Оновлення системного програмного забезпечення: Коли ви встановлюєте оновлення або апгрейди macOS, macOS створює новий знімок системи. Об'єм завантаження macOS потім використовує APFS (Apple File System) для переходу на цей новий знімок. Увесь процес застосування оновлень стає безпечнішим і надійнішим, оскільки система завжди може повернутися до попереднього знімка, якщо щось піде не так під час оновлення.

  3. Розділення даних: У поєднанні з концепцією розділення об'ємів даних і системи, введеною в macOS Catalina, функція Sealed System Snapshot забезпечує зберігання всіх ваших даних і налаштувань на окремому об'ємі "Дані". Це розділення робить ваші дані незалежними від системи, що спрощує процес оновлення системи та підвищує безпеку системи.

Пам'ятайте, що ці знімки автоматично керуються macOS і не займають додаткового місця на вашому диску завдяки можливостям спільного використання простору APFS. Також важливо зазначити, що ці знімки відрізняються від знімків Time Machine, які є резервними копіями всієї системи, доступними для користувача.

Check Snapshots

The command diskutil apfs list lists the details of the APFS volumes and their layout:

+-- Container disk3 966B902E-EDBA-4775-B743-CF97A0556A13
|   ====================================================
|   APFS Container Reference:     disk3
|   Size (Capacity Ceiling):      494384795648 B (494.4 GB)
|   Capacity In Use By Volumes:   219214536704 B (219.2 GB) (44.3% used)
|   Capacity Not Allocated:       275170258944 B (275.2 GB) (55.7% free)
|   |
|   +-< Physical Store disk0s2 86D4B7EC-6FA5-4042-93A7-D3766A222EBE
|   |   -----------------------------------------------------------
|   |   APFS Physical Store Disk:   disk0s2
|   |   Size:                       494384795648 B (494.4 GB)
|   |
|   +-> Volume disk3s1 7A27E734-880F-4D91-A703-FB55861D49B7
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk3s1 (System)
|   |   Name:                      Macintosh HD (Case-insensitive)
|   |   Mount Point:               /System/Volumes/Update/mnt1
|   |   Capacity Consumed:         12819210240 B (12.8 GB)
|   |   Sealed:                    Broken
|   |   FileVault:                 Yes (Unlocked)
|   |   Encrypted:                 No
|   |   |
|   |   Snapshot:                  FAA23E0C-791C-43FF-B0E7-0E1C0810AC61
|   |   Snapshot Disk:             disk3s1s1
|   |   Snapshot Mount Point:      /
|   |   Snapshot Sealed:           Yes
[...]
+-> Volume disk3s5 281959B7-07A1-4940-BDDF-6419360F3327
|   ---------------------------------------------------
|   APFS Volume Disk (Role):   disk3s5 (Data)
|   Name:                      Macintosh HD - Data (Case-insensitive)
    |   Mount Point:               /System/Volumes/Data
    |   Capacity Consumed:         412071784448 B (412.1 GB)
    |   Sealed:                    No
|   FileVault:                 Yes (Unlocked)

In the previous output it's possible to see that user-accessible locations are mounted under /System/Volumes/Data.

Moreover, macOS System volume snapshot is mounted in / and it's sealed (cryptographically signed by the OS). So, if SIP is bypassed and modifies it, the OS won't boot anymore.

It's also possible to verify that seal is enabled by running:

csrutil authenticated-root status
Authenticated Root status: enabled

Крім того, знімок диска також змонтовано як тільки для читання:

mount
/dev/disk3s1s1 on / (apfs, sealed, local, read-only, journaled)
Support HackTricks

Last updated