Ви отримуєте повідомлення в Signal від людини, якій довіряєте. У ньому — посилання на нову версію службового мобільного застосунку. Сайт виглядає справжнім: знайомий логотип, офіційний дизайн, кнопка «Завантажити». Ви встановлюєте APK, погоджуєтеся з кількома запитами на доступ і повертаєтеся до роботи.
У цей момент зловмиснику вже не потрібно експлуатувати складні вразливості, обходити фаєрволи чи ламати сервери. Він досяг своєї мети значно простішим шляхом — переконавши користувача встановити шкідливий застосунок власноруч.
Саме за таким принципом навесні 2024 року діяла одна з кампаній, зафіксованих державною командою реагування на комп'ютерні інциденти України CERT-UA спільно з підрозділом реагування на кіберінциденти при Центрі кіберзахисту Міноборони MILCERT.
Через Signal поширювалися посилання на підроблені сторінки застосунків GRISELDA та «Очі», які пропонували завантажити нібито офіційну мобільну версію. Технічні деталі роботи шкідливого ПЗ для нас неважливі, однак сама атака добре демонструє головну думку цього тексту: сьогодні мобільний застосунок є повноцінною поверхнею атаки, а його компрометація часто починається не з сервера, а з пристрою користувача.
Саме тому mobile application security testing (тестування безпеки мобільних застосунків) давно перестало бути додатком до веб пентесту. Системи Android та iOS мають власну модель загроз, власні механізми захисту й абсолютно різний набір типових проблем. І саме тому мобільний пентест — це окрема дисципліна зі своїми методиками, інструментами та стандартами, зокрема OWASP MASVS.
У цій статті ми розглянемо специфіку Android і iOS, стандарт OWASP MASVS та те, що саме шукають під час мобільного пентесту.
Чим mobile application penetration testing відрізняється від пентесту вебзастосунку
Якщо у вебзастосунку весь код виконується на сервері, а клієнту дістається лише HTML/JS, який більш-менш можна вважати «недовіреним за замовчуванням», то мобільний застосунок — це зовсім інша історія. Значна частина логіки виконується локально, на пристрої користувача, який фізично перебуває поза вашим контролем.
Це означає, що зловмисник отримує доступ до речей, яких у вебі просто немає:
- повний бінарний файл застосунку (APK або IPA), який можна декомпілювати й читати логіку;
- локальне сховище на пристрої — бази даних SQLite, файли конфігурацій, кеш;
- можливість підключити налагоджувач, підмінити системні виклики, обійти перевірки прямо під час роботи застосунку;
- фізичний контроль над пристроєм — root на Android чи jailbreak на iOS, що знімає майже весь захист на стороні застосунку.
Тобто мобільний пентест — це завжди комбінація трьох напрямків: статичний аналіз коду (читаємо код, не запускаючи застосунок), динамічний аналіз (запускаємо, перехоплюємо трафік, перехоплюємо виклики функцій прямо під час роботи застосунку) і тестування бекенд-API, з яким застосунок спілкується — а це, по суті, той самий вебпентест, тільки з мобільним клієнтом замість браузера.
OWASP MASVS (Mobile Application Security Verification Standard): основа безпеки
Так само як у вебпентесті є OWASP Top 10, у мобільному світі панує OWASP Mobile фреймворк, а саме OWASP Mobile Application Security Verification Standard (MASVS), доповнений практичним посібником MASTG (Mobile Application Security Testing Guide), який раніше називався MSTG.
MASVS — це не список вразливостей, а список вимог до безпечного застосунку, згрупованих у категорії. MASTG — це вже конкретні тест-кейси для перевірки кожної вимоги, з покроковими інструкціями та інструментами.
Розберемо групи контролів MASVS по суті.
MASVS-STORAGE — зберігання даних
Найпопулярніша категорія знахідок у реальних звітах. Перевіряється, чи не зберігає застосунок чутливі дані у відкритому вигляді: паролі й токени у SharedPreferences (Android) чи plist/UserDefaults (iOS) без шифрування, персональні дані в SQLite-базах без захисту, залишки чутливої інформації в кеші клавіатури та скріншотах багатозадачності (той самий «знімок екрана» iOS, що показується при згортанні застосунку, — і на ньому раптом видно номер карти). Сюди ж належать логи: застосунок радісно пише в них чутливі дані, а Logcat доступний будь-якому додатку з відповідним дозволом на застарілих версіях Android.
MASVS-CRYPTO — криптографія
Тут шукають не «чи використовується шифрування взагалі», а чи використовується воно правильно: чи немає саморобних алгоритмів шифрування замість перевірених бібліотек, чи не використовуються застарілі примітиви (ECB-режим, MD5/SHA1 для чутливих операцій, жорстко зашитий IV), чи ключі шифрування зберігаються не поруч із самими зашифрованими даними (бо шифрування з ключем в тому ж файлі — це просто кодування, а не захист).
MASVS-AUTH — автентифікація та управління сесіями
Локальна автентифікація (PIN, біометрія) перевіряється окремо від серверної. Ключове питання: чи біометрія дійсно захищає доступ до чутливих даних, чи це просто UI-заглушка, яку можна обійти, викликавши потрібний Activity/ViewController напряму, минаючи екран блокування. Також перевіряється логіка сесій, тобто правил авторизації: чи інвалідується (анулюється) цифровий токен-перепустка на сервері при виході з акаунта, чи можна перевикористати цей токен після зміни пароля, і чи є прив'язка сесії до конкретного пристрою.
MASVS-NETWORK — мережева взаємодія
Перевіряється коректність TLS: чи немає застосунків, які довіряють будь-якому сертифікату (класична помилка з TrustManager, який ігнорує помилки валідації — і так, вона досі трапляється). Також перевіряється, чи реалізований certificate/public key pinning — тобто жорстка прив'язка додатка до конкретного ключа вашого сервера, щоб унеможливити підміну трафіку там, де це виправдано. І, що важливо для пентестера, — чи можна цей pinning обійти (про це нижче, в динамічному аналізі).
MASVS-PLATFORM — взаємодія з платформою
Це специфічно платформні механізми: на Android — коректність налаштування Intent, Broadcast Receivers, Content Providers (чи не експортовані вони випадково назовні, дозволяючи іншому застосунку на пристрої втручатися в роботу), робота з WebView (чи увімкнений JavaScript-міст без потреби, чи можна завантажити довільний URL). На iOS — коректність обробки Custom URL Schemes і Universal Links, які можуть стати вектором для міжзастосункових атак.
MASVS-CODE — якість і захищеність коду
Чи використовуються застарілі, вразливі бібліотеки (той самий SCA — Software Composition Analysis, тільки для мобільного світу), чи є в коді налагоджувальний функціонал, забутий у робочій (реліз) збірці, чи коректно обробляються помилки без розкриття внутрішньої структури застосунку.
MASVS-RESILIENCE — стійкість до реверс-інжинірингу і тамперингу
Це найцікавіша й найбільш «мобільно-специфічна» категорія, аналогу якої немає в вебпентесті. Сюди входить: чи є обфускація коду, тобто його навмисне ускладнення, щоб було важче прочитати (і наскільки вона реально ускладнює аналіз, а не просто перейменовує змінні в a, b, c), чи є детекція root/jailbreak і наскільки легко вона обходиться, чи є детекція запущеного дебагера чи інструментів на кшталт Frida, чи перевіряється цілісність застосунку (anti-tampering, перевірка підпису під час роботи застосунку).
Важливий нюанс, яким часто нехтують продуктові менеджери: контроли з MASVS-RESILIENCE не є заміною серверної безпеки. Це ускладнення для зловмисника, а не бар'єр. Якщо вся ваша модель безпеки покладається на те, що обфускація зупинить реверс-інжиніринг — у вас проблема, а не фіча.
Android application security: як проводиться пентест під Android
Статичний аналіз коду
Все починається з розбору APK — коли пентестер за допомогою спеціальних утиліт (apktool, jadx) розпаковує додаток і вивчає його головний конфігураційний файл AndroidManifest.xml.
Тут одразу видно базові вразливості:
- чи є небезпечно експортовані компоненти (exported="true" без перевірки прав) — тобто екрани, які інші програми можуть відкривати напряму;
- чи дозволений бекап застосунку (allowBackup="true"), що дозволяє витягнути приватні дані додатка через командний рядок (adb backup) навіть без права суперкористувача (root);
- чи не залишено режим розробника (debuggable="true") у релізній збірці, що дає змогу стороннім підключатися до внутрішніх процесів додатка.
Далі читають внутрішній код додатка (Java/Kotlin або його низькорівневу версію Smali, якщо відновити звичайний код не вдалося). У ньому шукають критичні помилки: хардкод-секрети (вшиті прямо в код паролі та ключі доступу), слабке шифрування (ненадійні способи захисту даних) та небезпечні команди на кшталт Runtime.exec(), які дозволяють введеному користувачем тексту виконувати прямі вказівки в операційній системі та запускати шкідливий код.
Динамічний аналіз
Тут у гру вступають інструменти на кшталт Frida та Objection — фреймворки для динамічної інструментації, які дозволяють перехоплювати виклики функцій прямо під час роботи застосунку без перекомпіляції. Це дає можливість обійти перевірку на root (підмінивши результат функції перевірки на «пристрій чистий»), обійти SSL pinning (щоб перехопити й проаналізувати трафік через проксі на кшталт Burp Suite, навіть якщо застосунок за замовчуванням цьому противиться), чи витягти розшифровані дані прямо з пам'яті процесу в момент, коли вони вже дешифровані для використання.
Це саме той момент, де мобільний пентест перестає бути «просто читанням коду» і стає справжнім зламом у реальному часі — застосунок думає, що з ним усе гаразд, а насправді половина того, що відбувається під час роботи застосунку, вже під контролем пентестера.
Особливості тестування під операційну систему iOS
Екосистема Apple історично вважається «безпечнішою за замовчуванням» завдяки суворішій пісочниці й контролю App Store, але це не означає, що там нема чого шукати — просто вектори інші.
IPA-файл розпаковують так само, як APK. Усередині лежить скомпільований код застосунку — «бінарник», який не можна просто відкрити і прочитати, як текст. Щоб зрозуміти, як застосунок влаштований зсередини, не маючи вихідного коду, його «розкривають» спеціальними програмами-аналізаторами — class-dump або Hopper/IDA. Вони показують структуру класів, тобто з яких частин і функцій складається застосунок. І головна думка тут проста: на iOS зробити це насправді легше, ніж здається. Мова Objective-C, якою часто пишуть iOS-застосунки, залишає в скомпільованому файлі багато «підказок» про його внутрішню будову — назви класів, методів тощо, які розробник, найпевніше, волів би приховати. Через це реверс-інжиніринг (спроба зрозуміти, як влаштована програма, без доступу до вихідного коду) на iOS виявляється простішим, ніж багато хто думає.
Також перевіряють Keychain — це сховище на iOS, де застосунки зберігають паролі, токени та інші секрети. Вважається, що воно «безпечне за задумом», але на практиці розробники часто налаштовують його неправильно. Два типові приклади: дані записують так, що їх можна прочитати навіть коли телефон заблокований, або записи в Keychain не видаляються разом із застосунком — і якщо потім встановити застосунок на той самий пристрій знову, старі паролі й токени нікуди не діваються, вони просто чекають там.
Крім того, перевіряють App Transport Security (ATS) — це механізм iOS, який за замовчуванням вимагає, щоб усі з'єднання застосунку були зашифровані (по HTTPS, а не по звичайному HTTP). Проблема в тому, що цю вимогу можна вимкнути одним рядком у налаштуваннях застосунку (NSAllowsArbitraryLoads: true). Розробники іноді так і роблять, якщо їм не хочеться розбиратися з сертифікатом, — і тоді застосунок знову передає дані відкрито, не зашифровано.
Динамічне тестування на iOS теж робиться через Frida (той самий інструмент, що й для Android), але тут є нюанс: Frida потребує пристрій зі знятими обмеженнями (jailbreak). Якщо такого пристрою немає, є обхідний шлях — переупакувати застосунок так, щоб потрібний для Frida компонент був вбудований прямо всередину. І перевіряють те саме, що й на Android: чи можна обійти захист від jailbreak, чи можна перехопити трафік, чи можна зазирнути в пам'ять процесу, поки застосунок працює.
Тестування бекенд API — та сама історія, що й у вебі
Важливо розуміти: більшість «мобільних» вразливостей насправді ховаються не в самому застосунку, а в API — наборі команд, за якими застосунок спілкується з сервером. Мобільний застосунок — це просто один із способів звернутися до цього API. Той самий сервер із тим самим набором команд можна викликати і напряму, іншими програмами для надсилання запитів (наприклад, Postman чи curl), якщо у вас є перехоплений запит із застосунку.
Тому повноцінний мобільний пентест обов'язково включає той самий набір перевірок, що й веб пентест API: Broken Access Control, IDOR, mass assignment, слабка авторизація на рівні окремих ендпоінтів. Різниця лише в тому, що знайти ці ендпоінти складніше — вони не задокументовані публічно, і їх треба спершу витягнути через перехоплення трафіку динамічного аналізу. Але щойно ендпоінт знайдено — далі це вже класична робота пентестера вебдодатків.
Найпоширеніші знахідки: коротка практична вибірка
- Хардкод секретів у бінарнику — це коли прямо у зібраний код додатка «зашивають» конфіденційні дані: секретні API-ключі, ключі доступу до сторонніх сервісів або навіть тестові паролі адміністратора, які розробники залишили для зручності тестування та забули видалити перед випуском.
- Незашифровані локальні бази даних з персональними даними, повідомленнями чи історією транзакцій — щоб прочитати всі ці секретні дані, зловмиснику достатньо просто скопіювати файл SQLite і відкрити його будь-яким безкоштовним переглядачем.
- Слабкий або відсутній SSL pinning (Network Security), що дозволяє перехопити весь трафік (здійснити MITM-атаку) у незахищеній Wi-Fi-мережі (так, «безкоштовний Wi-Fi у кав'ярні» досі лишається робочим вектором атаки — це не міф з 2012 року).
- Небезпечно експортовані Android-компоненти, через які інший застосунок на тому ж пристрої може викликати функціонал вашого застосунку в обхід очікуваного сценарію використання.
- Логіка «довіри клієнту» — коли перевірка прав, ціни товару чи ліміту доступу відбувається на стороні застосунку, а бекенд просто приймає те, що йому надіслали.
- Debug-функціонал у релізній збірці — тестові ендпоінти, меню розробника та інші функції, залишені «тимчасово».
Скільки триває мобільний пентест
Мобільний пентест зазвичай триває довше, ніж такий самий тест вебзастосунку. Причина проста: тут додається окрема робота — розбір самого файлу застосунку (те, про що йшлося вище: статичний і динамічний аналіз бінарника), а вже поверх цього ще й перевірка API, з яким застосунок спілкується.
Класичні орієнтовні терміни, якщо йдеться про традиційний ручний пентест: невеликий застосунок з базовим функціоналом — 5–7 робочих днів; застосунок середньої складності, з власним API та кількома ролями користувачів — 2–3 тижні. Якщо потрібно перевірити обидві платформи, і Android, і iOS, окремо, — додайте ще 30–50% часу. Це майже два незалежні тести: сервер, з яким спілкуються обидва застосунки, спільний, а от усе, що специфічне саме для платформи (Android чи iOS), доводиться перевіряти окремо для кожної.
Проте із розвитком ШІ в кібербезпеці, терміні проведення перевірок драматично скоротились, і більше немає потреби чекати на результати днями або тижнями, а отже, відкладати релізи через питання безпеки, або безпеку — через потребу випускати застосунки швидше.
Як підготуватися до пентесту мобільного застосунку
Що варто підготувати заздалегідь:
- Debug-збірку без обфускації (або мапінг символів для обфускованої) — це суттєво пришвидшує статичний аналіз і не змінює якість результату, бо обфускація сповільнює аналіз, а не робить його неможливим.
- Тестові облікові записи різних ролей, як і для вебпентесту.
- Пристрій з можливістю root/jailbreak або офіційно підтримувані шляхи для динамічного аналізу — якщо тест проводиться на реальному пристрої клієнта без цих можливостей, частина MASVS-RESILIENCE перевірок буде обмежена.
- Документація API, яким користується застосунок, — це необов'язково (пентестер витягне ендпоінти з трафіку в будь-якому разі), але економить час.
Детальніше про те, як підготуватись до пентестів веб застосунків ми розповідали тут.
Як AI змінює мобільний пентест
Тут варто бути чесним: повноцінний реверс-інжиніринг мобільного бінарника — це саме та область, де повна автоматизація поки що не працює так гладко, як хотілося б. Розуміння того, чому саме ця функція в декомпільованому Smali-коді відповідає за перевірку root і як конкретно обійти цю перевірку під час роботи застосунку через Frida, — це задача, яка вимагає контексту, здогадок і експериментів, а не просто розпізнавання шаблону. Динамічна інструментація, обхід anti-tampering — усе це поки що значною мірою залишається територією людської експертизи.
Але є частина роботи, яка автоматизується вже зараз, і автоматизується добре — статичний аналіз коду, тобто SAST (Static Application Security Testing), адаптований під мобільну методологію OWASP MASTG/MASVS. Наприклад, це AI SAST від А42.
Головна перевага AI SAST від А42 у тому, що він дозволяє виявляти частину проблем ще на етапі розробки, тобто до виходу коду в продакшн, адже саме сканування займає лічені хвилини. AI SAST проходить по декомпільованому коду застосунку систематично й безперервно: шукає хардкод-секрети, небезпечні криптографічні примітиви, експортовані компоненти без перевірок, ризиковані виклики API платформи. Усе те, що в класичному пентесті займає перші кілька годин ручного читання коду, перш ніж пентестер взагалі дістається до цікавих речей.
Різниця з класичним статичним сканером (regex по коду): AI-модель аналізує контекст використання API, що дозволяє зменшити кількість хибнопозитивних результатів. Вона відрізнить реальний робочий ключ від тестового зразка (заглушки) в юніт-тестах, побачить, що конкретний TrustManager дійсно ігнорує помилки валідації сертифіката, а не просто містить слово «trust» у назві класу — і це прибирає той шар «шуму», на який традиційно страждають автоматизовані сканери мобільної безпеки.
Практичний результат: AI SAST проходить через кожну нову збірку застосунку, яку публікує команда, і фіксує регресії — наприклад, якщо новий реліз випадково повернув TrustManager, який виглядає валідним, але насправді глушить перевірку ланцюга сертифікатів. Класичний пентест, що проводиться раз на рік, такого не помітить до наступного циклу. AI SAST помітить одразу після наступної збірки.
Це не робить ручний мобільний пентест непотрібним — глибокий динамічний аналіз, обхід кастомного anti-tampering, дослідження нестандартної бізнес-логіки досі вимагають досвідченого пентестера. Але поєднання AI SAST для статичної частини й періодичного mobile pentesting для динамічної та архітектурної частини дає значно повніше й актуальніше покриття, ніж будь-який з підходів окремо.
Як почати користуватися AI SAST
AI SAST доступний безоплатно всім користувачам платформи A42 Recon+Exposure, навіть у межах тріал-версії. Почати сканування можна одразу й без складних технічних налаштувань: достатньо зайти в розділ AI SAST у дашборді A42, завантажити код (через посилання на Git-репозиторій або ZIP-архівом) і натиснути «Scan».
Якщо ви ще не є користувачем платформи, запросити тріал-доступ можна, залишивши заявку у формі зворотного зв'язку або забронювавши ознайомчий дзвінок із технічною командою А42.
