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 and jailbreaking:

iOS Testing Environment

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

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

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

iOS Basic Testing Operations

Tip

Для наступних кроків додаток має бути встановлений на пристрої і має бути вже отриманий IPA file додатку.
Read the Basic iOS Testing Operations page to learn how to do this.

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

Декілька цікавих decompilers для iOS - IPA файлів:

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

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

  • PIE (Position Independent Executable): When enabled, the application loads into a random memory address every-time it launches, making it harder to predict its initial memory address.
otool -hv <app-binary> | grep PIE   # It should include the PIE flag
  • Stack Canaries: To validate the integrity of the stack, a ‘canary’ value is placed on the stack before calling a function and is validated again once the function ends.
otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail
  • ARC (Automatic Reference Counting): To prevent common memory corruption flaws
otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol
  • Encrypted Binary: The binary should be encrypted
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

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

  • Weak Hashing Algorithms
# 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"
  • Insecure Random Functions
# 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"
  • Insecure ‘Malloc’ Function
# On the iOS device
otool -Iv <app> | grep -w "_malloc"

# On linux
grep -iER "_malloc"
  • Insecure and Vulnerable Functions
# 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: Спробуйте отримати доступ до обмежених областей файлової системи, які мають бути заблоковані на пристроях без jailbreak.
  • 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: Шукайте виклики до антидебагінгових API, таких як ptrace або SIGSTOP, наприклад ptrace(PT_DENY_ATTACH, 0, 0, 0).
  • Timing Checks: Вимірюйте час виконання певних операцій і шукайте невідповідності, які можуть вказувати на дебагування.
  • Memory Checks: Інспектуйте пам’ять на наявність артефактів дебагера або модифікацій.
  • Environment Variables: Перевіряйте змінні середовища, які можуть вказувати на сесію дебагування.
  • Mach Ports: Виявляйте, чи використовуються mach exception ports дебагерами.

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

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

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

Використовуйте команду 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 components of the application та як легко hook methods and classes за допомогою objection:

iOS Hooking With Objection

Структура IPA

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

  • Info.plist: Цей файл містить специфічні конфігураційні деталі застосунку.
  • _CodeSignature/: Цей каталог включає plist-файл із підписом, який забезпечує цілісність усіх файлів у бандлі.
  • Assets.car: Стиснутий архів, що зберігає файли ресурсів, наприклад іконки.
  • Frameworks/: Ця папка містить нативні бібліотеки застосунку, які можуть бути у вигляді .dylib або .framework файлів.
  • PlugIns/: Тут можуть бути розширення застосунку, відомі як .appex файли, хоча вони бувають не завжди. * Core Data: Використовується для збереження постійних даних застосунку для офлайн-доступу, кешування тимчасових даних та додавання функції undo у вашому застосунку на одному пристрої. Для синхронізації даних між кількома пристроями в одному iCloud-акаунті Core Data автоматично відображає вашу схему в контейнер CloudKit.
  • PkgInfo: Файл PkgInfo — альтернативний спосіб вказати type та creator коди вашої програми або бандлу.
  • en.lproj, fr.proj, Base.lproj: Це мовні пакети, які містять ресурси для відповідних мов, а також ресурс за замовчуванням на випадок, якщо мова не підтримується.
  • Security: Каталог _CodeSignature/ відіграє критичну роль у безпеці додатка, перевіряючи цілісність усіх файлів бандла через цифрові підписи.
  • Asset Management: Файл Assets.car використовує стиснення для ефективного керування графічними ресурсами, що важливо для оптимізації продуктивності застосунку та зменшення його розміру.
  • Frameworks and PlugIns: Ці каталоги підкреслюють модульність iOS-застосунків, дозволяючи розробникам включати багаторазово використовувані бібліотеки коду (Frameworks/) та розширювати функціональність застосунку (PlugIns/).
  • Localization: Структура підтримує кілька мов, полегшуючи глобальне поширення застосунку шляхом включення ресурсів для конкретних мовних пакетів.

Info.plist

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

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

  • For 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 мають бути ізольовані (sandboxed), кожен додаток також матиме папку всередині $HOME/Library/Containers з ім’ям папки, що відповідає CFBundleIdentifier додатка.

Однак обидві папки (data & container folders) містять файл .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 directory:

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

Data directory:

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

Let’s take a closer look at iGoat-Swift’s Application Bundle (.app) directory inside the Bundle directory (/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 ви знайдете binary файл під назвою <application-name>. Це файл, який буде executed. Ви можете виконати базову інспекцію binary за допомогою інструмента 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)
[...]

Перевірте, чи додаток зашифрований

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

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 segment з прикладного додатка, можна використати:

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;
};

However, the best options to disassemble the binary are: Hopper and IDA.

Збереження даних

To learn about how iOS stores data in the device read this page:

iOS Basics

Warning

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

Plist

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

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

The NSUserDefaults class provides a programmatic interface for interacting with the default system. The default system allows an application to customize its behaviour according to user preferences. Data saved by NSUserDefaults can be viewed in the application bundle. This class stores data in a plist file, but it’s meant to be used with small amounts of data.

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

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

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

find ./ -name "*.plist"

