Как да откриете и заобиколите откриването на Jailbreak - a

Съдържанието на статията

„Jailbroken“ устройство на Apple е не само нови функции, но и допълнителни проблеми със сигурността за самото устройство и приложенията, работещи на него. Днес ще говорим за това какво е джейлбрейк, как работи и какви са неговите последици за сигурността.

Какво е джейлбрейк?

В същото време самите джейлбрейкове са два вида:

• вързан (прикрепен);
• необвързан (необвързан).

Прикрепено означава, че след рестартиране на такова устройство JB изчезва, а в случай на неприкрепено ще остане в сила, което е много по-удобно.

Самата Apple, разбира се, третира негативно джейлбрейка и предупреждава своите потребители за това. Това е очевидно, защото трети страни правят промени в затворена ОС и, за да запазят тези промени, нарушават системата за сигурност на ОС - те кръпват и хакват определени части от кода. Което, разбира се, води до нарушаване на стабилността на OC - трябва да го имате предвид, когато правите jailbreak.

Бягството от затвора е риск за сигурността

JB деактивира повечето от механизмите за сигурност на ОС, във връзка с това съществува заплаха от злонамерен софтуер, заразяващ устройството. Това може да бъде или случайно изтеглен зловреден софтуер от Cydia (никой не го проверява там), или целенасочена атака в духа на ZitMo, SpitMo, CitMo. Ако си мислите, че такива проекти не съществуват, грешите. Има проект за шпионаж на iPhone, който включва такива функции като:

• кийлогър;
• заснемане на екранни снимки;
• SMS пренасочване;
• запис на микрофон;
• изпращане на GPS координати.

Както и да е, целият процес на създаване на джейлбрейк отстрани приличаигра на котка и мишка между Apple и разработчиците. Някои затварят уязвимостите и въвеждат нови механизми за сигурност в операционната система, докато други чакат издания и тестват своето потомство.

Отношението на Apple към бягството от затвора

Xakep #240. Гидра

Сигурност в iOS

Стига прелюдии, нека започнем да се гмурнем в техническия компонент на джейлбрейка. Нека се запознаем малко с механизмите за сигурност на iOS, които пречат на JB.

Разбира се, тъй като JB процесът трябва да използва бъгове, повредени в паметта, има също така необходимост да се заобиколят различни механизми за сигурност, насочени към затрудняване на използването на такива уязвимости. Сред тях са бисквитките стек, DEP, ASLR, KASLR и редица други, които дори нямат специални имена. Няма да се спираме на това: няма да ни помогне да открием JB на устройството по никакъв начин и като цяло е извън обхвата на тази статия.

Малко история и цифри

Живот след JB

Да преминем към нашата основна тема. За да разберете как да откриете дали JB има устройство или не, трябва да разберете какво JB е направил, променил, изоставил. И така, поставихте JB - какви нови аспекти се отвориха за вас?

Ще играем на тези ефекти - открийте JB!

JB общи стъпки

Последици от J.B.

Последствие 1: FS промени

След като JB е инсталиран, /etc/fstab се променя. Директорията / става записваема, а директорията /private/var губи битовете nosuid, nodev.

iOS устройство FS

Последствие 2: допълнителни помощни програми

По подразбиране няма unix shell на устройство с iOS. Това е разбираемо, Apple не е включила в своите устройства възможност за работа с тях от конзолата. В тази връзка JB поставя различни полезни програми, за да опрости свояинсталация. В резултат на това на устройството се появяват куп нови помощни програми, включително помощни програми за JB, файлове на самия JB, различни пакети, Cydia (обикновено, но не непременно), Mobile Substrate и т.н. Някои от тези нови функции могат да се видят в модифицирания /var/mobile/Library/Caches/com.apple.mobile.installation.plist.

Последствие 3: преместване на папка

Приложенията от App Store се поставят в /var/mobile/Applications, а тези от Cydia се поставят в /Applications. Поради факта, че системната директория (/) е много по-малка от потребителската директория (/private/var), а приложенията от Cydia са инсталирани в системната директория, има проблем с наличното пространство. За да го разрешите, направете символна връзка от необходимите директории към потребителската директория, където има достатъчно място. В резултат на това методът има следната формула: /var/stash + символни връзки. Същото се прави за /Library/Ringtones, /Library/Wallpaper, /usr/include, /usr/lib/pam, /usr/libexec, /usr/share.

