macOS Gatekeeper / Quarantine / XProtect
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)
Gatekeeper - це функція безпеки, розроблена для операційних систем Mac, призначена для забезпечення того, щоб користувачі використовували лише надійне програмне забезпечення на своїх системах. Вона функціонує шляхом перевірки програмного забезпечення, яке користувач завантажує та намагається відкрити з джерел, що не є App Store, таких як додаток, плагін або пакет установника.
Ключовий механізм Gatekeeper полягає в її процесі перевірки. Вона перевіряє, чи є завантажене програмне забезпечення підписаним визнаним розробником, що забезпечує автентичність програмного забезпечення. Додатково, вона підтверджує, чи є програмне забезпечення нотаризованим Apple, що підтверджує, що воно не містить відомого шкідливого вмісту і не було змінено після нотаризації.
Крім того, Gatekeeper посилює контроль і безпеку користувача, запитуючи користувачів підтвердити відкриття завантаженого програмного забезпечення вперше. Ця запобіжна міра допомагає запобігти випадковому запуску потенційно шкідливого виконуваного коду, який користувач міг помилково прийняти за безпечний файл даних.
Підписи додатків, також відомі як підписи коду, є критично важливим компонентом інфраструктури безпеки Apple. Вони використовуються для перевірки особи автора програмного забезпечення (розробника) та для забезпечення того, що код не був змінений з моменту останнього підписання.
Ось як це працює:
Підписання додатка: Коли розробник готовий розповсюдити свій додаток, він підписує додаток за допомогою приватного ключа. Цей приватний ключ пов'язаний з сертифікатом, який Apple видає розробнику під час реєстрації в програмі Apple Developer Program. Процес підписання включає створення криптографічного хешу всіх частин додатка та шифрування цього хешу за допомогою приватного ключа розробника.
Розповсюдження додатка: Підписаний додаток потім розповсюджується користувачам разом із сертифікатом розробника, який містить відповідний публічний ключ.
Перевірка додатка: Коли користувач завантажує та намагається запустити додаток, його операційна система Mac використовує публічний ключ з сертифіката розробника для розшифрування хешу. Потім вона перераховує хеш на основі поточного стану додатка та порівнює його з розшифрованим хешем. Якщо вони збігаються, це означає, що додаток не був змінений з моменту підписання розробником, і система дозволяє запуск додатка.
Підписи додатків є важливою частиною технології Gatekeeper Apple. Коли користувач намагається відкрити додаток, завантажений з Інтернету, Gatekeeper перевіряє підпис додатка. Якщо він підписаний сертифікатом, виданим Apple відомому розробнику, і код не був змінений, Gatekeeper дозволяє запуск додатка. В іншому випадку, він блокує додаток і сповіщає користувача.
Починаючи з macOS Catalina, Gatekeeper також перевіряє, чи був додаток нотаризований Apple, додаючи додатковий рівень безпеки. Процес нотаризації перевіряє додаток на наявність відомих проблем безпеки та шкідливого коду, і якщо ці перевірки проходять, Apple додає квиток до додатка, який може перевірити Gatekeeper.
При перевірці деяких зразків шкідливого програмного забезпечення ви завжди повинні перевіряти підпис бінарного файлу, оскільки розробник, який його підписав, може вже бути пов'язаний з шкідливим програмним забезпеченням.
Процес нотаризації Apple слугує додатковим захистом для користувачів від потенційно шкідливого програмного забезпечення. Він передбачає, що розробник подає свою програму на перевірку до Служби нотаризації Apple, яку не слід плутати з перевіркою додатків. Ця служба є автоматизованою системою, яка ретельно перевіряє подане програмне забезпечення на наявність шкідливого контенту та будь-які потенційні проблеми з підписуванням коду.
Якщо програмне забезпечення проходить цю перевірку без жодних зауважень, Служба нотаризації генерує квиток нотаризації. Розробник зобов'язаний додати цей квиток до свого програмного забезпечення, процес, відомий як 'стаплінг'. Крім того, квиток нотаризації також публікується в Інтернеті, де Gatekeeper, технологія безпеки Apple, може отримати до нього доступ.
Під час першої установки або виконання програмного забезпечення користувачем, наявність квитка нотаризації - чи то прикріпленого до виконуваного файлу, чи знайденого в Інтернеті - інформує Gatekeeper, що програмне забезпечення було нотаризовано Apple. В результаті Gatekeeper відображає описове повідомлення в початковому діалоговому вікні запуску, вказуючи на те, що програмне забезпечення пройшло перевірки на наявність шкідливого контенту від Apple. Цей процес таким чином підвищує довіру користувачів до безпеки програмного забезпечення, яке вони встановлюють або запускають на своїх системах.
Зверніть увагу, що з версії Sequoia, spctl більше не дозволяє змінювати конфігурацію Gatekeeper.
spctl - це інструмент CLI для перерахунку та взаємодії з Gatekeeper (через демон syspolicyd за допомогою XPC повідомлень). Наприклад, можна побачити статус GateKeeper за допомогою:
Зверніть увагу, що перевірки підпису GateKeeper виконуються лише для файлів з атрибутом Quarantine, а не для кожного файлу.
GateKeeper перевірить, чи може бінарний файл бути виконаний відповідно до налаштувань та підпису:
syspolicyd є основним демон, відповідальним за забезпечення роботи Gatekeeper. Він підтримує базу даних, розташовану в /var/db/SystemPolicy, і ви можете знайти код для підтримки бази даних тут та SQL шаблон тут. Зверніть увагу, що база даних не обмежена SIP і доступна для запису root, а база даних /var/db/.SystemPolicy-default використовується як оригінальна резервна копія на випадок, якщо інша буде пошкоджена.
Більше того, пакунки /var/db/gke.bundle та /var/db/gkopaque.bundle містять файли з правилами, які вставляються в базу даних. Ви можете перевірити цю базу даних як root за допомогою:
syspolicyd також відкриває XPC сервер з різними операціями, такими як assess, update, record та cancel, які також доступні за допомогою Security.framework's SecAssessment* API, а xpctl насправді спілкується з syspolicyd через XPC.
Зверніть увагу, як перше правило закінчується на "App Store", а друге на "Developer ID", і що на попередньому зображенні було увімкнено виконання додатків з App Store та ідентифікованих розробників. Якщо ви зміните це налаштування на App Store, то правила "Notarized Developer ID" зникнуть.
Існує також тисячі правил типу GKE :
Це хеші, які з:
/var/db/SystemPolicyConfiguration/gke.bundle/Contents/Resources/gke.auth
/var/db/gke.bundle/Contents/Resources/gk.db
/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db
Або ви можете перерахувати попередню інформацію за допомогою:
Опції --master-disable та --global-disable команди spctl повністю відключать ці перевірки підписів:
Коли повністю увімкнено, з'явиться нова опція:
Можна перевірити, чи буде додаток дозволено GateKeeper за допомогою:
Можливо додати нові правила в GateKeeper, щоб дозволити виконання певних додатків за допомогою:
Щодо розширень ядра, папка /var/db/SystemPolicyConfiguration містить файли зі списками kext, які дозволено завантажувати. Більше того, spctl має право com.apple.private.iokit.nvram-csr, оскільки він здатний додавати нові попередньо схвалені розширення ядра, які також потрібно зберігати в NVRAM у ключі kext-allowed-teams.
Після завантаження програми або файлу, певні програми macOS, такі як веб-браузери або поштові клієнти, додають розширений атрибут файлу, відомий як "прапор карантину", до завантаженого файлу. Цей атрибут діє як захисний захід, щоб позначити файл як такий, що походить з ненадійного джерела (інтернету) і потенційно несе ризики. Однак не всі програми додають цей атрибут, наприклад, звичайне програмне забезпечення клієнтів BitTorrent зазвичай обходить цей процес.
Наявність прапора карантину сигналізує про функцію безпеки Gatekeeper macOS, коли користувач намагається виконати файл.
У випадку, якщо прапор карантину відсутній (як у випадку з файлами, завантаженими через деякі клієнти BitTorrent), перевірки Gatekeeper можуть не виконуватись. Тому користувачі повинні бути обережними при відкритті файлів, завантажених з менш безпечних або невідомих джерел.
Перевірка дійсності підписів коду є ресурсоємним процесом, який включає в себе генерацію криптографічних хешів коду та всіх його упакованих ресурсів. Крім того, перевірка дійсності сертифіката передбачає проведення онлайн-перевірки на серверах Apple, щоб дізнатися, чи був він відкликаний після його видачі. З цих причин повна перевірка підпису коду та нотаризації є недоцільною для виконання щоразу при запуску програми.
Отже, ці перевірки виконуються лише при виконанні програм з атрибутом карантину.
Цей атрибут повинен бути встановлений програмою, що створює/завантажує файл.
Однак файли, які знаходяться в пісочниці, матимуть цей атрибут, встановлений для кожного файлу, який вони створюють. А непісочні програми можуть встановити його самостійно або вказати ключ LSFileQuarantineEnabled у Info.plist, що змусить систему встановити розширений атрибут com.apple.quarantine на створені файли,
Більше того, всі файли, створені процесом, що викликає qtn_proc_apply_to_self, підлягають карантину. А API qtn_file_apply_to_path додає атрибут карантину до вказаного шляху файлу.
Можна перевірити його статус і увімкнути/вимкнути (потрібні права root) за допомогою:
Ви також можете знайти, чи має файл розширений атрибут карантину за допомогою:
Перевірте значення розширених атрибутів і знайдіть додаток, який записав атрибут карантину за допомогою:
Насправді, процес "може встановити прапори карантину для файлів, які він створює" (я вже намагався застосувати прапор USER_APPROVED у створеному файлі, але він не застосовується):
```c #include #include
enum qtn_flags { QTN_FLAG_DOWNLOAD = 0x0001, QTN_FLAG_SANDBOX = 0x0002, QTN_FLAG_HARD = 0x0004, QTN_FLAG_USER_APPROVED = 0x0040, };
#define qtn_proc_alloc _qtn_proc_alloc #define qtn_proc_apply_to_self _qtn_proc_apply_to_self #define qtn_proc_free _qtn_proc_free #define qtn_proc_init _qtn_proc_init #define qtn_proc_init_with_self _qtn_proc_init_with_self #define qtn_proc_set_flags _qtn_proc_set_flags #define qtn_file_alloc _qtn_file_alloc #define qtn_file_init_with_path _qtn_file_init_with_path #define qtn_file_free _qtn_file_free #define qtn_file_apply_to_path _qtn_file_apply_to_path #define qtn_file_set_flags _qtn_file_set_flags #define qtn_file_get_flags _qtn_file_get_flags #define qtn_proc_set_identifier _qtn_proc_set_identifier
typedef struct _qtn_proc *qtn_proc_t; typedef struct _qtn_file *qtn_file_t;
int qtn_proc_apply_to_self(qtn_proc_t); void qtn_proc_init(qtn_proc_t); int qtn_proc_init_with_self(qtn_proc_t); int qtn_proc_set_flags(qtn_proc_t, uint32_t flags); qtn_proc_t qtn_proc_alloc(); void qtn_proc_free(qtn_proc_t); qtn_file_t qtn_file_alloc(void); void qtn_file_free(qtn_file_t qf); int qtn_file_set_flags(qtn_file_t qf, uint32_t flags); uint32_t qtn_file_get_flags(qtn_file_t qf); int qtn_file_apply_to_path(qtn_file_t qf, const char *path); int qtn_file_init_with_path(qtn_file_t qf, const char path); int qtn_proc_set_identifier(qtn_proc_t qp, const char bundleid);
int main() {
qtn_proc_t qp = qtn_proc_alloc(); qtn_proc_set_identifier(qp, "xyz.hacktricks.qa"); qtn_proc_set_flags(qp, QTN_FLAG_DOWNLOAD | QTN_FLAG_USER_APPROVED); qtn_proc_apply_to_self(qp); qtn_proc_free(qp);
FILE *fp; fp = fopen("thisisquarantined.txt", "w+"); fprintf(fp, "Hello Quarantine\n"); fclose(fp);
return 0;
}
І знайдіть усі файли в карантині за допомогою:
Інформація про карантин також зберігається в центральній базі даних, якою керує LaunchServices у ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2, що дозволяє графічному інтерфейсу отримувати дані про походження файлів. Більше того, це може бути перезаписано додатками, які можуть бути зацікавлені в приховуванні своїх походжень. Крім того, це можна зробити з API LaunchServices.
libquarantine.dylb
Ця бібліотека експортує кілька функцій, які дозволяють маніпулювати полями розширених атрибутів.
API qtn_file_* стосуються політик карантину файлів, API qtn_proc_* застосовуються до процесів (файлів, створених процесом). Неекспортовані функції __qtn_syscall_quarantine* — це ті, що застосовують політики, які викликають mac_syscall з "Quarantine" як першим аргументом, що надсилає запити до Quarantine.kext.
Quarantine.kext
Розширення ядра доступне лише через кеш ядра на системі; однак ви можете завантажити Kernel Debug Kit з https://developer.apple.com/, який міститиме символізовану версію розширення.
Цей Kext буде перехоплювати через MACF кілька викликів, щоб захопити всі події життєвого циклу файлів: створення, відкриття, перейменування, жорстке посилання... навіть setxattr, щоб запобігти встановленню розширеного атрибута com.apple.quarantine.
Він також використовує кілька MIB:
security.mac.qtn.sandbox_enforce: Застосування карантину разом із Sandbox
security.mac.qtn.user_approved_exec: Карантиновані процеси можуть виконувати лише затверджені файли
XProtect — це вбудована антивірусна функція в macOS. XProtect перевіряє будь-який додаток, коли він вперше запускається або модифікується, проти своєї бази даних відомих шкідливих програм і небезпечних типів файлів. Коли ви завантажуєте файл через певні програми, такі як Safari, Mail або Messages, XProtect автоматично сканує файл. Якщо він відповідає будь-якій відомій шкідливій програмі в його базі даних, XProtect запобіжить виконанню файлу і сповістить вас про загрозу.
База даних XProtect регулярно оновлюється Apple новими визначеннями шкідливих програм, і ці оновлення автоматично завантажуються та встановлюються на ваш Mac. Це забезпечує те, що XProtect завжди актуальний з останніми відомими загрозами.
Однак варто зазначити, що XProtect не є повнофункціональним антивірусним рішенням. Він лише перевіряє конкретний список відомих загроз і не виконує сканування при доступі, як більшість антивірусного програмного забезпечення.
Ви можете отримати інформацію про останнє оновлення XProtect, запустивши:
XProtect розташований у захищеному місці SIP за адресою /Library/Apple/System/Library/CoreServices/XProtect.bundle, і всередині пакету ви можете знайти інформацію, яку використовує XProtect:
XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist: Дозволяє коду з цими cdhash'ами використовувати спадкові права.
XProtect.bundle/Contents/Resources/XProtect.meta.plist: Список плагінів і розширень, які заборонено завантажувати через BundleID і TeamID або вказуючи мінімальну версію.
XProtect.bundle/Contents/Resources/XProtect.yara: Правила Yara для виявлення шкідливого ПЗ.
XProtect.bundle/Contents/Resources/gk.db: База даних SQLite3 з хешами заблокованих додатків і TeamIDs.
Зверніть увагу, що є ще один додаток у /Library/Apple/System/Library/CoreServices/XProtect.app, пов'язаний з XProtect, який не бере участі в процесі Gatekeeper.
Зверніть увагу, що Gatekeeper не виконується щоразу, коли ви запускаєте додаток, лише AppleMobileFileIntegrity (AMFI) перевіряє підписи виконуваного коду лише тоді, коли ви запускаєте додаток, який вже був виконаний і перевірений Gatekeeper.
Отже, раніше було можливо виконати додаток, щоб кешувати його з Gatekeeper, а потім модифікувати не виконувані файли додатка (як-от Electron asar або NIB файли), і якщо не було інших захистів, додаток виконувався з шкідливими доповненнями.
Однак тепер це неможливо, оскільки macOS запобігає модифікації файлів всередині пакетів додатків. Тож, якщо ви спробуєте атаку Dirty NIB, ви виявите, що більше не можна її зловживати, оскільки після виконання додатка для кешування з Gatekeeper ви не зможете модифікувати пакет. І якщо ви, наприклад, зміните назву каталогу Contents на NotCon (як вказано в експлойті), а потім виконаєте основний бінарний файл додатка для кешування з Gatekeeper, це викличе помилку і не виконається.
Будь-який спосіб обійти Gatekeeper (змусити користувача завантажити щось і виконати це, коли Gatekeeper повинен це заборонити) вважається вразливістю в macOS. Ось деякі CVE, призначені технікам, які дозволяли обійти Gatekeeper у минулому:
Було помічено, що якщо для розпакування використовується Archive Utility, файли з шляхами, що перевищують 886 символів, не отримують розширену атрибуцію com.apple.quarantine. Ця ситуація ненавмисно дозволяє цим файлам обійти перевірки безпеки Gatekeeper.
Перевірте оригінальний звіт для отримання додаткової інформації.
Коли додаток створюється за допомогою Automator, інформація про те, що йому потрібно для виконання, знаходиться всередині application.app/Contents/document.wflow, а не в виконуваному файлі. Виконуваний файл - це просто загальний бінарний файл Automator, званий Automator Application Stub.
Отже, ви могли б зробити так, щоб application.app/Contents/MacOS/Automator\ Application\ Stub вказував за допомогою символічного посилання на інший Automator Application Stub всередині системи і він виконає те, що знаходиться в document.wflow (ваш скрипт) без спрацьовування Gatekeeper, оскільки фактичний виконуваний файл не має атрибута карантину.
Приклад очікуваного місця: /System/Library/CoreServices/Automator\ Application\ Stub.app/Contents/MacOS/Automator\ Application\ Stub
Перевірте оригінальний звіт для отримання додаткової інформації.
У цьому обході був створений zip-файл з додатком, який починався з компресії з application.app/Contents, а не з application.app. Отже, атрибут карантину був застосований до всіх файлів з application.app/Contents, але не до application.app, що перевіряв Gatekeeper, тому Gatekeeper був обійдений, оскільки коли application.app був запущений, він не мав атрибута карантину.
Check the original report for more information.
Навіть якщо компоненти різні, експлуатація цієї вразливості дуже схожа на попередню. У цьому випадку ми згенеруємо Apple Archive з application.app/Contents, тому application.app не отримає атрибут карантину при розпакуванні за допомогою Archive Utility.
Перевірте оригінальний звіт для отримання додаткової інформації.
ACL writeextattr може бути використаний для запобігання запису атрибута у файл:
Moreover, AppleDouble file format copies a file including its ACEs.
In the source code it's possible to see that the ACL text representation stored inside the xattr called com.apple.acl.text is going to be set as ACL in the decompressed file. So, if you compressed an application into a zip file with AppleDouble file format with an ACL that prevents other xattrs to be written to it... the quarantine xattr wasn't set into de application:
Перегляньте оригінальний звіт для отримання додаткової інформації.
Зверніть увагу, що це також може бути використано з AppleArchives:
Було виявлено, що Google Chrome не встановлював атрибут карантину для завантажених файлів через деякі внутрішні проблеми macOS.
Формати файлів AppleDouble зберігають атрибути файлу в окремому файлі, що починається з ._, це допомагає копіювати атрибути файлів між macOS машинами. Однак було помічено, що після розпакування файлу AppleDouble, файл, що починається з ._, не отримував атрибут карантину.
Можливість створити файл, який не матиме атрибуту карантину, дозволила обійти Gatekeeper. Трюк полягав у тому, щоб створити DMG файл додатку за допомогою конвенції імен AppleDouble (почати з ._) і створити видимий файл як символьне посилання на цей прихований файл без атрибуту карантину.
Коли файл dmg виконується, оскільки він не має атрибуту карантину, він обійде Gatekeeper.
Створіть каталог, що містить додаток.
Додайте uchg до додатку.
Стисніть додаток у файл tar.gz.
Відправте файл tar.gz жертві.
Жертва відкриває файл tar.gz і запускає додаток.
Gatekeeper не перевіряє додаток.
У бандлі ".app", якщо атрибут quarantine xattr не додано, при виконанні Gatekeeper не буде активовано.
Вчіться та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
