Як захиститися:
- Застосовувати SSL / TLS до транспортних каналів, які використовуватимуться мобільним додатком для передачі конфіденційної інформації в API або веб-службах.
- Використовуйте надійні комплекти шифрів із відповідною довжиною ключа.
- Використовуйте сертифікати, підписані довіреним центром сертифікації.
- Завжди вимагати перевірки ланцюжка SSL.
- Встановлюйте безпечне з'єднання лише після перевірки особистості сервера за допомогою довірених сертифікатів у ланцюжку ключів.
- Сповіщати користувачів через інтерфейс користувача, якщо мобільний додаток виявляє недійсний сертифікат.
- Не надсилайте конфіденційні дані альтернативними каналами (наприклад, SMS, MMS або повідомлення).
- Якщо можливо, застосуйте окремий рівень шифрування до будь-яких конфіденційних даних, перш ніж вони будуть передані на канал SSL. У разі виявлення майбутніх вразливостей у реалізації SSL зашифровані дані забезпечать вторинний захист від порушення конфіденційності.
Спеціальні рекомендації для iOS
- Класи за замовчуванням в останній версії iOS добре справляються з узгодженням надійності шифру SSL. Здавалося б, все добре, але проблема виникає, коли розробники тимчасово додають код, щоб обійти ці значення і залишають їх після релізу. На додаток до вищезазначених загальних практик:
- Переконайтеся, що сертифікати дійсні та закриті під час збою.
- У разі використання CFNetwork розгляньте можливість використання Secure Transport API для позначення сертифікатів довірених клієнтів. Майже у всіх ситуаціях NSStreamSocketSecurityLevelTLSv1 слід використовувати для вищого рівня надійності шифру.
- Після розробки переконайтеся, що всі виклики NSURL (або оболонки NSURL) не допускають самозавіряючих або недійсних сертифікатів, таких як метод класу NSURL setAllowsAnyHTTPSCertificate.
- Подумайте про використання закріплення сертифікатів, виконаючи такі дії: експортуйте сертифікат, увімкніть його в комплект програми та прив'яжіть його до об'єкта довіри.
- При використанні методу NSURL з'єднання: willSendRequestForAuthenticationChallenge: тепер прийме сертифікат.
Рекомендації для Android
- Видаліть весь код після циклу розробки, який може дозволити застосунку приймати всі сертифікати, такі як org.apache.http.conn.ssl.AllowAllHostnameVerifier або SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. Оскільки це еквівалентно довірі всім сертифікатам.
- При використанні класу, який розширює SSLSocketFactory, переконайтеся, що метод checkServerTrusted правильно реалізований, щоб сертифікат сервера був правильно перевірений.
M3-Insecure Communication
Ну що погнали далі! Тепер перейдемо до нашого коханого мужика, який любить стати посередині і спостерігати, якщо ви подумали про збоченця, який любить спостерігати, то я говорю не про нього :-))) Цей мужик не просто спостерігає, але й краде ваші конфіденційні дані через незахищені громадські мережі та програми, якими ви користуєтеся, якщо вони погано написані. У рейтингу OWASP TOP 10 ця вразливість перебуватиме на 3 місці.
Ну що розберемо вразливість M3-Insecure Communication. До неї схильні користувачі, які користуються громадськими мережами і не дуже добре захищеними програмами або зовсім завантажене з піратського ресурсу, в якому встановлено шкідливе програмне забезпечення.
Як ми знаємо, користуючись мобільним додатком, користувачі зазвичай обмінюються даними з сервером, працює як і звичайна веб-додаток. Найчастіше мобільні програми не захищають мережевий трафік. Вони можуть використовувати SSL/TLS під час автентифікації, але не в інших місцях. Ця невідповідність призводить до ризику перехоплення даних та ідентифікаторів сеансів. Навіть якщо ви використовуєте безпечну передачу даних, це не означає, що програма правильно реалізована. Щоб виявити основні недоліки, спостерігайте за мережним трафіком телефону. Встановіть якийсь інструмент перехоплення запитів і спостерігайте у якому вигляді передаються дані на сервер.
Перехоплення трафіку Перехоплення трафіку для мобільного додатка не просте, існують певні важливі умови, які необхідно виконати, щоб успішно виконати цю атаку і поставити під загрозу зв'язок між додатком та внутрішнім сервером, до якого він підключається. Ці умови включають:
- Можливість встановлення сертифіката CA проксі на пристрої.
- Програма довіряє встановленому користувачем сертифікату.
- Можливість зміни конфігурації Wi-Fi пристрою.
- Обхід SSL-закріплення (якщо звичайно він взагалі є :-))), як правило, сертифікати повинні мати досить довгий ключ, мінімум 2048 біт. Вони повинні бути не закінченими, виданими довіреними центрами сертифікації, а найголовніше правильно налаштованими на рівні сервера для роботи з безпечними протоколами (TLS v1 є кращим) і треба використовувати набори шифрів RSA/AES256/SHA2).
Так переходимо до практики. Для цього нам потрібен Burp Suite та Genymotion.
Налаштування проксі між цими двома програмами
Почнемо з цього інструменту:
1) встановіть Genymotion (якщо у вас Virtualbox встановлений, то качайте пакет без віртуалки)
2) запустіть програму
3) створіть пристрій на базі 5.0 Андроїд, як це показано нижче (це пов'язано з тим, що саме на цій версії можна буде записати google сервіси, так як Genymotion не домовився з гуглом про присутність гуглівських сервісів у них в емуляторах, а так як деякі програми просять ці послуги зі своїх міркувань, то ці додатки без цих послуг працювати не будуть. Допустимо у вас програми, які повинні визначати вашу геолокацію і якщо у вас на емуляторі не буде сервісу визначення місця, то і додаток ваш не працюватиме, все залежить від того, як ваші розробники реалізовували приклад. Як додати гугл сервіси погуглить, довго писати просто)))
4) встановіть Burp Suite
5) запустіть програму Burp Suite
6) перейдіть у вкладку Proxy->Options
Після натискання на кнопку edit, вибрати такі настройки, для налаштування нашої проксі в Burp Suite.
7) Налаштувати проксю в мобільному емуляторі або в реальному підключеному девайсі. Для цього запускаємо наш емулятор
Відкриваємо налаштування мережі і модифікуємо під нашу проксі, які ми налаштовували в Burp Suite
Клацаємо на пункт Modify network.
У пункті 1 пропишемо ip нашого комп'ютера, на якому підняли Burp Suite. У пункті 2 пишемо порт, який вказали в самому Burp Suite. Залишається трохи тепер, у цій конфігурації, ми можемо бачити в Burp Suite тільки трафік який ходить через http, але нам же і потрібно ловити трафік https. Для цього нам потрібно залити сертифікат із Burpa у довірчі на телефон. Заходимо у будь-який браузер пишемо у рядку урл http://Burp
Як ми бачимо вище, у вас має вийти так. Потім клацаємо по кнопці CA Certificate, піде стрибка сертифіката, але не поспішайте поспішати радіти. Нам трохи не підходить формат того сертифіката для мобільного пристрою, нам треба змінити розширення з der на crt. Один і варіантів це зробити це підконнектитися до девайсу за допомогою команди adb connect ip. У моїй нагоді adb connect 192.168.17.234.
Після того, як ми підконнектимося до нього, заходимо в shell пристрої, це робимо за допомогою команди adb shell.
Далі заходимо до директорії Download за допомогою команди cd /mnt/sdcard/Download.
Далі робимо переформатування сертифіката за допомогою mv cacert.der cacert.crt
У вас вийде набір команд як на скріні вище
8) встановлення сертифіката на телефоні Для цього ми йдемо в налаштування і там знаходимо пункт Security-> в ньому знаходимо пункт Install from SD card -> Там знаходимо наш сертифікат за нашим ім'ям, під яким зберігали з потрібним нам уже розширенням і встановлюємо його.
Все, ми налаштували нашу бадю з перехоплення запитів для подальших змін. Тепер запускаємо будь-яку програму, яка спілкується з сервером. Допустимо візьмемо авторизацію сторінку, вводимо туди якісь креденшели і дивимось у Burp.
Якщо у вас перехоплений запит має такий вигляд, то це дуже погано, тому що всі дані знаходяться у відкритому вигляді, без усіляких шифрувань, відповідно зловмисник зможе потім розпоряджатися цими даними з корисливою метою.
Ну а якщо у вас при перехопленні запиту такий вигляд, то можете вважати що ви не вразливі до цієї вразливості.