Основен изглед след JB

Последствие 4: Счупена пясъчна кутия

Тези промени се случват много ниско, на двоично ниво и няма да ни бъдат много полезни, но е невъзможно да не се каже за тях. Първо, JB закърпва Apple Mobile File Integrity Daemon, който отговаря за проверката на подписите. Второ, прави промени в самото ядро:

• поява на нови файлове/директории;
• променени имоти;
• променено поведение.

Някой може да се чуди: Защо аз, като разработчик на приложения за iPhone, ще проверявам на кое устройство работи приложението ми? Въпросът е добър и логичен.

Първо, за намаляване на рисковете за самия потребител. Ако разработвате някакво критично мобилно приложение, например за мобилно банкиране, тогава вПоради възможността за изпълнение на злонамерен софтуер на такова устройство, можете или да предотвратите стартирането на вашето приложение, или да ограничите някои от наличните функции, например да забраните паричните преводи или да ги ограничите до горна граница. Виждал съм такива подходи в българските приложения за мобилно банкиране. Също така често се използва от MDM (Управление на мобилни устройства) системи.

Второ, за да се предотврати заобикалянето на въведените в кода ограничения. Ограниченията за клиента са зло.

Трето, усложнете анализа на вашето приложение. Някой може да иска да проучи алгоритъма на вашата програма и тук не можете да правите само статика - имате нужда и от динамика. И за да не му изглежда животът като мед, можете или да спрете да работите, или да поемете по грешен път.

Откриване на JB: нови файлове.

1. Можете да препращате към файлове от Cydia (напр. /Applications/Cydia.app/ ) или URI схемата на cydia://, която идва с него. Този метод е много често срещан, но трябва да имате предвид, че Cydia е просто пакет и може да не бъде включен в JB или да бъде премахнат. Вземете например най-новия JB от evad3rs за iOS 7. Те нямат Cydia, но имат китайския App Store Taig.
2. Можете да опитате да получите достъп до всички известни файлове извън пясъчника, било то /bin/bash, /Application/Preferences.app/General.plist или /Applications/MobileMail.app.
3. Естествено, файловете за джейлбрейк не могат да бъдат игнорирани - например /private/var/stash. Има много от тях и първо могат да бъдат определени от датата на модификация в системата.
4. Има по-екзотични начини, като например SSH loopback връзка - достъп до 127.0.0.1 порт 22, тъй като потребителите обикновено поставят SSH на него, за да взаимодействат с устройството.

За справка с URI-можете да използвате функцията Objective-C openURL и да работите с файлове, както функциите Obj-C (BOOL)fileExistsAtPath:(NSString*)path), така и класическите C функции (fopen(), stat() или access()).

JB Discovery: Промяна на свойства

Понякога, за да объркате, можете да се обърнете не към самите файлове, а към техните свойства:

• права за достъп за запис;
• размер /etc/fstab;
• намерете символни връзки към /var/stash c:/Applications /Library/Ringtones /Library/Wallpaper /usr/arm-apple-darwin9 /usr/include /usr/libexec /usr/share

Тук всичко е просто, както в предишния параграф. Отново можете да използвате както Obj-C функции от класа NSFileManager, така и стандартни C функции като statfs(), stat().

Откриване на JB: Променено поведение или целостта на пясъчника

полезни връзки

Интересен уеб проект за генериране на код за откриване на JB: appminder.nesolabs.de

JB откритие заобикаля

Ако откриването може да бъде открито, тогава процесът на откриване също може да бъде открит. И след това го промени по правилния начин :). Има три основни начина:

