У статті розглянемо як перехопити HTTPS трафік вашого iPhone.
Що таке FoodSniffer
Для досліду будемо використовувати простий iOS застосунок FoodSniffer. Основна його функція — надання користувачеві списку продуктів, страв та напоїв для споживання протягом дня.
Застосунок отримує від сервера JSON, який виглядає так:
[
{
"name" : "soup",
"consumePeriod" : "morning"
},
…
]
(У нашому випадку сервером слугує Dropbox, а JSON можна переглянути тут)
Проблема №1
Виникає проблема: замість двох елементів у списку їжі для ранкового періоду часу, отримуємо лише один.
Як вирішити проблему? Один зі способів зрозуміти у чому причина багу — переглянути JSON, що повертається сервером.
Як перехопити трафік?
Припустимо, що ваш MacOS комп'ютер та iOS пристрій знаходяться в одній локальній мережі, на зразок:
Трафік надходить від iOS пристрою через роутер до сервера, незалежно від трафіку комп'ютера.
Щоб читати трафік iOS пристрою необхідно організувати його передачу через Mac, що буде виглядати приблизно так:
Також знадобиться HTTP/S проксі сервер. З його допомогою буде можливість оглядати та модифікувати залучений трафік iOS пристрою.
Важливо також мати можливість перехоплювати HTTPS-трафік. Основна перешкода полягає в тому, що HTTPS протокол створювався саме для того, щоб окрім клієнта та сервера ніхто не міг переглянути зміст HTTP запитів. Саме тому HTTPS-проксі повинен постачатися разом із SSL сертифікатом, який потрібен для роботи з HTTPS трафіком.
Іншими словами, ми організовуємо Man-in-the-Middle атаку на нашу власну мережу.
Charles Web Debugging Proxy Application
Очевидно, що перехоплення HTTP-трафіку є багатоетапним завданням. Для максимального полегшення задачі раджу використовувати застосунок Charles Proxy
Почнемо з його недоліків:
-
Застосунок платний, але єдине обмеження у пробній версії полягає в тому, що Charles працює не більше 30 хвилин, а потім потребує перезавантаження. Також можна помітити затримки у 5 секунд при запуску застосунку. Дратує, але користуватися можливо.
-
Якщо ви потребуєте справжній хакерський інструмент для роботи 24/7 на віддаленому сервері з нормальним CLI, то Charles вам не підійде.
-
Якщо працюєте на Windows, краще підійде Fiddler, який до того ж безкоштовний.
-
Якщо вам потрібен проксі-сервер для великої кількості пристроїв (понад 2-3), то Charles вам також не підійде.
-
Якщо є необхідність роботи з TCP/IP пакетами в чистому вигляді — скористуйтеся Wireshark
Перейдемо до переваг:
-
Зручний дизайн. Charles не потребує спеціальних навичок для встановлення, налаштування та використання. Звичайний віконний MacOS застосунок.
-
HTTPS для iOS. У Charles є набір інструментів, які організовують перехоплення HTTPS з вашого iOS девайсу найбільш зручним в налаштуванні.
-
Функціонал. Charles може перехоплювати, модифікувати трафік, який проходить через застосунок, імітувати повільний інтернет, збирати статистику, імпортувати/експортувати трафік у різних форматах.
-
Доступний для Windows та Linux.
Особисто для мене, Charles — оптимальне рішення з погляду функціоналу/зручності при роботі з iOS пристроями.
Налаштування Charles та iOS девайсу
Опишемо процедуру первинного налаштування iOS девайсу для роботи з Charles Proxy.
- Запускаємо Charles на комп'ютері.
- Встановлюємо Charles Root Certificate на iOS пристрої. В меню обираємо Help -> SSL Proxing - > Install Charles Root Certificate on Mobile Device or Remote Browser.
З'явиться наступне вікно:
- В налаштуваннях мережі iOS необхідно вказати IP та порт Charles Proxy.
IP адреса, за якою працює Charles може відрізнятися, залежно від архітектури вашої мережі.
- Відкриваємо браузер на iOS девайсі та переходимо за посиланням
- Встановлюємо Charles SSL на пристрій.
- Вказуємо у налаштуваннях девайсу, що ми повністю довіряємо даному сертифікату. Settings -> General -> About -> Certificate Trust Settings
Цей етап є необхідним для пристроїв з iOS 10 та новіше.
Під час останніх двох етапів ми встановили на пристрій Charles SSL та вказали, що довіряємо йому. Таким чином, тепер увесь HTTPS трафік, підписаний цим сертифікатом не буде блокуватися ATS (App Transport Security).
Як переглядати трафік iOS приладу
Відкрийте додаток FoodSniffer. Якщо налаштування проксі було зроблено коректно, ви побачите такий екран:
В Charles Proxy відкрийте меню Тools -> No Caching і повністю вимкніть кешування на проксі-сервері.
В застосунку реалізовано Pull-to-refresh. Після оновлення списку продуктів ви повинні побачити в Charles посилання https://www.dropbox.com з лівого боку. Натисніть правою кнопкою миші на нього та оберіть Enable SSL Proxing.
Оновіть ще раз список продуктів у застосунку. Ви повинні побачити приблизно таку картину:
Тепер у нас є можливість вільно читати HTTPS трафік, який надходить від застосунку на Dropbox слід за нашим JSON.
Але це ще не все.
Dropbox не відправляє JSON з хосту dropbox.com напряму. Натомість він повертає 302 response та перенаправляє на інший хост, з якого і відбувається завантаження даних.
Його можна знайти, переглянувши Raw Response наступного запиту:
В даному випадку це http://uc9c29db95802af8490afc3afda9.dl.dropboxusercontent.com, а у вас, скоріш за все, буде інший хост.
Налаштовуємо таким чином: SSL Proxing: Enabled та оновлюємо FoodSniffer повторно.
Нарешті, можемо побачити правильний JSON, який демонструє наш застосунок.
Ми бачимо, що в у нас є всього один тип їжі на вечірній час — віскі. Пишемо про це нашому тімліду і йдемо пити каву, проблема не на нашому боці!
В проекті застосовується вже виправлений JSON з 2-ма типами їжі на вечір.
Якщо хост http://uc9c29db95802af8490afc3afda9.dl.dropboxusercontent.com чи схожі на нього не з'являються у списку зліва, спробуйте оновити список продуктів у застосунку декілька разів.
Проблема №2 або як змінити HTTPS трафік IOS пристрою
Після проведених налаштувань JSON формується правильно. Але що робити, якщо зараз ранок, а перевірити необхідно дані саме про вечірні страви?
Один із варіантів: за допомогою Charles змінювати JSON, який приходить у відповідь від Dropbox. Для цього замінимо consumePeriod з evening на morning, обравши в меню Tools -> Rewrite. У вікні Rewrite Settings додаємо нову категорію для перезапису — Dropbox.
Додаємо хост, вказавши https порт в Edit Location меню.
Вказуємо правила перезапису в меню Rewrite Rule наступним чином:
Тепер у кожній частині Body відповіді від нашого сервера evening буде замінено на morning.
За необхідністю можна змінювати будь-яку частину HTTP запиту/відповіді, а також використовувати регулярні вирази для заміни тексту.
Оновивши список, побачимо чотири типи страв та напоїв:
Якщо результат не збігається, спробуйте оновити список у застосунку декілька разів.
Тож тепер можемо виправити баг одразу, а не чекати вечора.
Висновок
Charles - досить зрозумілий, умовно безкоштовний, функціональний HTTPS-проксі. Як на мене, він найкраще проявляє себе при роботі з MacOS та iOS девайсами.
Натомість, існують альтернативні способи перехоплення трафіку. Для HTTP/S трафіку широко застосовують Fiddler. Якщо ж хочете приділити більше уваги TCP/IP - Wireshark для вас.
Окрім цього, існує проблема certificate pinning. Якщо у вашому застосунку він реалізований, необхідно або додавати Charles SSL сертифікат у список дозволених для застосування всередині застосунку, або використовувати інструменти, на зразок Frida для вимкнення certificate pinning на рівні самого застосунку.
Коментарі (1)