Джейлбрейк evasi0n: Як він працює?

4 лютого - день, коли з'явився джейлбрейк iOS 6. Зараз вже всі, хто хотів, «звільнили» свої пристрої, і ейфорія потроху почала зникати... Саме час перейти до технічної частини! У чому ж полягає принцип роботи evasi0n? Розглянемо його в деталях.

Утиліта хакерської групи evad3rs відрізняється тим, що повністю працює на рівні файлової системи пристрою. Вона не вимагає навмисної псування пам'яті, щоб отримати адміністративний доступ. Можливо, його назвали evasi0n, що в перекладі означає «уникнення», оскільки він уникає всі захисні механізми, вбудовані в систему, замість того, щоб атакувати їх прямо в лоб.

evasi0n працює в три етапи, які ми розповімо нижче. Всі етапи використовують ту функціональність апарату, яка надається MobileBackup - сервісом, що використовується для створення та відновлення резервних копій пристрою. Оскільки резервні копії створюються з користувальницького девайса і повинні бути перенесені, то їх не так то просто криптографічно підписати, адже, по суті, вони не можуть вважатися достовірними даними.

MobileBackup використовує загальний ідентифікатор типу MediaDomain, який вказує на фіксоване місце на пристрої, і відносний шлях, щоб ідентифікувати кожен файл резервної копії. Статичний абсолютний шлях (тобто, від кореня диска - прим.) ідентифікатора, з'єднаний з відносним шляхом до файлу, дає абсолютний шлях до восстанавливаемому на пристрої файлу. evasi0n створює свої файли в MediaDomain, всі файли якого лежать в /var/mobile/Media.

Під час першого етапу evasi0n створює свіжу резервну копію для відновлення на пристрої, що містить тільки такі файли (всі вони зберігаються в MediaDomain).

Символьне посилання в каталозі .haxx to /var/mobile створена для того, щоб обійти традиційні обмеження шляху MobileBackup. Як правило, файли MediaDomain повинні розташовуватися в директорії /var/mobile/Media. Проте коли символьне посилання створюється, будь-який файл, який знаходиться в .haxx, відновлюється у in /var/mobile. Дана методика також використовувалась у попередніх джейлбрейках.

Делее в /var/mobile створюється додаток iOS під назвою DemoApp.app, доповнене іконками та іншими атрибутами. Plist com.apple.mobile.installation.plist оновлюється таким чином, що Springboard знає, де розташовується це додаток, і може відображати його на головному екрані.

Однак, на відміну від звичайного програми iOS, виконуваний код цього додатка досить незвичайний і виглядає наступним чином:

Для тих, хто знайомий зі скриптами оболонок UNIX, ядро дивиться на перший рядок тексту, щоб визначити інтерпретатор скрипта. Зміст файлу вище повідомляє ядру завдання на виконання launchctl з цими конкретними аргументами. Крім того, Plist com.apple.mobile.installation.plist містить спеціальний розділ для DemoApp.app, що визначає середу змінних оточення, яку потрібно встановити при запуску програми:

У цей момент пристрій перезавантажується, щоб додаток потрапляло в Springboard й відобразилося користувачеві.

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

Це дозволяє створити символьне посилання під назвою /var/db/timezone, яка вказує на /var/tmp/launchd. Стандартні права доступу на /var/tmp/launchd наступні:

Зазвичай ці права доступу не дозволяють додатками, що працюють як користувач mobile потрапляти в цю директорію. Далі evasi0n повідомляє користувачеві, що він «брикається» lockdownd. Насправді це означає, що evasi0n відправляє неправильно сформований команду PairRequest до lockdownd. lockdownd - це основний сервіс на пристрої, який працює з командами, отриманими через USB, і використовується для запуску/зупинки інших служб, таких як MobileBackup і AFC. Так як lockdownd працює з правами адміністратора, і користувач може до нього звертатися, застосування його не за призначенням для виконання нестандартних завдань було досить поширеним серед попередніх джейлбрейков.

І ось ми підійшли до використання першої уразливості. Відправлення lockdownd неправильно сформованої команди PairRequest змушує lockdownd виконати команду chmod 777 /var/db/timezone, щоб вона була доступна для користувача mobile (і всіх користувачів). Нам не відомо, чи знаходиться ця вразливість в lockdownd або в якийсь системної бібліотеці.

В рамках етапу 2.2 ми продовжуємо заглиблюватися в /var/tmp/launchd. Це дозволяє змінити права доступу до сокету (спеціальний файл, через який йде комунікація між програмами в UNIX-подібних системах - прим.) так, щоб звичайний користувач без адміністративних прав міг отримати доступ до launchd. В рамках етапу 2.2 символьне посилання:

змінює timezone наступним чином:

Після цього evasi0n відсилає ще один спеціально сформований запит PairRequest в lockdownd, призводячи до того, що і файл /var/tmp/launchd/sock стане доступним для користувача mobile.

