iOS Pentesting
Last updated
Last updated
Використовуйте Trickest для легкого створення та автоматизації робочих процесів, підтримуваних найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:
На цій сторінці ви можете знайти інформацію про iOS емулятор, емулятори та джейлбрейк:
iOS Testing EnvironmentПід час тестування буде запропоновано кілька операцій (підключитися до пристрою, читати/записувати/завантажувати/скачувати файли, використовувати деякі інструменти...). Тому, якщо ви не знаєте, як виконати будь-яку з цих дій, будь ласка, почніть читати цю сторінку:
iOS Basic Testing OperationsДля наступних кроків додаток має бути встановлено на пристрої та вже має бути отримано IPA файл програми. Прочитайте сторінку Основні операції тестування iOS, щоб дізнатися, як це зробити.
Рекомендується використовувати інструмент MobSF для виконання автоматичного статичного аналізу IPA файлу.
Ідентифікація захистів, присутніх у бінарному файлі:
PIE (Position Independent Executable): Коли увімкнено, програма завантажується в випадкову адресу пам'яті щоразу, коли вона запускається, ускладнюючи передбачення її початкової адреси пам'яті.
Stack Canaries: Для перевірки цілісності стеку значення «канарки» розміщується на стеку перед викликом функції та перевіряється знову після завершення функції.
ARC (Automatic Reference Counting): Для запобігання поширеним помилкам корупції пам'яті
Зашифрований бінарний файл: Бінарний файл має бути зашифрований
Ідентифікація чутливих/незахищених функцій
Слабкі алгоритми хешування
Ненадійні випадкові функції
Ненадійна функція ‘Malloc’
Ненадійні та вразливі функції
Ознайомтеся з динамічним аналізом, який виконує MobSF. Вам потрібно буде переміщатися між різними виглядами та взаємодіяти з ними, але він буде підключати кілька класів, виконуючи інші дії, і підготує звіт, коли ви закінчите.
Використовуйте команду frida-ps -Uai
, щоб визначити ідентифікатор пакета встановлених додатків:
Дізнайтеся, як перерахувати компоненти програми та як легко підключати методи та класи за допомогою objection:
iOS Hooking With ObjectionСтруктура IPA файлу в основному є структурою запакованого архіву. Змінивши його розширення на .zip
, його можна розпакувати, щоб виявити його вміст. У цій структурі Bundle представляє повністю упаковану програму, готову до встановлення. Всередині ви знайдете каталог з назвою <NAME>.app
, який містить ресурси програми.
Info.plist
: Цей файл містить специфічні конфігураційні деталі програми.
_CodeSignature/
: Цей каталог включає файл plist, який містить підпис, що забезпечує цілісність усіх файлів у бандлі.
Assets.car
: Стиснутий архів, що зберігає файли активів, такі як іконки.
Frameworks/
: Ця папка містить рідні бібліотеки програми, які можуть бути у формі файлів .dylib
або .framework
.
PlugIns/
: Це може включати розширення програми, відомі як файли .appex
, хоча вони не завжди присутні. * Core Data
: Використовується для збереження постійних даних вашої програми для офлайн-використання, для кешування тимчасових даних та для додавання функціональності скасування дій у вашій програмі на одному пристрої. Щоб синхронізувати дані між кількома пристроями в одному обліковому записі iCloud, Core Data автоматично відображає вашу схему в контейнер CloudKit.
PkgInfo
: Файл PkgInfo
є альтернативним способом вказати тип і коди творця вашої програми або бандлу.
en.lproj, fr.proj, Base.lproj: Це мовні пакети, які містять ресурси для цих конкретних мов, а також ресурс за замовчуванням на випадок, якщо мова не підтримується.
Безпека: Каталог _CodeSignature/
відіграє критичну роль у безпеці програми, перевіряючи цілісність усіх упакованих файлів за допомогою цифрових підписів.
Управління активами: Файл Assets.car
використовує стиснення для ефективного управління графічними активами, що є важливим для оптимізації продуктивності програми та зменшення її загального розміру.
Frameworks та PlugIns: Ці каталоги підкреслюють модульність iOS програм, дозволяючи розробникам включати повторно використовувані бібліотеки коду (Frameworks/
) та розширювати функціональність програми (PlugIns/
).
Локалізація: Структура підтримує кілька мов, полегшуючи глобальне охоплення програми, включаючи ресурси для специфічних мовних пакетів.
Info.plist
Info.plist служить основою для iOS програм, інкапсулюючи ключові конфігураційні дані у формі пар ключ-значення. Цей файл є обов'язковим не лише для програм, але й для розширень програм та фреймворків, упакованих разом. Він структурований у форматі XML або бінарному форматі та містить критичну інформацію, починаючи від дозволів програми до конфігурацій безпеки. Для детального вивчення доступних ключів можна звернутися до Apple Developer Documentation.
Для тих, хто хоче працювати з цим файлом у більш доступному форматі, конвертацію в XML можна здійснити без зусиль за допомогою plutil
на macOS (доступний нативно на версіях 10.2 і пізніше) або plistutil
на Linux. Команди для конвертації такі:
Для macOS:
Для Linux:
Серед безлічі інформації, яку може розкрити файл Info.plist, помітні записи включають рядки дозволів додатка (UsageDescription
), користувацькі URL-схеми (CFBundleURLTypes
) та конфігурації для App Transport Security (NSAppTransportSecurity
). Ці записи, разом з іншими, такими як експортовані/імпортовані користувацькі типи документів (UTExportedTypeDeclarations
/ UTImportedTypeDeclarations
), можна без зусиль знайти, перевіряючи файл або використовуючи просту команду grep
:
Шляхи Даних
У середовищі iOS каталоги призначені спеціально для системних додатків та додатків, встановлених користувачем. Системні додатки розташовані в каталозі /Applications
, тоді як додатки, встановлені користувачем, знаходяться під /var/mobile/containers/Data/Application/
. Ці додатки отримують унікальний ідентифікатор, відомий як 128-бітний UUID, що ускладнює завдання ручного знаходження папки додатка через випадковість назв каталогів.
Оскільки додатки в iOS повинні бути в пісочниці, кожен додаток також матиме папку всередині $HOME/Library/Containers
з CFBundleIdentifier
додатка як назва папки.
Однак обидві папки (папки даних та контейнерів) мають файл .com.apple.mobile_container_manager.metadata.plist
, який пов'язує обидва файли за ключем MCMetadataIdentifier
.
Щоб полегшити виявлення каталогу встановлення додатка, встановленого користувачем, інструмент objection надає корисну команду env
. Ця команда розкриває детальну інформацію про каталог для відповідного додатка. Нижче наведено приклад використання цієї команди:
Альтернативно, ім'я програми можна знайти в /private/var/containers
, використовуючи команду find
:
Команди, такі як ps
та lsof
, також можуть бути використані для ідентифікації процесу програми та переліку відкритих файлів відповідно, надаючи інформацію про активні директорії програми:
Bundle directory:
AppName.app
Це пакет програми, як було зазначено раніше в IPA, він містить основні дані програми, статичний контент, а також скомпільований бінарний файл програми.
Ця директорія видима для користувачів, але користувачі не можуть записувати в неї.
Контент у цій директорії не резервується.
Вміст цієї папки використовується для перевірки підпису коду.
Data directory:
Documents/
Містить всі дані, створені користувачем. Кінцевий користувач програми ініціює створення цих даних.
Видима для користувачів і користувачі можуть записувати в неї.
Контент у цій директорії резервується.
Додаток може вимкнути шляхи, встановивши NSURLIsExcludedFromBackupKey
.
Library/
Містить всі файли, які не є специфічними для користувача, такі як кеші, налаштування, куки та файли конфігурації списку властивостей (plist).
Додатки iOS зазвичай використовують підкаталоги Application Support
та Caches
, але додаток може створювати власні підкаталоги.
Library/Caches/
Містить напівпостійні кешовані файли.
Невидима для користувачів і користувачі не можуть записувати в неї.
Контент у цій директорії не резервується.
ОС може автоматично видаляти файли цієї директорії, коли додаток не працює, а місця для зберігання не вистачає.
Library/Application Support/
Містить постійні файли, необхідні для роботи програми.
Невидима для користувачів і користувачі не можуть записувати в неї.
Контент у цій директорії резервується.
Додаток може вимкнути шляхи, встановивши NSURLIsExcludedFromBackupKey
.
Library/Preferences/
Використовується для зберігання властивостей, які можуть зберігатися навіть після перезапуску програми.
Інформація зберігається, нешифрована, всередині пісочниці програми у файлі plist під назвою [BUNDLE_ID].plist.
Усі пари ключ/значення, збережені за допомогою NSUserDefaults
, можна знайти в цьому файлі.
tmp/
Використовуйте цю директорію для запису тимчасових файлів, які не потрібно зберігати між запусками програми.
Містить непостійні кешовані файли.
Невидима для користувачів.
Контент у цій директорії не резервується.
ОС може автоматично видаляти файли цієї директорії, коли додаток не працює, а місця для зберігання не вистачає.
Давайте ближче розглянемо пакет програми iGoat-Swift (.app) у директорії Bundle (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
):
Всередині папки <application-name>.app
ви знайдете бінарний файл під назвою <application-name>
. Це файл, який буде виконуватись. Ви можете виконати базову перевірку бінарного файлу за допомогою інструменту otool
:
Перевірте, чи зашифровано додаток
Перевірте, чи є будь-який вихід для:
Дизасемблювання бінарного файлу
Дизасемблюйте текстовий розділ:
Щоб надрукувати Objective-C сегмент зразкової програми, можна використовувати:
Щоб отримати більш компактний код Objective-C, ви можете використовувати class-dump:
Однак, найкращими варіантами для дизасемблювання бінарного коду є: Hopper та IDA.
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:
Щоб дізнатися, як iOS зберігає дані на пристрої, прочитайте цю сторінку:
iOS BasicsНаступні місця для зберігання інформації слід перевірити відразу після встановлення програми, після перевірки всіх функцій програми та навіть після виходу з одного користувача та входу в іншого. Мета полягає в тому, щоб знайти незахищену чутливу інформацію програми (паролі, токени), поточного користувача та раніше увійшлих користувачів.
plist файли - це структуровані XML файли, які містять пари ключ-значення. Це спосіб зберігати постійні дані, тому іноді ви можете знайти чутливу інформацію в цих файлах. Рекомендується перевіряти ці файли після встановлення програми та після інтенсивного використання, щоб побачити, чи записуються нові дані.
Найпоширеніший спосіб зберігання даних у plist файлах - це використання NSUserDefaults. Цей plist файл зберігається всередині пісочниці програми в Library/Preferences/<appBundleID>.plist
Клас NSUserDefaults
надає програмний інтерфейс для взаємодії з системою за замовчуванням. Система за замовчуванням дозволяє програмі налаштовувати свою поведінку відповідно до уподобань користувача. Дані, збережені за допомогою NSUserDefaults
, можна переглядати в пакеті програми. Цей клас зберігає дані в plist файлі, але призначений для використання з невеликою кількістю даних.
Ці дані більше не можуть бути доступні безпосередньо через довірений комп'ютер, але можуть бути доступні шляхом виконання резервного копіювання.
Ви можете вивантажити інформацію, збережену за допомогою NSUserDefaults
, використовуючи ios nsuserdefaults get
від objection.
Щоб знайти всі plist, які використовуються програмою, ви можете отримати доступ до /private/var/mobile/Containers/Data/Application/{APPID}
і виконати:
Щоб конвертувати файли з XML або бінарного (bplist) формату в XML, доступні різні методи в залежності від вашої операційної системи:
Для користувачів macOS: Використовуйте команду plutil
. Це вбудований інструмент в macOS (10.2+), призначений для цієї мети:
Для користувачів Linux: Спочатку встановіть libplist-utils
, а потім використовуйте plistutil
для конвертації вашого файлу:
У сесії Objection: Для аналізу мобільних додатків спеціальна команда дозволяє вам безпосередньо конвертувати файли plist:
Core Data
— це фреймворк для управління модельним шаром об'єктів у вашому додатку. Core Data може використовувати SQLite як своє постійне сховище, але сам фреймворк не є базою даних.
CoreData за замовчуванням не шифрує свої дані. Однак, додатковий шар шифрування можна додати до CoreData. Дивіться GitHub Repo для отримання додаткової інформації.
Ви можете знайти інформацію про SQLite Core Data додатку за шляхом /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support
Якщо ви можете відкрити SQLite і отримати доступ до чутливої інформації, то ви знайшли неправильну конфігурацію.
YapDatabase - це сховище ключ/значення, побудоване на основі SQLite. Оскільки бази даних Yap є базами даних sqlite, ви можете знайти їх, використовуючи запропоновану команду в попередньому розділі.
Звичайно, що додатки створюють свої власні бази даних sqlite. Вони можуть зберігати чутливі дані на них і залишати їх незашифрованими. Тому завжди цікаво перевіряти кожну базу даних у каталозі додатків. Тому перейдіть до каталогу додатка, де зберігаються дані (/private/var/mobile/Containers/Data/Application/{APPID}
)
Розробники можуть зберігати та синхронізувати дані в NoSQL хмарній базі даних через Firebase Real-Time Databases. Дані, збережені у форматі JSON, синхронізуються з усіма підключеними клієнтами в реальному часі.
Ви можете дізнатися, як перевірити неправильно налаштовані Firebase бази даних тут:
Firebase DatabaseRealm Objective-C та Realm Swift пропонують потужну альтернативу для зберігання даних, яку не надає Apple. За замовчуванням, вони зберігають дані без шифрування, з можливістю шифрування через специфічну конфігурацію.
Бази даних розташовані за адресою: /private/var/mobile/Containers/Data/Application/{APPID}
. Щоб дослідити ці файли, можна використовувати команди, такі як:
Для перегляду цих файлів бази даних рекомендується інструмент Realm Studio.
Щоб реалізувати шифрування в базі даних Realm, можна використовувати наступний фрагмент коду:
Couchbase Lite описується як легкий та вбудований механізм бази даних, який слідує документно-орієнтованому (NoSQL) підходу. Розроблений для iOS та macOS, він пропонує можливість безперервної синхронізації даних.
Щоб виявити потенційні бази даних Couchbase на пристрої, слід перевірити наступний каталог:
iOS зберігає куки додатків у Library/Cookies/cookies.binarycookies
всередині папки кожного додатку. Однак, розробники іноді вирішують зберігати їх у keychain, оскільки згаданий файл куків може бути доступний у резервних копіях.
Щоб перевірити файл куків, ви можете використовувати цей python скрипт або використовувати ios cookies get
з objection.
Ви також можете використовувати objection, щоб конвертувати ці файли у формат JSON і перевірити дані.
За замовчуванням NSURLSession зберігає дані, такі як HTTP запити та відповіді в базі даних Cache.db. Ця база даних може містити чутливі дані, якщо токени, імена користувачів або будь-яка інша чутлива інформація була кешована. Щоб знайти кешовану інформацію, відкрийте каталог даних програми (/var/mobile/Containers/Data/Application/<UUID>
) і перейдіть до /Library/Caches/<Bundle Identifier>
. Кеш WebKit також зберігається у файлі Cache.db. Objection може відкрити та взаємодіяти з базою даних за допомогою команди sqlite connect Cache.db
, оскільки це нормальна SQLite база даних.
Рекомендується відключити кешування цих даних, оскільки вони можуть містити чутливу інформацію в запиті або відповіді. Наступний список показує різні способи досягнення цього:
Рекомендується видалити кешовані відповіді після виходу з системи. Це можна зробити за допомогою методу, наданого Apple, під назвою removeAllCachedResponses
. Ви можете викликати цей метод наступним чином:
URLCache.shared.removeAllCachedResponses()
Цей метод видалить всі кешовані запити та відповіді з файлу Cache.db. 2. Якщо вам не потрібно використовувати переваги куків, рекомендується просто використовувати властивість конфігурації URLSession .ephemeral, яка відключить збереження куків та кешів.
Об'єкт конфігурації сесії ephemeral подібний до конфігурації сесії за замовчуванням (див. default), за винятком того, що відповідний об'єкт сесії не зберігає кеші, сховища облікових даних або будь-які дані, пов'язані з сесією, на диску. Натомість дані, пов'язані з сесією, зберігаються в оперативній пам'яті. Єдиний раз, коли ephemeral сесія записує дані на диск, це коли ви кажете їй записати вміст URL у файл.
3. Кеш також можна відключити, встановивши політику кешування на .notAllowed. Це відключить зберігання кешу будь-яким чином, як в пам'яті, так і на диску.
Коли ви натискаєте кнопку "Додому", iOS знімає знімок поточного екрану, щоб мати можливість здійснити перехід до програми набагато плавніше. Однак, якщо на поточному екрані присутні чутливі дані, вони будуть збережені в зображенні (яке зберігається після перезавантажень). Це знімки, до яких ви також можете отримати доступ, двічі торкнувшись екрану "Додому", щоб перемикатися між програмами.
Якщо iPhone не зламаний, зловмисник повинен мати доступ до пристрою без блокування, щоб побачити ці знімки екрана. За замовчуванням останній знімок зберігається в пісочниці програми в папці Library/Caches/Snapshots/
або Library/SplashBoard/Snapshots
(достовірні комп'ютери не можуть отримати доступ до файлової системи з iOX 7.0).
Один зі способів запобігти цій поганій поведінці - це поставити порожній екран або видалити чутливі дані перед зняттям знімка, використовуючи функцію ApplicationDidEnterBackground()
.
Наступний є прикладом методу усунення, який встановить знімок за замовчуванням.
Swift:
Objective-C:
Це встановлює фонове зображення на overlayImage.png
щоразу, коли додаток переходить у фоновий режим. Це запобігає витоку чутливих даних, оскільки overlayImage.png
завжди перекриває потній вигляд.
Для доступу та управління iOS keychain доступні інструменти, такі як Keychain-Dumper, які підходять для джейлбрейкнутіх пристроїв. Крім того, Objection надає команду ios keychain dump
для подібних цілей.
Клас NSURLCredential ідеально підходить для збереження чутливої інформації безпосередньо в keychain, обходячи необхідність у NSUserDefaults або інших обгортках. Для зберігання облікових даних після входу використовується наступний код Swift:
Щоб витягти ці збережені облікові дані, використовується команда Objection ios nsurlcredentialstorage dump
.
Починаючи з iOS 8.0, користувачі можуть встановлювати розширення користувацьких клавіатур, які можна керувати в Налаштування > Загальні > Клавіатура > Клавіатури. Хоча ці клавіатури пропонують розширену функціональність, вони несуть ризик реєстрації натискань клавіш і передачі даних на зовнішні сервери, хоча користувачі отримують сповіщення про клавіатури, які потребують доступу до мережі. Додатки можуть і повинні обмежувати використання користувацьких клавіатур для введення чутливої інформації.
Рекомендації з безпеки:
Рекомендується вимкнути сторонні клавіатури для підвищення безпеки.
Будьте обережні з функціями автокорекції та автоматичних підказок стандартної клавіатури iOS, які можуть зберігати чутливу інформацію у кеш-файлах, розташованих у Library/Keyboard/{locale}-dynamic-text.dat
або /private/var/mobile/Library/Keyboard/dynamic-text.dat
. Ці кеш-файли слід регулярно перевіряти на наявність чутливих даних. Рекомендується скинути словник клавіатури через Налаштування > Загальні > Скинути > Скинути словник клавіатури для очищення кешованих даних.
Перехоплення мережевого трафіку може виявити, чи передає користувацька клавіатура натискання клавіш віддалено.
Протокол UITextInputTraits пропонує властивості для управління автокорекцією та безпечним введенням тексту, що є важливим для запобігання кешуванню чутливої інформації. Наприклад, вимкнення автокорекції та увімкнення безпечного введення тексту можна досягти за допомогою:
Крім того, розробники повинні забезпечити, щоб текстові поля, особливо ті, що призначені для введення чутливої інформації, такої як паролі та PIN-коди, вимикали кешування, встановивши autocorrectionType
на UITextAutocorrectionTypeNo
та secureTextEntry
на YES
.
Відлагодження коду часто передбачає використання логування. Існує ризик, оскільки логи можуть містити чутливу інформацію. Раніше, в iOS 6 та ранніших версіях, логи були доступні всім додаткам, що створювало ризик витоку чутливих даних. Тепер додатки обмежені у доступі лише до своїх логів.
Незважаючи на ці обмеження, зловмисник з фізичним доступом до розблокованого пристрою все ще може скористатися цим, підключивши пристрій до комп'ютера та прочитавши логи. Важливо зазначити, що логи залишаються на диску навіть після видалення додатка.
Щоб зменшити ризики, рекомендується ретельно взаємодіяти з додатком, досліджуючи всі його функціональні можливості та введення, щоб переконатися, що жодна чутлива інформація не записується ненавмисно.
При перегляді вихідного коду додатка на предмет потенційних витоків, шукайте як попередньо визначені, так і кастомні логуючі оператори, використовуючи ключові слова, такі як NSLog
, NSAssert
, NSCAssert
, fprintf
для вбудованих функцій, а також будь-які згадки про Logging
або Logfile
для кастомних реалізацій.
Додатки записують різні фрагменти інформації, які можуть бути чутливими. Для моніторингу цих логів використовують інструменти та команди, такі як:
корисні. Додатково, Xcode надає спосіб збору консолі логів:
Відкрийте Xcode.
Підключіть iOS пристрій.
Перейдіть до Window -> Devices and Simulators.
Виберіть ваш пристрій.
Викличте проблему, яку ви досліджуєте.
Використовуйте кнопку Open Console, щоб переглянути логи в новому вікні.
Для більш просунутого логування, підключення до оболонки пристрою та використання socat може забезпечити моніторинг логів в реальному часі:
Слід за командами для спостереження за активністю журналів, що може бути безцінним для діагностики проблем або виявлення потенційних витоків даних у журналах.
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:
Функції автоматичного резервного копіювання інтегровані в iOS, що полегшує створення копій даних пристрою через iTunes (до macOS Catalina), Finder (з macOS Catalina і далі) або iCloud. Ці резервні копії охоплюють майже всі дані пристрою, за винятком дуже чутливих елементів, таких як деталі Apple Pay та налаштування Touch ID.
Включення встановлених додатків та їх даних у резервні копії піднімає питання потенційного витоку даних та ризик того, що модифікації резервних копій можуть змінити функціональність додатків. Рекомендується не зберігати чутливу інформацію у відкритому вигляді в будь-якому каталозі додатка або його підкаталогах, щоб зменшити ці ризики.
Файли в Documents/
та Library/Application Support/
за замовчуванням резервуються. Розробники можуть виключити конкретні файли або каталоги з резервних копій, використовуючи NSURL setResourceValue:forKey:error:
з NSURLIsExcludedFromBackupKey
. Ця практика є важливою для захисту чутливих даних від включення в резервні копії.
Щоб оцінити безпеку резервного копіювання додатка, почніть з створення резервної копії за допомогою Finder, а потім знайдіть її, скориставшись вказівками з офіційної документації Apple. Проаналізуйте резервну копію на наявність чутливих даних або конфігурацій, які можуть бути змінені для впливу на поведінку додатка.
Чутливу інформацію можна шукати за допомогою інструментів командного рядка або програм, таких як iMazing. Для зашифрованих резервних копій наявність шифрування можна підтвердити, перевіривши ключ "IsEncrypted" у файлі "Manifest.plist" в корені резервної копії.
Для роботи з зашифрованими резервними копіями можуть бути корисні скрипти Python, доступні в репозиторії DinoSec на GitHub, такі як backup_tool.py та backup_passwd.py, хоча вони можуть вимагати коригувань для сумісності з останніми версіями iTunes/Finder. Іншим варіантом для доступу до файлів у захищених паролем резервних копіях є iOSbackup.
Приклад зміни поведінки додатка через модифікацію резервних копій продемонстровано в додатку Bither bitcoin wallet, де PIN-код блокування UI зберігається в net.bither.plist
під ключем pin_code. Видалення цього ключа з plist і відновлення резервної копії усуває вимогу PIN-коду, надаючи необмежений доступ.
При роботі з чутливою інформацією, що зберігається в пам'яті додатка, важливо обмежити час експозиції цих даних. Існує два основних підходи для дослідження вмісту пам'яті: створення дампа пам'яті та аналіз пам'яті в реальному часі. Обидва методи мають свої виклики, включаючи можливість пропустити критично важливі дані під час процесу дампа або аналізу.
Для пристроїв з джейлбрейком і без нього інструменти, такі як objection та Fridump, дозволяють створювати дамп пам'яті процесу додатка. Після створення дампа аналіз цих даних вимагає різних інструментів, залежно від природи інформації, яку ви шукаєте.
Щоб витягти рядки з дампа пам'яті, можна використовувати команди, такі як strings
або rabin2 -zz
:
Для більш детального аналізу, включаючи пошук конкретних типів даних або шаблонів, radare2 пропонує розширені можливості пошуку:
r2frida надає потужну альтернативу для перевірки пам'яті програми в реальному часі, без необхідності в дампі пам'яті. Цей інструмент дозволяє виконувати команди пошуку безпосередньо в пам'яті запущеного додатку:
Деякі розробники зберігають чутливі дані у локальному сховищі та шифрують їх за допомогою ключа, закодованого в коді. Це не слід робити, оскільки деяке реверсування може дозволити зловмисникам витягти конфіденційну інформацію.
Розробники не повинні використовувати застарілі алгоритми для виконання перевірок авторизації, зберігання або відправки даних. Деякі з цих алгоритмів: RC4, MD4, MD5, SHA1... Якщо хеші використовуються для зберігання паролів, наприклад, слід використовувати хеші, стійкі до брутфорсу з сіллю.
Основні перевірки, які потрібно виконати, це знайти, чи можна знайти жорстко закодовані паролі/секрети в коді, або чи вони передбачувані, і чи використовує код якісь слабкі криптографічні алгоритми.
Цікаво знати, що ви можете моніторити деякі крипто бібліотеки автоматично, використовуючи objection з:
Для додаткової інформації про криптографічні API та бібліотеки iOS зверніться до https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography
Локальна аутентифікація відіграє важливу роль, особливо коли йдеться про захист доступу до віддаленого кінцевого пункту за допомогою криптографічних методів. Суть полягає в тому, що без належної реалізації механізми локальної аутентифікації можуть бути обійдені.
Фреймворк Local Authentication від Apple та keychain надають надійні API для розробників, щоб полегшити діалоги аутентифікації користувачів та безпечно обробляти секретні дані відповідно. Secure Enclave захищає ідентифікацію за відбитком пальця для Touch ID, тоді як Face ID покладається на розпізнавання обличчя без компрометації біометричних даних.
Щоб інтегрувати Touch ID/Face ID, розробники мають два варіанти API:
LocalAuthentication.framework
для високорівневої аутентифікації користувачів без доступу до біометричних даних.
Security.framework
для доступу до сервісів keychain нижчого рівня, що забезпечує захист секретних даних за допомогою біометричної аутентифікації. Різні open-source обгортки спрощують доступ до keychain.
Однак, як LocalAuthentication.framework
, так і Security.framework
мають вразливості, оскільки вони в основному повертають булеві значення без передачі даних для процесів аутентифікації, що робить їх вразливими до обходу (див. Don't touch me that way, by David Lindner et al).
Щоб запитати користувачів про аутентифікацію, розробники повинні використовувати метод evaluatePolicy
у класі LAContext
, вибираючи між:
deviceOwnerAuthentication
: Запитує Touch ID або код доступу до пристрою, не вдаючись, якщо жоден з них не активовано.
deviceOwnerAuthenticationWithBiometrics
: Виключно запитує Touch ID.
Успішна аутентифікація вказується булевим значенням, повернутим з evaluatePolicy
, що підкреслює потенційну вразливість безпеки.
Реалізація локальної аутентифікації в iOS-додатках передбачає використання keychain API для безпечного зберігання секретних даних, таких як токени аутентифікації. Цей процес забезпечує доступ до даних лише для користувача, використовуючи їх код доступу до пристрою або біометричну аутентифікацію, таку як Touch ID.
Keychain пропонує можливість встановлювати елементи з атрибутом SecAccessControl
, який обмежує доступ до елемента, поки користувач не пройде успішну аутентифікацію через Touch ID або код доступу до пристрою. Ця функція є важливою для підвищення безпеки.
Нижче наведені приклади коду на Swift та Objective-C, які демонструють, як зберігати та отримувати рядок з keychain, використовуючи ці функції безпеки. Приклади конкретно показують, як налаштувати контроль доступу, щоб вимагати аутентифікацію Touch ID та забезпечити доступність даних лише на пристрої, на якому вони були налаштовані, за умови, що код доступу до пристрою налаштовано.
Тепер ми можемо запитати збережений елемент з ключниці. Служби ключниці відобразять діалог аутентифікації для користувача та повернуть дані або nil в залежності від того, чи було надано відповідний відбиток пальця.
Використання фреймворків в додатку також можна виявити, аналізуючи список спільних динамічних бібліотек бінарного файлу додатку. Це можна зробити за допомогою otool
:
Якщо в додатку використовується LocalAuthentication.framework
, вихід міститиме обидві наступні рядки (пам'ятайте, що LocalAuthentication.framework
використовує Security.framework
під капотом):
Якщо використовується Security.framework
, буде показано лише другий варіант.
Через Objection Biometrics Bypass, розташований на цій сторінці GitHub, доступна техніка для подолання механізму LocalAuthentication. Суть цього підходу полягає в використанні Frida для маніпуляції функцією evaluatePolicy
, що забезпечує постійний результат True
, незалежно від фактичного успіху аутентифікації. Це особливо корисно для обходу ненадійних процесів біометричної аутентифікації.
Щоб активувати цей обхід, використовується наступна команда:
Ця команда запускає послідовність, де Objection реєструє завдання, яке ефективно змінює результат перевірки evaluatePolicy
на True
.
Приклад використання evaluatePolicy
з DVIA-v2 application:
Щоб досягти bypass локальної аутентифікації, написано скрипт Frida. Цей скрипт націлений на перевірку evaluatePolicy, перехоплюючи її зворотний виклик, щоб забезпечити повернення success=1. Змінюючи поведінку зворотного виклику, перевірка аутентифікації ефективно обходиться.
Скрипт нижче інжектується для зміни результату методу evaluatePolicy. Він змінює результат зворотного виклику, щоб завжди вказувати на успіх.
Щоб впровадити скрипт Frida та обійти біометричну аутентифікацію, використовується наступна команда:
Важливо перевірити, що жодна комунікація не відбувається без шифрування і що додаток правильно перевіряє TLS сертифікат сервера. Щоб перевірити ці проблеми, ви можете використовувати проксі, наприклад, Burp:
iOS Burp Suite ConfigurationОднією з поширених проблем при перевірці TLS сертифіката є перевірка, що сертифікат був підписаний достовірним ЦС, але не перевіряється, чи ім'я хоста сертифіката є іменем хоста, до якого звертаються. Щоб перевірити цю проблему за допомогою Burp, після довірення Burp CA на iPhone, ви можете створити новий сертифікат з Burp для іншого імені хоста і використовувати його. Якщо додаток все ще працює, то щось є вразливим.
Якщо додаток правильно використовує SSL Pinning, то додаток буде працювати лише якщо сертифікат є тим, що очікується. При тестуванні додатка це може бути проблемою, оскільки Burp буде надавати свій власний сертифікат. Щоб обійти цю захист на джейлбрейкнутому пристрої, ви можете встановити додаток SSL Kill Switch або встановити Burp Mobile Assistant
Ви також можете використовувати objection's ios sslpinning disable
У /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/*
ви можете знайти знімок, виконаний для додатку перед відправленням його у фоновий режим.
Розробники можуть віддалено поправити всі установки свого додатку миттєво без необхідності повторно подавати додаток до App Store і чекати, поки його затвердять. Для цієї мети зазвичай використовують JSPatch. Але є й інші варіанти, такі як Siren та react-native-appstore-version-checker. Це небезпечний механізм, який може бути зловжито зловмисними сторонніми SDK, тому рекомендується перевірити, який метод використовується для автоматичного оновлення (якщо є) та протестувати його. Ви можете спробувати завантажити попередню версію додатку для цієї мети.
Суттєвою проблемою з 3rd party SDKs є відсутність детального контролю над їх функціональністю. Розробники стикаються з вибором: або інтегрувати SDK і прийняти всі його функції, включаючи потенційні вразливості безпеки та проблеми з конфіденційністю, або зовсім відмовитися від його переваг. Часто розробники не можуть виправити вразливості в цих SDK самостійно. Більше того, оскільки SDK отримують довіру в спільноті, деякі з них можуть почати містити шкідливе ПЗ.
Послуги, що надаються сторонніми SDK, можуть включати відстеження поведінки користувачів, показ реклами або покращення користувацького досвіду. Однак це створює ризик, оскільки розробники можуть не бути повністю обізнані про код, що виконується цими бібліотеками, що призводить до потенційних ризиків конфіденційності та безпеки. Важливо обмежити інформацію, що передається стороннім службам, до необхідного та забезпечити, щоб жодні чутливі дані не були розкриті.
Впровадження сторонніх послуг зазвичай відбувається у двох формах: окрема бібліотека або повний SDK. Щоб захистити конфіденційність користувача, будь-які дані, що передаються цим службам, повинні бути анонімізовані, щоб запобігти розкриттю особистої ідентифікаційної інформації (PII).
Щоб визначити бібліотеки, які використовує додаток, можна використовувати команду otool
. Цей інструмент слід запустити проти додатку та кожної спільної бібліотеки, яку він використовує, щоб виявити додаткові бібліотеки.
OWASP iGoat https://github.com/OWASP/igoat <<< Версія Objective-C https://github.com/OWASP/iGoat-Swift <<< Версія Swift
Використовуйте Trickest для легкого створення та автоматизації робочих процесів, підтримуваних найсучаснішими інструментами спільноти. Отримайте доступ сьогодні:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вчіться та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)