Як тестують захищені мобільні додатки: робимо обхід SSL pinning

Навіщо взагалі сніфати мобільні додатки? Уявіть ситуацію: ви намагаєтесь проаналізувати API, спарсити дані або знайти вразливість на сайті популярного сервісу. Але там вас миттєво блокує Cloudflare, змушують розгадувати капчу, а за зайвий запит банить якийсь rate limiter або WAF. Захист сучасних веб-сайтів зазвичай вибудований дуже щільно.

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

• Немає CAPTCHA на формах логіну чи реєстрації.
• Відсутні або значно слабші ліміти на кількість запитів (Rate Limiting), що відкриває шлях для брутфорсу або масового парсингу.
• Залишаються старі вразливості (наприклад, IDOR), які на веб-версії давно закрили.

Тому для хакера або багхантера мобільний додаток - це ідеальний чорний хід до серверів та баз даних компанії. Але щоб цей трафік побачити, треба спочатку обійти головного охоронця - SSL Pinning.

Перехоплюємо весь трафік телефона

В нашому відео здебільшого для таких задач використовуєм Burp Suite (можна використовувати любий сніфер). Переходимо Proxy -> Proxy Settings -> Edit по проксі і ставимо прослуховування всіх інтерфейсів.

У тому ж вікні налаштувань натискаємо Import / Export CA certificate -> вибираємо Certificate in DER format, називаємо його (наприклад, burp.der) і зберігаємо на комп'ютер.

Налаштовуємо проксі та сертифікат

Щоб телефон почав відправляти трафік через наш Burp Suite, а ми могли розшифровувати HTTPS-запити, потрібно виконати два кроки:

• Направляємо трафік на комп'ютер (Проксі): Обидва пристрої (ПК і телефон) мають бути в одній Wi-Fi мережі. На телефоні заходимо в налаштування Wi-Fi, натискаємо на нашу мережу і вибираємо налаштування проксі-сервера ("Вручну"). У полі IP-адреси вписуємо локальну IP-адресу вашого комп'ютера (наприклад, 192.168.1.100), а в поле порт — той, що вказали в Burp (зазвичай 8080).
• Встановлюємо сертифікат Burp: Відправляємо збережений раніше файл burp.der на телефон (через USB, Telegram "Збережене" або будь-яким іншим способом). Є й швидший хак: після налаштування проксі просто відкрийте браузер на телефоні і перейдіть за адресою http://burp — там буде кнопка CA Certificate для прямого завантаження.

Далі йдемо в налаштування телефону — Certificate в пошуку — CA Certificate (назви меню можуть відрізнятися залежно від телефона). Вибираємо наш сертифікат і встановлюємо його.

Чому цього недостатньо?

Здавалося б, усе готово. Трафік іде через проксі, сертифікат встановлено. Якщо ви зараз відкриєте браузер на телефоні і зайдете на будь-який сайт — ви побачите всі запити в Burp Suite.

Але якщо ви відкриєте наш цільовий мобільний додаток, то, найімовірніше, побачите помилку підключення до мережі. Чому так? Річ у тім, що починаючи з Android 7.0, компанія Google запровадила суворе правило: додатки за замовчуванням більше не довіряють сертифікатам, які встановив користувач. Вони довіряють лише системним сертифікатам, вшитим у саму операційну систему.

Крім того, розробники часто додають той самий SSL Pinning — жорстко прописують хеш свого серверного сертифіката прямо в код додатка. Додаток дивиться на наш сертифікат від Burp, розуміє, що це "підробка", і відрубує зв'язок.

Саме тому нам потрібно витягнути цей додаток, "розпакувати" його, змінити налаштування безпеки, змусити довіряти нашому сертифікату і зібрати назад. Тут на сцену виходять інструменти ADB та Apktool.

Обходимо SSL Pinning

Підключаємо мобілку до ПК (якщо це ще не зроблено), запускаємо adb. Знаходимо шлях до додатку:

bash./adb shell pm path com.назва_апки.android

Додаток, який ми вибрали, використовує Android App Bundle — це не один APK файл, а кілька, тому витягуємо їх:

bashmkdir app_patched && cd app_patched

# Витягнути потрібні файли (підставити актуальний шлях з попередньої команди)
./adb pull /data/app/~~XXXX==/com.app.android-XXXX==/base.apk
./adb pull /data/app/~~XXXX==/com.app.android-XXXX==/split_config.arm64_v8a.apk
./adb pull /data/app/~~XXXX==/com.app.android-XXXX==/split_config.en.apk
./adb pull /data/app/~~XXXX==/com.app.android-XXXX==/split_config.xxhdpi.apk

Декодуємо через apktool:

bashjava -Xmx4g -jar /path/to/apktool.jar d base.apk -o base_decoded -f --no-src

Перевіряємо Network Security Config:

bashgrep -n "networkSecurityConfig" base_decoded/AndroidManifest.xml

Якщо є @xml/nsc_mitm - створити файл конфігу:

bashcat > base_decoded/res/xml/nsc_mitm.xml << 'EOF'
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
  <base-config cleartextTrafficPermitted="true">
    <trust-anchors>
      <certificates src="system"/>
      <certificates src="user"/>
    </trust-anchors>
  </base-config>
</network-security-config>
EOF

Якщо атрибута немає взагалі — додати вручну в тег в AndroidManifest.xml:

xml<application android:networkSecurityConfig="@xml/nsc_mitm" ...>

Перепаковуємо:

bashjava -Xmx4g -jar /path/to/apktool.jar b base_decoded -o base_patched.apk -f

Підписуємо (uber-apk-signer):

bashjava -jar ../uber-apk-signer.jar --apks base_patched.apk split_config.armeabi_v7a.apk split_config.uk.apk split_config.xxhdpi.apk

Встановлюємо:

bash./adb uninstall com.app.android

# Встановити патчений разом зі split APK
./adb install-multiple base_patched-aligned-debugSigned.apk \
  split_config.arm64_v8a.apk \
  split_config.en.apk \
  split_config.xxhdpi.apk

Відкриваємо, PROFIT!