1. Вступление
Добрый день, уважаемые форумчане. Давно от меня не было статей, из-за того что проходил курс SQLiM aka SQL Injection Master от codeby. Хоть наш поток и закончился почти месяц назад, я хотел максимально закрепить пройденный материал и практиковался на разных ресурсах. Курс, кстате, советую всем. Сегодня мы разберем необычную уязвимость в android приложениях для обхода авторизации клиентов. Сегодняшним нашим инструментов будет незаменимый Charles, который лучше всех справляется со своей задачей.
2. Charles
Charles (или Charles Web Debugging Proxy), если верить википедии - это кроссплатформенное приложение прокси-сервера отладки HTTP, написанное на Java. Он позволяет пользователю просматривать HTTP, HTTPS, HTTP / 2 и включенный трафик TCP-порта, доступ к которому, с локального компьютера или через него. Простыми словами, мы можем модифицировать request/response. А с помощью специальных правил, запрос будет модифицироваться автоматически.
3. Почему Charles, а не Burp Suite
После прочтения статьи, некоторые могут задуматься, почему автор решил использовать charles, если есть всеми любимый burp suite. Burp suite - несомненно мощный инструмент, но, для наших целей Charles отлично вставлялась в пазл. Вместо 1000 слов, приложу основные различия Charles vs Burp Suite.
Как мы можем заметить, каждый по своему хорош и выполняет определенную задачу лучше чем свой конкурент.
4. Подготовка рабочего окружения и настройка
Для запуска уязвимого приложения, нам естественно нужен будет Android девайс. Мы бы могли провернуть такую же операцию на реальном телефоне, но, яблочник раз - яблочник навсегда
Возьмем в качестве эмулятор Nox Player, который без грязных рук разрешает назначать прокси, в отличии от BlueStacks.
Итак, запускаем Charles, следом запускаем наш эмулятор и настраиваем для него прокси. В качестве IP адреса указываем локальный IP адрес компьютера, где у нас запущен Charles. В linux и mac os, ip адрес можно узнать командой ifconfig. Для windows существуют схожая команда - ipconfig.
И вбиваем его в качестве прокси сервера для беспроводной точки доступа на android устройстве.
Для просмотра HTTPS траффика в нормальном виде, нам нужно установить сертификат Charles на нашем android устройстве.
После этого процесса идем проверять всё ли сделали правильно. Открываем в браузере телефона любой сайт и наблюдаем изменения в Charles.
Если вы видите примерно такую картину, значит вы всё сделали правильно. Почему у нас в запросе везде ноли и единицы? Потому-что мы не включили для данного хоста пункт SSL Proxying, который служит расшифровкой SSL траффика. Включаем SSL проксирование для всех хостов, чтобы не включать каждый нужный хост индивидуально. Нажимаем Proxy -> SSL Proxying Settings -> Add и заполняем форму как на скриншоте
Открываем на эмулятор сайт еще раз и глянем в Charles
Теперь вместо нулей у нас реальные данные, такие как, размер запроса и ответа, скорость ответа от сервера, dns и много другой инфы.
5. Обход API авторизации
Итак, запускаем наше приложение. Ждем пока всё прогрузится. Для перехвата запроса пытаемся авторизоваться по своему номеру. включаем брекпоинты (правый клик по хосту и включить пункт Breakpoints) для хоста и переходим в режим брекпоинтов (красная галочка на верхней панели) и вводим полученный код.
Видим запрос который проверяет код. Запускаем запрос и смотрим на ответ.
В качестве подтверждения правильности кода, сервер отправил нам JSON ответ. Ладно, сохраним этот json объект, и теперь пытаемся авторизовать с рандомного номера и указываем любой код.
Смотрим ответ от сервера
Сервер сообщает нам что код неверный, по сути так и есть, ведь мы указали рандомный номер и код. А что будет если подставить ответ от успешного входа вместо этого ответа? Меняем JSON ответ
И пускаем ответ к приложению кнопкой Execute. Смотрим что произошло в приложении
Ура! Мы в системе под чужим номером. Хоть это было не совсем сложно, но, мы обошли авторизацию.
6. Заключение
Вся информация была предоставлена исключительно в образовательных целях. Эксплуатация уязвимости была выполнена на реальном примере, в реальном приложении. Т.е. это может встречаться на практике. Зафиксить эту уязвимость очень легко. Достаточно при каждом запросе от клиента, предоставлять ему токен, по которому сервер авторизует юзера, а не JSON объект или иной текст, подтверждающий удачный вход. До скорой встречи!
Добрый день, уважаемые форумчане. Давно от меня не было статей, из-за того что проходил курс SQLiM aka SQL Injection Master от codeby. Хоть наш поток и закончился почти месяц назад, я хотел максимально закрепить пройденный материал и практиковался на разных ресурсах. Курс, кстате, советую всем. Сегодня мы разберем необычную уязвимость в android приложениях для обхода авторизации клиентов. Сегодняшним нашим инструментов будет незаменимый Charles, который лучше всех справляется со своей задачей.
2. Charles
Charles (или Charles Web Debugging Proxy), если верить википедии - это кроссплатформенное приложение прокси-сервера отладки HTTP, написанное на Java. Он позволяет пользователю просматривать HTTP, HTTPS, HTTP / 2 и включенный трафик TCP-порта, доступ к которому, с локального компьютера или через него. Простыми словами, мы можем модифицировать request/response. А с помощью специальных правил, запрос будет модифицироваться автоматически.
3. Почему Charles, а не Burp Suite
После прочтения статьи, некоторые могут задуматься, почему автор решил использовать charles, если есть всеми любимый burp suite. Burp suite - несомненно мощный инструмент, но, для наших целей Charles отлично вставлялась в пазл. Вместо 1000 слов, приложу основные различия Charles vs Burp Suite.
Как мы можем заметить, каждый по своему хорош и выполняет определенную задачу лучше чем свой конкурент.
4. Подготовка рабочего окружения и настройка
Для запуска уязвимого приложения, нам естественно нужен будет Android девайс. Мы бы могли провернуть такую же операцию на реальном телефоне, но, яблочник раз - яблочник навсегда
Возьмем в качестве эмулятор Nox Player, который без грязных рук разрешает назначать прокси, в отличии от BlueStacks.
Итак, запускаем Charles, следом запускаем наш эмулятор и настраиваем для него прокси. В качестве IP адреса указываем локальный IP адрес компьютера, где у нас запущен Charles. В linux и mac os, ip адрес можно узнать командой ifconfig. Для windows существуют схожая команда - ipconfig.
И вбиваем его в качестве прокси сервера для беспроводной точки доступа на android устройстве.
Для просмотра HTTPS траффика в нормальном виде, нам нужно установить сертификат Charles на нашем android устройстве.
- Получите сертификат SSL. Посетите этот URL из своего мобильного браузера:
Ссылка скрыта от гостей
- В поле «Имя сертификата» введите все, что хотите.
- Примите предупреждение о безопасности и установите сертификат. Если вы установите его успешно, то вы, вероятно, увидите это так: В телефоне Настройки -> Безопасность -> Доверенные учетные данные
После этого процесса идем проверять всё ли сделали правильно. Открываем в браузере телефона любой сайт и наблюдаем изменения в Charles.
Если вы видите примерно такую картину, значит вы всё сделали правильно. Почему у нас в запросе везде ноли и единицы? Потому-что мы не включили для данного хоста пункт SSL Proxying, который служит расшифровкой SSL траффика. Включаем SSL проксирование для всех хостов, чтобы не включать каждый нужный хост индивидуально. Нажимаем Proxy -> SSL Proxying Settings -> Add и заполняем форму как на скриншоте
Открываем на эмулятор сайт еще раз и глянем в Charles
Теперь вместо нулей у нас реальные данные, такие как, размер запроса и ответа, скорость ответа от сервера, dns и много другой инфы.
5. Обход API авторизации
Итак, запускаем наше приложение. Ждем пока всё прогрузится. Для перехвата запроса пытаемся авторизоваться по своему номеру. включаем брекпоинты (правый клик по хосту и включить пункт Breakpoints) для хоста и переходим в режим брекпоинтов (красная галочка на верхней панели) и вводим полученный код.
Видим запрос который проверяет код. Запускаем запрос и смотрим на ответ.
В качестве подтверждения правильности кода, сервер отправил нам JSON ответ. Ладно, сохраним этот json объект, и теперь пытаемся авторизовать с рандомного номера и указываем любой код.
Смотрим ответ от сервера
Сервер сообщает нам что код неверный, по сути так и есть, ведь мы указали рандомный номер и код. А что будет если подставить ответ от успешного входа вместо этого ответа? Меняем JSON ответ
И пускаем ответ к приложению кнопкой Execute. Смотрим что произошло в приложении
Ура! Мы в системе под чужим номером. Хоть это было не совсем сложно, но, мы обошли авторизацию.
6. Заключение
Вся информация была предоставлена исключительно в образовательных целях. Эксплуатация уязвимости была выполнена на реальном примере, в реальном приложении. Т.е. это может встречаться на практике. Зафиксить эту уязвимость очень легко. Достаточно при каждом запросе от клиента, предоставлять ему токен, по которому сервер авторизует юзера, а не JSON объект или иной текст, подтверждающий удачный вход. До скорой встречи!
Последнее редактирование модератором:
