M4-Insecure Authentication
У цій статті поговоримо про вразливість поганої автентифікації, які є вектори обходу авторизації тощо. У рейтингу OWASP TOP 10 ця вразливість знаходиться на 4-му місці.
Атаки через цю вразливість зазвичай робляться автоматично з використанням доступних і безкоштовних інструментів. До інструментів визначення цієї вразливості можна використовувати Burp Suite, OWASP ZAP, Drozer тощо.
Як тільки зловмисник розуміє, наскільки вразлива схема аутентифікації, він підробляє або оминає аутентифікацію, надсилаючи запити на обробку серверу мобільного додатка, при цьому не юзаючи мобільний додаток взагалі. Цей процес надсилання запитів виконується за допомогою:
- мобільного шкідливого ПЗ усередині пристрою
- бот-мереж, що належать зловмиснику
Погані схеми автентифікації дозволяють зловмиснику анонімно виконувати будь-які дії, доступні для користувача, у мобільному додатку або на сервері, що використовується мобільним додатком. Слабка автентифікація для мобільних додатків досить поширена через форм-фактор введення мобільного пристрою. Форм-фактор настійно рекомендує використовувати короткі паролі, які часто ґрунтуються на чотиризначних PIN-кодах. Вимоги автентифікації для мобільних додатків можуть відрізнятися від традиційних схем веб-автентифікації через вимоги доступності. Очікується, що у традиційних веб-додатках користувачі будуть підключені до мережі та автентифікуватимуться в режимі реального часу.
Мобільні інтернет-з'єднання є набагато менш надійними, ніж традиційні веб-з'єднання. Отже, мобільні програми можуть мати вимоги щодо часу безвідмовної роботи, які вимагають автономної автентифікації. Ця автономна вимога може мати серйозні наслідки для речей, які розробники повинні враховувати під час реалізації мобільної автентифікації. Щоб виявити погані схеми аутентифікації, тестери можуть виконувати бінарні атаки на мобільний додаток, коли він перебуває в режимі офлайн. Під час атаки тестер змусить програму обходити автономну автентифікацію і виконувати функції, які повинні вимагати автономної автентифікації. Крім того, тестери повинні намагатися виконувати будь-які функції сервера анонімно, видаляючи будь-які маркери сеансів із будь-яких запитів POST/GET для функціональності мобільного додатка.
Приклади сценаріїв атаки:
- №1. Burp suite. Розробники припускають, що тільки автентифіковані користувачі зможуть генерувати запит сервісу, який відправляє мобільний додаток на сервер для обробки. Під час обробки запиту код сервера не перевіряє, чи вхідний запит пов'язаний з відомим користувачем. Отже, зловмисники надсилають запити на сервер та анонімно користуються функціоналом.
У цьому випадку, зловмисник може використовувати просто якийсь аналізатор програми, допустимо той же Burp Suite. Йому досить проаналізувати які є сторінки цього додатка для цього є функція Craw, за допомогою неї ми можемо зрозуміти які пакети йдуть, куди йдуть і які пакети приходять від сервера.
Проаналізувавши програму, ми бачимо все дерево запитів та відповідей від сервера, а також дані, які надсилаються або виходять у відповідь від сервера. Далі зловмисник може просто намагається отримати інформацію, вживаючи запити, а в них перебирати:
- урли до яких стукають
- перебирати права користувача
- Спробувати замінити токен, підібравши потрібний (з доступом до адмінських функцій)
- і т.д.
Знову ж таки, якщо немає перевірки на те, що цей користувач вже автентифікований Як налаштовувати аналізатор до мобільного додатка я писав у статті про M3-Insecure Communication
- №2. Drozer. Запустимо нашу програму з даною вразливістю Insecure Bank
Підконнектившись через OS до мобільного телефону, викликаємо команду в консолі нашої OS
З результатів ми дізнаємося, що це 5 дій, які експортуються, і перші дві пов'язані із процесом входу до системи.
com.android.insecurebankv2.LoginActivity призначений для екрана сторінки входу в систему, а дія
com.android.insecurebankv2.PostLogin це екран, який спрацьовує під час входу користувача до системи. Тому нам потрібно використовувати активність com.android.insecurebankv2.PostLogin для обходу аутентифікації. Використовуючи drozer, давайте почнемо вправу, давши наступну команду
dz> run app.activity.start --component com.android.insecurebankv2 com.android.insecurebankv2.PostLogin
Ми обійшли сторінку входу, тепер ми можемо зробити переклад, змінити пароль або переглянути заяву.
Атаки Brute force також можливі, але якщо програма не має будь-якого механізму захисту. Наприклад, якщо програма часто отримує запит на вхід до системи, вона блокує користувача і на деякий час обмежує доступ і т.д. Дізнатися більше, як проводиться Brute force, можете у цій статті.
Як захиститися:
- Якщо ви переносите веб-додаток на мобільний еквівалент, вимоги до автентифікації мобільних програм повинні відповідати вимогам до компонента веб-додатку. Тому не повинно бути можливості автентифікації з меншою кількістю символів автентифікації, ніж у веб-браузері;
- Не зберігати дані користувача локально в програмі, процедуру автентифікації можна обійти на зламаних пристроях за допомогою маніпулювання двійкового файлу.
- Переконайтеся, що всі запити на автентифікацію виконуються на стороні сервера. Після успішної аутентифікації дані програми будуть завантажені на мобільний пристрій. Це гарантує, що дані програми будуть доступні лише після успішної автентифікації;
- Якщо потрібно зберігати дані на стороні клієнта, дані повинні бути зашифровані з використанням ключа шифрування. Це забезпечить доступ до збережених даних програми лише після успішного введення правильних облікових даних;
- Функціональність постійної аутентифікації (Запам'ятати мене), реалізована в мобільних додатках, ніколи не повинна зберігати пароль користувача на пристрої;
- В ідеалі мобільні програми повинні використовувати токен автентифікації для конкретного пристрою. Це гарантує, що програма може пом'якшити несанкціонований доступ з вкраденого / втраченого пристрою;
- Постійна автентифікація в мобільних додатках має бути реалізована як opt-in та не включена за замовчуванням;
- Якщо можливо, не дозволяйте користувачам надавати 4-значні номери PIN для паролів автентифікації.
- Використовувати двофакторну автентифікацію