1. Редактиране на двоичен файл. Ние кръпваме самия код, даден в двоичен файл. Например, ако дадено приложение открие наличието на JB чрез наличието на файла /Applications/Cydia.app/, тогава можете да коригирате Cydia към Fydia директно в двоичния файл и такъв файл вече не се намира в системата и проверката ще бъде неуспешна. Можете също така да коригирате ARM код, като условен преход към безусловен. Пачването на инструкции в ARM също така опростява факта, че всички инструкции в него имат фиксирана дължина.
2. Използване на MobileSubstrate за закачане на Objective-C функции. Ако проверката е реализирана в Obj-C, тогава тя може много лесно да бъде прихваната по време на изпълнение и да върне стойността, от която се нуждаем. За пример вижте проектаxCon, който прави точно това. Като цяло можете да погледнете имената на методите в класовете за наличието на JailbreakDetect, isJailbreak и т.н., след което пишем настройка и защитата се предава.
3. Игри по време на изпълнение (GDB, Cycript). Ако проверката е реализирана като част от друга функция, тогава не можем да я заменим напълно толкова просто. Тук трябва да играете с GDB. Като цяло в този метод няма нищо ново в сравнение с платформата Linux.

Препоръки за разработчиците

Освен какво да нанесете, трябва да знаете и как да го нанесете правилно. Тук бих искал да дам няколко съвета как да защитите приложение за iOS.

1. Използвайте техники за отстраняване на грешки. Това е добре познатата функция ptrace(PTDENYATTACH, 0, 0, 0) и флага P_TRACED.
2. Използвайте техники против закачане. В iOS откриването на кука може да се извърши с извикване dladdr() и Dlinfo структура. Още по-добре, критични кодови фрагменти (проверки за сигурност, откриване на джейлбрейк) като вградени функции, използващи _attribute_((alwaysinline)).
3. Объркайте своя код и данни. Спецификата на Objective-C е, че той съхранява много мета-информация за класове, функции, променливи и т.н. Ако в други компилирани езици, като правило, това са символи и те не влизат в окончателното сглобяване, тогава всичко е на лице и това е просто приказка за обратен инженеринг - логиката е ясна веднага. Така че можете да преименувате имена на класове и методи преди пускане. Що се отнася до критичните данни, те трябва да бъдат криптирани или динамично генерирани.
4. Ако се опитвате да определите наличието на JB, използвайте не една техника, а няколко.

В същото време се опитайте да разпределите равномерно всички проверки за сигурност върху кода, а не само в началото на програмата. И използвайте C за критични функции и функциисигурност - по този начин информацията за тях няма да се показва в _objc сегменти.

Информация за класове и методи от двоичния Mach-O

За да се предпазите от пиратство на приложението, можете да проверите целостта на собствените си файлове. Например, целостта на изпълнимия файл е LCENCRYPTIONINFO = 0 за всички кракнати/декриптирани приложения, тъй като той е декриптиран. Или, алтернативно, проверете файловете с метаданни: iTunesMetadata.plist, SC_Info, Code Signing, Info.plist.

Разбира се, няма идеална, непреодолима защита и всички горепосочени методи само усложняват процеса на обратно инженерство.

Статията не изброява всички начини за откриване на JB на устройство, но по аналогия можете да намерите свои собствени и да подобрите съществуващите методи.

Верига за изтегляне на iOS

Първо, има три режима на зареждане на iOS: нормално зареждане, режим DFU (надграждане на фърмуера на устройството) и режим на възстановяване. Последните две, ако не навлизате в подробности, са необходими за възстановяване на операционната система до определено състояние. Режимът на възстановяване се използва за актуализиране на операционната система чрез iTunes. А фигурата по-долу илюстрира стъпките за нормално зареждане.

Второ, по време на нормално зареждане системните компоненти се зареждат в следния ред: Bootrom -> LLB-> iBoot-> Ядро-> Системен софтуер -> Приложения.

На всеки етап се проверява сигнатурата на компонента. Тази верига може да бъде атакувана на всеки етап и колкото по-скоро се направи това, толкова по-добре, тъй като на по-ранните етапи има по-малко механизми за сигурност, които трябва да бъдат заобиколени, и колкото по-близо до началото, толкова по-близо до хардуера. И затварянето на уязвимост в хардуерен компонент изисква производителят да замени самия хардуер, тоест животът на такава уязвимост е до пусканетоследващата версия на устройството.

Възможни атаки срещу веригата за изтегляне на iOS

---