DDoS-атаки з мобільних пристроїв досить рідкісне явище. Однак зараз мобільні пристрої стають дедалі потужнішими, а можливості зв'язку швидко зростають.
289 
Навіть не дивлячись у статистику, Android-розробники знають, що гугловський Play Market заповнений додатками, їх там вже близько 3,5 мільйонів, з цього зрозуміло, що найжорстокіша конкуренція. Тому тема тестування Android дуже релевантна. І високий попит на Android-тестувальників, у тому числі Junior. З огляду на конкуренцію розробникам не можна — ніяк і ніде — підбивати користувачів. Цього реально досягти, якщо QA-відділ викладається на всі сто. Якщо софт для тестування Android – твоє слабке місце, або ти взагалі новачок у цій темі, спробуємо розібратися з базовими речами. Почнемо з простого, розглянемо мобільне тестування “загалом”. Мобільне тестування – це процес перевірки мобільних додатків, тобто програм для смартфонів, планшетів та інших мобільних пристроїв (більше про тестування мобільних додатків можна почитати в нашій статті). Перевіряється функціональність, продуктивність, безпека, зручність.
Тестування може бути ручним чи автоматизованим. Мета тестувальника та всієї QA-команди: переконатися, що програма відповідає прописаним бізнес-вимогам, та очікуванням користувачів. Придбавши нові навички в тестуванні, ви можете підняти свою значущість у компанії, взявши на себе більше відповідальності та знайти вразливі місця у своїх додатках. Коли керівництво побачить ваш звіт про виконану роботу, то неодмінно накине вам премію чи перегляне розмір зарплати. Тепер ви фахівець із безпеки, а таких на ринку велика недостача, тобто цінність вас як професіонала підвищується. І пам’ятайте: все наведене вище призначене для навчання! Застосовувати цю інформацію у своїх проектах можна лише з дозволу правовласника.
Коли займаєшся одним тривалий час, воно набридає, і я вирішив спробувати розібратися, як же відбуваються перевірки на вразливості в мобільних додатках. Топік узяв із списку OWASP TOP 10, тільки для мобайла. OWASP переїхав, тому не зможу скинути посилання на офіційний топік. До переїзду сайту список уразливостей був такий:
Після того, як я відкрив список і ознайомився з мобільними топ-уразливістю, зрозумів, що половина з них повністю схожі на вебівські, тобто OWASP TOP 10 класичний, який ми так звикли бачити. Так як, по суті, у нативних і веб-додатків один і той же спосіб роботи – на кшталт клієнт-серверної архітектури. Тобто в мобайлі клієнтом є нативний додаток, а в Інтернеті – браузер, але і у того, і в іншого запити надходять на сервер. Це і призводить до висновку, що половину технік можна взяти з веб-вразливостей, щоб застосувати пошуки дірок у нативних програмах.
Почнемо з того, який набір інструментів нам необхідний для проведення базового аналізу захищеності програми. Так, доповню: далі я розповідатиму, як це застосовувати для Android-додатків. У iOS трохи інша специфіка, про це в іншій статті.
1. Тестове середовище, тобто апка. Для цього можемо взяти програму DIVA. У ньому зібрані найпоширеніші вразливості мобільних додатків, і ви зможете попрактикуватися у їхньому пошуку.
2. Мобільний девайс. Або піднятий через емулятор Genymotion, або реальний, але обов’язково рутований, тому що без рут-привілеїв пенетрет не вдасться.
3. Santoku Linux. Цей дистрибутив був створений спеціально для того, щоб перевіряти Android-аплікухи на вразливості. У ньому вже з коробки встановлено всі необхідні програми для злому.
Отже, почнемо пошук зі статистики поширеності кожної з дірок топу OWASP. Якщо візьмемо статистику 2018 року, побачимо, на які категорії вразливостей варто звертати більше уваги при аудиті мобільного додатка. А тепер, думаю, настав час перейти до розбору кожної з категорій. Почнемо розглядати їх не по порядку, а з M9 – Reverse Engineering, оскільки пентест починається саме з неї.
Реверс-інжиніринг мобільного коду – звичайне явище. Це процес простого та несанкціонованого аналізу:
вихідного коду програми;
бібліотек;
алгоритмів;
таблиць і т.д.
Чтобы получить исходный код приложения, нужно на Santoku Linux закинуть установочный файл мобильного приложения, то есть APK, открыть консоль и выполнить нетрудные команды. Щоб отримати вихідний код програми, потрібно на Santoku Linux закинути файл інсталяції мобільного додатка, тобто APK, відкрити консоль і виконати неважкі команди. Виконуємо командуunzip -d diva-beta base.apk. Як ви здогадалися, вона розархівує програму і всі файли покладе в теку, яку ми назвали diva-beta.
Далі потрібно перейти до цієї папки і в ній виконати наступну команду: d2j -dex2jar classes.dex. З її допомогою ми здійснюємо декомпіляцію коду, який знаходиться у цьому файлі. Якщо ми відкриємо цей файл без декомпіляції, побачимо в ньому тільки кракозябри. Після відпрацювання цієї команди у папці з’явиться новий файл з ім’ям classes-dex2jar.jar, у якому буде нормальний вихідний код програми, придатний для читання людиною.
Для того щоб відкрити цей файл і почати вивчати код програми, нам знадобиться програма Jadx, яка також встановлена в нашому дистрибутиві Linux. Виконуємо команду jd-gui classes-dex2jar.jar.
Після відпрацювання цієї команди відкриється програма Jadx. Ми побачимо в ньому весь вихідний код і зможемо зрозуміти всі його недоліки, тобто знайти вже за його допомогою якісь уразливості.
І з M9-категорії перейдемо до M1. До цієї категорії відноситься неправильне використання функції операційної системи або заходів безпеки платформи. Це трапляється часто і може вплинути на вразливі програми. Давайте перейдемо, наприклад. Так як у нас ця програма вже є з вихідним кодом, за допомогою попередньої вразливості вивчимо одну з діяльності цієї апки.
Ми бачимо, що розробник при дебазі програми використовував logcat, щоб розуміти, які помилки були в даному полі. Але при компілюванні програми в релізне складання забув забрати цю команду дебага. Що це може означати для користувачів програми? Те, що дії логуватимуться, якщо там будуть якісь помилки чи попередження. Тобто, коли користувач буде писати у форму (а, припустимо, це форма для прийняття карткових даних), ці дані будуть мелькати в логах програми, якщо користувач припуститься помилки при заповненні форми або отримає попередження щодо заповнення. Неважко здогадатися, що до цих логів зловмисник може отримати доступ.
Цей ризик у списку OWASP інформує спільноту розробників про небезпечне зберігання даних на мобільному пристрої. Зловмисник може або отримати фізичний доступ до украденого пристрою, або увійти в нього, використовуючи шкідливе ПЗ.
У разі фізичного доступу до пристрою зловмисник може легко отримати доступ до файлової системи пристрою після підключення його до комп’ютера. Багато програм, що вільно розповсюджуються, дозволяють зловмиснику отримувати доступ до каталогів та особистих даних, що містяться в них.
конфіденційні дані в додатку треба зберігати в зашифрованому вигляді;
програми можуть ділитися даними з іншими додатками.
Як приклад візьмемо форму реєстрації у мобільному додатку.Я, як користувач, зареєструвався в додатку. Розробник взяв і поклав мої дані у незашифрованому вигляді у загальнодоступну папку, до якої мають доступ інші програми, встановлені в телефоні. Отримуємо те, що мої дані були злиті.
M3 — це ще один поширений ризик, про який забувають розробники мобільних додатків. Передача даних у мобільний додаток та з нього зазвичай здійснюється через оператора зв’язку або Wi-Fi. Відомо, що зловмисники досягають успіху у розкритті особистої інформації користувачів, якщо ця передача не захищена. Хакери перехоплюють дані користувачів у локальній мережі через скомпрометовану мережу Wi-Fi, підключаючись до неї через маршрутизатори, вежі стільникового зв’язку, проксі-сервери або використовуючи заражений додаток за допомогою шкідливого ПЗ. При надсиланні запитів на сервер з даними, які надсилає користувач, деякі з них іноді надсилають за протоколом HTTP замість HTTPS.
Приклад експлуатації такої вразливості: зловмисник створює компрометовану мережу Wi-Fi, до якої підключиться користувач. Потім цей man in the middle починає аналізувати весь трафік, який ходитиме через нього. Відповідно, дані користувача, які надсилаються до сервера за протоколом HTTP, можуть перехоплюватися. Зловмисник бачитиме його креди у перехопленому пакеті. Нижче наведено приклади, як передавати дані погано і як добре. Також можна переглянути цей видос про перехоплення трафіку. Погано:
Дані варто шифрувати: навіть якщо зловмисник почне слухати трафік, підключившись до тієї ж мережі, що й ми, він хоча б не побачить інформації у відкритому вигляді. Тобто ми ускладнимо йому завдання крадіжки даних, як це показано на малюнку нижче.
Гаразд, ми застосували шифрування, про яке говорили в розділі про попередню вразливість. Але якщо ми використовуємо слабкі процеси шифрування/дешифрування або допускаємо огріхи в алгоритмах, що запускають їх, то дані користувачів знову стають вразливими.
Є три способи, за допомогою яких зловмисники намагаються використати криптографічні проблеми:
отримати фізичний доступ до мобільного пристрою;
стежити за мережним трафіком;
використовувати шкідливі програми на пристрої для доступу до зашифрованих даних.
Щоб зрозуміти, якими методами користуються розробники для шифрування даних, потрібно поглянути на вихідний код, який ми вже маємо.
На малюнку вище бачимо, що розробник застосував метод хешування MD5, який прямо так і кричить: «Ломай мене повністю!» Це один із найлегших методів.
При перехопленні запиту від користувача ми побачимо засекречені здавалося б дані. Але якщо підемо на якийсь онлайн декодер і закинемо туди цей хеш, то побачимо реальний пароль даного користувача.
Погані схеми автентифікації дозволяють зловмиснику анонімно виконувати будь-які дії, доступні користувачеві, в мобільному додатку або сервері, використовуваному мобільним додатком. Слабка автентифікація для мобільних додатків досить поширена через формфактор введення мобільного пристрою. Формфактор настійно рекомендує використовувати короткі паролі, які часто ґрунтуються на чотиризначних PIN-кодах. Вимоги автентифікації для мобільних програм можуть істотно відрізнятися від традиційних схем веб-автентифікації через вимоги доступності. Очікується, що у традиційних веб-додатках користувачі будуть підключені до мережі та автентифікуватимуться в режимі реального часу.
Як тільки зловмисник розуміє, наскільки вразлива схема аутентифікації, він підробляє або обходить аутентифікацію, надсилаючи запити серверу на обробку мобільного додатка, при цьому взагалі не залучаючи останнє. Для прикладу: зловмисник може використовувати просто якийсь аналізатор програми, допустимо той же Burp Suite. Йому достатньо проаналізувати, які є сторінки цієї програми.
Розглянемо запит на авторизацію. Ми бачимо дані, які надсилаються на сервер. Далі зловмисник просто намагається отримати інформацію від сервера, використовуючи вихідну інфу в запиті. Він перебирає виділені місця, щоб досягти позитивного результату несанкціонованого доступу до даних когось із користувачів.
звернути увагу до урли;
звернути увагу до тип користувача;
спробувати замінити токен, підібравши необхідний (з доступом до адмінських функцій), і т.д.
Багато людей плутають ризик M4 з ризиком M6, оскільки вони стосуються облікових даних користувача. Розробник повинен мати на увазі, що M6 включає використання авторизації для входу в систему як легітимного користувача, на відміну від M4, коли зловмисник намагається обійти процес аутентифікації, увійшовши в систему як анонімний користувач.
Як тільки зловмисник отримає доступ до програми як законного користувача, обдуривши механізм безпеки програми, наступне його завдання в M6 — отримати адміністративний доступ шляхом примусового перебору запитів, серед яких він може натрапити на команди адміністратора. Зловмисники зазвичай використовують ботнети або шкідливі програми на мобільному пристрої для використання вразливостей авторизації. Результатом цього порушення безпеки є те, що зловмисник може виконати бінарні атаки на пристрої в автономному режимі.Пошук можна робити також за допомогою Burp Suite, намагаючись виконати запити, доступні адміну, як звичайного користувача. Дивіться вразливість M4.
Ризик M7 виникає через погану або суперечливу практику кодування, коли кожен член команди розробників дотримується різних практик кодування і створює невідповідності в кінцевому коді. Економія для розробників тут полягає в тому, що навіть якщо поширеність цього ризику загальна, його виявленість низька. Хакерам нелегко вивчити патерни поганого кодування, часто потрібний непростий ручний аналіз. Через погане кодування користувач мобільного пристрою може зіткнутися із уповільненням обробки запитів та неможливістю правильно завантажити необхідну інформацію. Наприклад, можна навести історію з WhatsApp, коли його інженери виявили можливість переповнення буфера шляхом відправки спеціально створеної серії пакетів. Для цього не потрібно було відповідати на виклик і зловмисник міг виконати довільний код.
Оказалось, что такая уязвимость использовалась для установки на телефон программ-шпионов. Эту услугу продала израильская компания NSO Group. Не стоит использовать функции, которые могут переполнить буфер, вот так:
Тут усе зрозуміло, і розповідати нема чого. Просто не варто завантажувати програми APK зі сторонніх ресурсів, оскільки хакери воліють фальсифікацію коду в додатках, оскільки це дозволяє їм отримати необмежений доступ:
до інших програм у вашому телефоні;
до поведінки користувача.
Пам’ятаєте, у M9 ми зробили реверс-інженерію програми та знаємо вихідний код? Тепер можемо його підправити (залити туди якогось хробака, який отримуватиме доступ до даних на інших додатках), потім заново скомпілювати та викласти APK на якийсь сайт із приміткою, що тут його можна завантажити безкоштовно 🙂
Перед тим, як програма буде готова до роботи, команда розробників часто зберігає в ній код, щоб мати легкий доступ до внутрішнього сервера. Цей код не впливає на функціонування програми. Але коли зловмисник знайде ці підказки, розробникам буде не дуже прикольно. Аж раптом це будуть креди для входу в систему з правами адміну?
Як приклад, візьмемо сторінку, на якій потрібно ввести ключ для отримання доступу до важливих даних. Вивчимо, як виглядає ця сторінка у коді.
Побачимо, що розробник залишив підказку, що потрібно запровадити, щоб отримати доступ до необхідних нам даних. На цьому сьогодні все, до зустрічі.
289 
403 
404