Він починається з завантаження на пристрій запакованого набору файлів, яке містить установщик Cydia. Відразу ці дані не використовуються, але зберігаються на майбутнє, щоб бути розпакованими після успішного джейлбрейка.

Далі користувачеві пропонується запустити на своєму пристрої додаток Jailbreak (насправді це DemoApp.app, який був створений в ході виконання Етапу 1 - прим.). Нагадаємо, що робить програму:

з змінної оточення

Якщо Ви прочитаєте мануал на launchctl, то побачите, що команда подачі описується наступним чином:

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

Унікальний лейбл, що використовується для призначення цього завдання launchd.

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

Якщо Ви поглянете на сторінку мануала launchd, то побачите:

Ця змінна експортується, коли виклик команди здійснюється через командний рядок launchd. Вона повідомляє launchctl про те, як знайти потрібний сокет launchd для комунікації.

На відміну від більшості інших компонентів iOS, механізм IPC (interprocess communication, «взаємодія між процесами» - прим.) launchd працює через сокети сервісів UNIX. Існує кілька процесів launchd, кожен з яких працює для кожного користувача. На iOS є один процес, який працює як root (адміністратора), і ще один - як mobile звичайний користувач. Тому користувач запускає launchctl через DemoApp.app з звичайними привілеями доступу. Тим не менш launchctl не звертається до launchd, що відноситься до mobile user. Замість цього він звертається до launchd, запущеному з адміністративним доступом, через сокет launchd, відкритий раніше через права доступу UNIX з використанням уразливості /var/db/timezone.

Оскільки launchd працює як root (адміністратора), ця команда буде виконуватися від імені адміністратора. В рамках цього процесу системний розділ диска пристрою буде перетворений в режим «читання-запис» (вся суть джейлбрейка - відкрити системний розділ файлової системи пристрою на запис, так як зазвичай він доступний лише для читання - прим.), що дозволяє эксплойту вносити зміни в системний розділ, які будуть виконані з правами адміністратора при завантаженні пристрою.

І ось починається заключний етап джейлбрейка, знову з використанням MobileBackup, проте на цей раз з повним доступом до системного розділу диска пристрою.

Це може виглядати трохи заплутано у зв'язку з надмірним використанням символьних посилань, але по суті, це створює каталогу /var/evasi0n, що містить виконуваний файл, бібліотеку і новий файл launchd.conf. launchd.conf описується Apple наступним чином:

«launchd.conf складається з переліку подкоманд (load, unload і т.д.) для запуску через launchctl(1), коли запускається launchd(8)».

Підставної launchd.conf, що запускається при кожній завантаження, містить:

Ось що він робить, поетапно:

встановлює системного розділу диска атрибути «читання-запис»;

завантажує бібліотеку amfi.dylib в будь-який виконуваний файл, який запускається після цього етапу;

завантажує сервіс MobileFileIntegrity;

запускає спеціально підготовлений код, раніше поміщений в /var/evasi0n/evasi0n;

очищає змінну оточення DYLD_INSERT_LIBRARIES, щоб amfi.dylib більше нікуди не завантажувався;

видаляє сокет-файл, раніше присутній у /private/var/evasi0n/шкарпетки;

створює символьне посилання з /var/tmp/launchd/sock на /private/var/evasi0n/шкарпетка, що дозволяє іншим кодом отримувати прямий доступ до сокету адміністративного launchd

Після цього експлойт перезавантажує пристрій, внаслідок чого ця конфігурація, рядок за рядком, виконується під час наступного запуску. Цікава особливість amfi.dylib і evasi0n полягає в тому, що вони не мають криптографічний підпис. Якщо поглянути на amfi.dylib з допомогою otool, можна побачити, що там взагалі немає розділу TEXT/text. Відсутність розділу TEXT/text означає, що там просто нічого підписувати. Замість цього там міститься наступна інформація для линковщика (компонент системи, відповідальний за прив'язку викликів системних бібліотек - прим.):

Завдяки розумному використанню особливостей линковщика, системні методи як CFEqual можуть бути замінені на інші, в результаті чого інші виклики, такі як MISValidateSignature, завжди будуть видавати 0, що дозволяє запускати будь-який непідписані бінарний код.

evasi0n цікавий тим, що він отримує адміністративний доступ, а потім і повний доступ до системного розділу диска пристрою без жодних трюків, пов'язаних з загаживанием пам'яті (оперативна пам'ять пристрою навмисно завантажується сміттям і спеціально підготовленим шматком виконуваного коду, в результаті чого виконується цей підготовлений код в результаті переповнення - прим.). Він робить це, використовуючи уразливість з /var/db/timezone, щоб отримати доступ до адміністративного сокету launchd. Потім він використовує launchd, щоб запустити MobileFileIntegrity з додатковою бібліотекою, що не містить коду, яка перепризначає MISValidateSignature, щоб та завжди повертала 0.