Щоб конвертувати файли з формату XML or binary (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 files:

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 does not encrypt it’s data by default. Однак до CoreData можна додати додатковий шар шифрування. Див. the GitHub Repo для детальнішої інформації.

You can find the SQLite Core Data information of an application in the path /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

If you can open the SQLite and access sensitive information, then you found a miss-configuration.

-(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 базами даних, ви можете знайти їх, використовуючи запропоновану команду в попередньому розділі.

Other SQLite Databases

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

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

Firebase Real-Time Databases

Розробникам надається можливість store and sync data у NoSQL cloud-hosted database через Firebase Real-Time Databases. Збережені у форматі JSON, дані синхронізуються зі всіма підключеними клієнтами в реальному часі.

Тут показано, як перевірити неправильно налаштовані бази даних Firebase:

Firebase Database

Бази даних Realm

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

Бази даних знаходяться за шляхом: /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/

Cookies

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

Щоб переглянути файл cookies, ви можете використати цей python-скрипт або скористатися objection’ом командою 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"
}
]

Cache

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

Рекомендується recommended to disable Caching this data, оскільки в запиті або відповіді може міститися конфіденційна інформація. Нижче наведено різні способи досягти цього:

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

URLCache.shared.removeAllCachedResponses()

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

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

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 також можна вимкнути, встановивши Cache Policy в .notAllowed. Це заборонить збереження Cache будь-яким способом — у пам’яті або на диску.

Snapshots

Коли ви натискаєте кнопку Home, iOS takes a snapshot of the current screen щоб забезпечити більш плавний перехід між застосунками. Однак, якщо на поточному екрані присутні sensitive data, вони будуть saved у image (який persists across reboots). Це ті snapshot’и, до яких також можна отримати доступ, двічі натиснувши кнопку Home для перемикання між додатками.

Якщо iPhone не є jailbroken, attacker повинен мати access до device unblocked, щоб побачити ці скриншоти. За замовчуванням останній snapshot зберігається у sandbox додатку в Library/Caches/Snapshots/ або Library/SplashBoard/Snapshots (trusted computers не можуть отримати доступ до файлової системи з iOX 7.0).

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

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

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 devices. Крім того, 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];

To extract these stored credentials, Objection’s command ios nsurlcredentialstorage dump is utilized.

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

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

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

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

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

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

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

Крім того, розробники повинні гарантувати, що текстові поля, особливо ті, що призначені для введення конфіденційної інформації, наприклад паролів та PIN-кодів, вимикають кешування, встановивши 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. Перейдіть до Вікно -> Пристрої та Симулятори.
  4. Виберіть свій пристрій.
  5. Спровокуйте проблему, яку ви досліджуєте.
  6. Використайте кнопку Відкрити консоль, щоб переглянути журнали в новому вікні.

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

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

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

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

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

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

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

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

Файли в 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>

Для роботи з зашифрованими резервними копіями корисними можуть бути Python-скрипти з DinoSec’s GitHub repo, такі як backup_tool.py та backup_passwd.py, хоча може знадобитися їх адаптація для сумісності з останніми версіями iTunes/Finder. Іншим варіантом доступу до файлів у захищених паролем бекапах є інструмент iOSbackup.

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

Приклад зміни поведінки додатка шляхом модифікації бекапу показано у Bither bitcoin wallet app, де UI lock PIN зберігається у net.bither.plist під ключем pin_code. Видалення цього ключа з plist і відновлення бекапу скасовує вимогу PIN, забезпечуючи необмежений доступ.

Підсумок тестування пам’яті щодо конфіденційних даних

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

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

Для як jailbroken, так і non-jailbroken пристроїв інструменти на кшталт objection та Fridump дозволяють зробити дамп пам’яті процесу додатка. Після створення дампа для аналізу цих даних потрібні різні інструменти, залежно від характеру інформації, яку ви шукаєте.

Щоб витягти рядки з дампа пам’яті, можна використовувати команди, такі як strings або rabin2 -zz:

# 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]> /?
...

Runtime Memory Analysis

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

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

Проблемна Cryptography

Погані процеси управління ключами

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

Використання ненадійних та/або застарілих алгоритмів

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

Перевірка

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

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

ios monitor crypt

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

Local Authentication

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

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

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

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

Caution

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

Implementing Local Authentication

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

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

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

Local Authentication using Keychain

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

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

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

// 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

If Security.framework is used, only the second one will be shown.

Обхід Local Authentication Framework

Objection

Through the Objection Biometrics Bypass, located at this GitHub page, a technique is available for overcoming the LocalAuthentication mechanism. The core of this approach involves leveraging Frida to manipulate the evaluatePolicy function, ensuring it consistently yields a True outcome, irrespective of the actual authentication success. This is particularly useful for circumventing flawed biometric authentication processes.

Щоб активувати цей 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’а, перевірка аутентифікації фактично bypass.

Нижченаведений скрипт інжектується, щоб змінити результат методу 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 та обійти біометричну аутентифікацію, використовується наступна команда:

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

Вразливий доступ до чутливого функціоналу через IPC

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

Hostname check

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

Certificate Pinning

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

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

Misc

  • У /System/Library можна знайти фреймворки, встановлені в телефоні та використовувані системними додатками
  • Додатки, встановлені користувачем з App Store, розташовані всередині /User/Applications
  • А /User/Library містить дані, збережені прикладними програмами рівня користувача
  • Ви можете отримати доступ до /User/Library/Notes/notes.sqlite, щоб прочитати нотатки, збережені у застосунку.
  • Всередині теки встановленого додатку (/User/Applications/<APP ID>/) можна знайти деякі цікаві файли:
  • 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. Цю утиліту слід запускати проти самого додатку та кожної спільної бібліотеки, яку він використовує, щоб виявити додаткові бібліотеки.

otool -L <application_path>

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

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

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

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