M4-Insecure Authentication
Вернуться назад

В этой статейке поговорим про уязвимость плохой аутентификации, какие есть векторы обхода авторизации и тд.

В рейтинге OWASP TOP 10 эта уязвимость находится на 4 месте.

Атаки через эту уязвимость обычно делаются в автоматическом режиме с использованием доступных и бесплатных инструментов. К инструментам для определения этой уязвимости можно использовать Burp Suite, OWASP ZAP, Drozer и тд.

 

Как только злоумышленник понимает, насколько уязвима схема аутентификации, он подделывает или обходит аутентификацию, отправляя запросы на обработку серверу мобильного приложения, при этом не юзая мобильное приложение вообще. Этот процесс отправки запросов выполняется с помощью:

- мобильного вредоносного ПО внутри устройства

- бот-сетей, принадлежащих злоумышленнику

 

Плохие схемы аутентификации позволяют злоумышленнику анонимно выполнять любые действия, доступные для пользователя, в мобильном приложении или на сервере, используемом мобильным приложением. Слабая аутентификация для мобильных приложений довольно распространена из-за форм-фактора ввода мобильного устройства. Форм-фактор настоятельно рекомендует использовать короткие пароли, которые часто основаны на четырехзначных PIN-кодах. Требования аутентификации для мобильных приложений могут сильно отличаться от традиционных схем веб-аутентификации из-за требований доступности. Ожидается, что в традиционных веб-приложениях пользователи будут подключены к сети и будут аутентифицироваться в режиме реального времени.

 

Мобильные интернет-соединения гораздо менее надежны, чем традиционные веб-соединения. Следовательно, мобильные приложения могут иметь требования по времени безотказной работы, которые требуют автономной аутентификации. Это автономное требование может иметь серьезные последствия для вещей, которые разработчики должны учитывать при реализации мобильной аутентификации. Чтобы обнаружить плохие схемы аутентификации, тестеры могут выполнять бинарные атаки на мобильное приложение, когда оно находится в режиме «офлайн». Во время атаки тестер заставит приложение обходить автономную аутентификацию и затем выполнять функции, которые должны требовать автономной аутентификации. Кроме того, тестеры должны пытаться выполнять любые функции сервера анонимно, удаляя любые маркеры сеансов из любых запросов POST / GET для функциональности мобильного приложения.

Примеры сценариев атаки:

- № 1. Burp suite. Разработчики предполагают, что только аутентифицированные пользователи смогут генерировать запрос сервиса, который мобильное приложение отправляет на сервер для обработки. Во время обработки запроса код сервера не проверяет, что входящий запрос связан с известным пользователем. Следовательно, злоумышленники отправляют запросы на сервер и анонимно пользуются функционалом. 

 

В этом случае, злоумышленник может использовать просто какой-то анализатор приложения, допустим тот же Burp Suite. Ему достаточно проанализировать какие есть страницы у данного приложения для этого есть функция Craw, с помощью ее мы можем понять какие пакеты уходят, куда уходят и какие пакеты приходят от сервера. 

Как защититься:

- Если вы переносите веб-приложение на мобильный эквивалент, требования к аутентификации мобильных приложений должны соответствовать требованиям к компоненту веб-приложения. Поэтому не должно быть возможности аутентификации с меньшим количеством символов аутентификации, чем в веб-браузере;

- Не хранить данные пользователя локально в приложении, процедуру аутентификации можно обойти на взломанных устройствах с помощью манипулирования двоичного файла.

- По возможности, убедитесь, что все запросы на аутентификацию выполняются на стороне сервера. После успешной аутентификации данные приложения будут загружены на мобильное устройство. Это гарантирует, что данные приложения будут доступны только после успешной аутентификации;

- Если требуется хранение данных на стороне клиента, данные должны быть зашифрованы с использованием ключа шифрования. Это обеспечит доступ к сохраненным данным приложения только после успешного ввода правильных учетных данных;

- Функциональность постоянной аутентификации (Запомнить меня), реализованная в мобильных приложениях, никогда не должна хранить пароль пользователя на устройстве;

- В идеале мобильные приложения должны использовать токен аутентификации для конкретного устройства. Это гарантирует, что приложение может смягчить несанкционированный доступ с украденного / потерянного устройства;

- Постоянная аутентификация в мобильных приложениях должна быть реализована как opt-in и не включена по умолчанию;

- Если возможно, не разрешайте пользователям предоставлять 4-значные номера PIN для паролей аутентификации.

- Использовать двухфакторную аутентификацию

И ПОМНИТЕ ВСЕ ПОКАЗАННОЕ ВЫШЕ, СДЕЛАНО В ЦЕЛЯХ ОБУЧЕНИЯ!!!

МОЖНО ПРИМЕНЯТЬ ТОЛЬКО НА СВОИХ ПРОЕКТАХ, ПОСЛЕ РАЗРЕШЕНИЯ

gallery/выделение_139

Хотите узнать больше о различных уязвимостях и инструментах для поиски этих же уязвимостей, чтоб сделать ваш проект безопасным, для ваших пользователей? 

Мы организовываем тренинги по OWASP TOP 10. 

Буду рад вас видеть на тренинге!

 

Программа тут

 

 

Подконектившись через 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, можете в этой статье

gallery/выделение_006
gallery/photo_2019-05-24_14-49-20
gallery/owasp_logo_normal
gallery/выделение_008

Проанализировав приложение, мы видим все дерево запросов и ответов от сервера, а также данные, которые отправляются или получаются в ответ от сервера. Далее злоумышленник может просто напросто пытается получить информацию, употребляя запросы, а в них перебирать:

- урлы к которым стучатся

- перебирать права юзера

- попробовать подменить токен, подобрав нужный (с доступом к админским функциям)

- и тд.

Опять таки если нету проверки на то, что этот пользователь уже аутентифицирован

Как настраивать анализатор к мобильному приложению я писал в статье про M3-Insecure Communication

 

 

- № 2. Drozer. Запустим наше приложение с данной уязвимостью Insecure Bank

gallery/выделение_007
gallery/выделение_009
gallery/выделение_005