История о том, как я шеринги ломал

39086c48c497ec6c0d92c76ba6d46d11.png

Всех приветствую, дорогие читатели! В этой статье поделюсь с вами историей о том, как я тестировал приложения различных шеринговых сервисов, начиная с сервисов по аренде самокатов/велосипедов и заканчивая повербанками. Моя заинтересованность в тестировании привела к раскрытию различного рода уязвимостей, о которых вы узнаете далее. Приятного чтения!)

Предыстория

Отдельно хочу поблагодарить@tururu_secза участие в моём исследовании. Спасибо!

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

Всё началось с момента, когда по городу начали появляться шеринговые сервисы, а именно самокаты, велосипеды и повербанки. Всегда, когда проходил мимо них, задавался вопросом, а можно ли их взломать? Думаю, подобное чувство многим знакомо:)

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

Подготовка

Для тестирования мне пришлось приобрести БУ смартфон с уже установленными root-правами и модулями Xposed, так как эмуляторы Android не хотели нормально работать из-за отсутствия необходимых ресурсов на моём компьютере, да и мне лично, так было удобнее работать.

Первым делом я установил модуль Xposed под названием «LSposed», куда уже отдельно установил модуль под названием «SSLUnpinning». После установки и запуска модуля, я выбрал несколько приложений для тестирования и проставил им галочки, чтобы модуль внёс все необходимые изменения для обхода SSL Pinning и после чего перезагрузил свой телефон.

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

Уязвимость #1 — Отсутствие Rate Limit

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

Приложение #1

Первую такую проблему я обнаружил в приложении по аренде велосипедов. В главном меню приложения требуется ввести номер телефона, на который в дальнейшем отправляется 4-х значный смс-код, который нужно ввести для подтверждения, чтобы авторизоваться в аккаунте. Первая мысль, которая пришла мне в голову, а могу ли я перебрать код, чтобы попасть в аккаунт? Мысль оказалась верной, код перебрать удалось, никаких ограничений не было!

Рисунок 1 - Этапы авторизации в приложении

Рисунок 1 — Этапы авторизации в приложении

Уязвимость как раз присутствует на 4-ом этапе авторизации во время проверки кода. После обнаружения уязвимости, я сразу связался с разработчиками, предоставил небольшой отчёт и они исправили её в течении месяца и выплатили небольшое денежное вознаграждение.

Рисунок 2 - Связь с разработчиками приложения

Рисунок 2 — Связь с разработчиками приложения

Ниже находятся PoC-и с эксплуатацией уязвимости:

Рисунок 3 - Начало авторизации

Рисунок 3 — Начало авторизации

Здесь происходит основная авторизация

  1. Мы открываем приложение и начинаем вводить номер телефона.

Рисунок 4 - Проверка номера телефона

Рисунок 4 — Проверка номера телефона

  1. Приложение его проверяет, зарегистрирован ли он или нет.

Рисунок 5 - Отправка кода на указанный номер

Рисунок 5 — Отправка кода на указанный номер

  1. Происходит отправка кода на указанный номер

Рисунок 6 - Проверка кода

Рисунок 6 — Проверка кода

  1. И начинается процесс его проверки в параметре «code».

Этот запрос мы отправляем в Intruder > захватываем параметр «code» и выставляем настройки, как указано ниже.

Рисунок 7 - Настройка пэйлоада

Рисунок 7 — Настройка пэйлоада

И нажимаем Start Attack. Ждём результата.

Рисунок 8 - Успешный перебор кода

Рисунок 8 — Успешный перебор кода

Как мы можем с вами видеть, было отправлено 8417 запросов для подбора верного кода. Далее мы копируем результат из параметра message и вставляем его в параметр accessToken и вуаля, мы попадаем в чужой аккаунт!

Рисунок 9 - Авторизация в аккаунте

Рисунок 9 — Авторизация в аккаунте

После того как я сообщил им об уязвимости, они в течении месяца её исправили. После нескольких неудачных попыток отправки кода, сервер сразу же нас блокирует из-за превышения лимита отправляемых запросов. Молодцы, ребята)

Рисунок 10 - Исправление уязвимости

Рисунок 10 — Исправление уязвимости

Они выполнили одну из моих рекомендаций. Вот те самые пункты из отчёта:

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

  2. Использовать 6-ти значные цифры для подтверждения авторизации, чтобы ещё сильнее затруднить перебор цифр. В таком случае злоумышленнику придется отправить 1.000.000 запросов, чтобы угадать верную комбинацию кода. Для 4-х же цифр, необходимо отправить 10.000 запросов.

Приложение #2

Следующее приложение занимается кикшерингом, в небольших городах сдают в аренду электросамокаты. У них я обнаружил точно такую же уязвимость, ниже представлю несколько PoC-ов с её эксплуатацией.

Рисунок 11 - Отправка кода на указанный номер

Рисунок 11 — Отправка кода на указанный номер

Рисунок 12 - Успешный перебор кода

Рисунок 12 — Успешный перебор кода

Было опять отправлено большое количество запросов, и сервер не ограничивал их отправку. Как я им сообщил, её исправили также за месяц.

Рисунок 13 - Исправление уязвимости

Рисунок 13 — Исправление уязвимости

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

Рисунок 14 - Благодарность за сообщение об уязвимости

Рисунок 14 — Благодарность за сообщение об уязвимости

Рисунок 15 - Выплата вознаграждения

Рисунок 15 — Выплата вознаграждения

После сообщения об уязвимости, они проявили инициативу и выплатили мне денежное вознаграждение в размере 20.000р, за что очень приятно и было для меня неожиданным. Считай, это было моё первое самое крупное денежное вознаграждение за найденную уязвимость!

Если сотрудники читают эту статью, то передаю вам огромный привет, относитесь к честным баг-хантерам так и дальше, это правда важно!)

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

Рисунок 16 - Ввод незарегистрированного номера

Рисунок 16 — Ввод незарегистрированного номера

Рисунок 17 - Ввод зарегистрированного номера

Рисунок 17 — Ввод зарегистрированного номера

Как мы видим, если в параметр phone ввести номер незарегистрированного пользователя, то в ответе мы получил false, в ином же случае мы получим ответ true, что означает что пользователь зарегистрирован.

Уязвимость не особо критичная, но может использоваться для сбора информации.

Приложение #3

Такая же уязвимость была обнаружена в приложении по аренде и сдаче парковочных мест.

Рисунок 18 - Получение доступа к аккаунту

Рисунок 18 — Получение доступа к аккаунту

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

После сообщения об уязвимости и предоставления отчёта, через какое-то определенное время они сообщили, что её устранили ещё до получения моего письма. Видимо, заметили мою активность и поняли в чём дело:)

Рисунок 19 - Ответ на сообщение об уязвимости

Рисунок 19 — Ответ на сообщение об уязвимости

Приложение #4 и #5

Такая же уязвимость была обнаружена и в 2-ух приложениях. Оба эти приложения работают по одному и тому же домену, видимо кто-то из них является агрегатором. Причём, регистрация требуется в каждом приложении.

Рисунок 20 - Получение доступа к аккаунту

Рисунок 20 — Получение доступа к аккаунту

Ну и ситуация точно такая же, перебираем код и получаем доступ к аккаунту.

Уязвимость #2 — Раскрытие информации

Следующая уязвимость была обнаружена в другом шеринговом сервисе.

Уязвимость возникала при обращении к ресурсу после истечения токена пользователя, когда приложение сообщало о том, что доступ к ресурсу запрещён из-за отсутствия авторизации (HTTP-код 401) и вместе с ним появлялась ошибка, которая раскрывала внутренние пути системы и используемые библиотеки, включая их версии.

Рисунок 21 - Раскрытие информации

Рисунок 21 — Раскрытие информации

Знание этой информации может быть полезна для этапа разведки и в дальнейшем поиска эксплойтов под конкретную версию библиотек. В общем, всё что необходимо для планирования атаки:)

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

Вроде и хорошо, что нашёл, но и плохо, что не исправили:(

Уязвимость #3 — Open Redirect

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

Уязвимость возникала при генерации ссылок промокода, когда приложение автоматически её генерирует, отправляя свой URL-адрес.

Рисунок 22 - Генерация короткой ссылки

Рисунок 22 — Генерация короткой ссылки

В параметре «link» мы можем указать любой другой URL-адрес, сервер успешно его примет и сгенерирует короткую ссылку под своим именем.

Рисунок 23 - Генерация ссылки с произвольным адресом

Рисунок 23 — Генерация ссылки с произвольным адресом

На рисунке выше, мы успешно замаскировали введённую ссылку под их именем. Злоумышленники могут распространять вредоносные ссылки под видом легитимного адреса, что в последствии может сказаться на репутации компании. Но мы проверять это не будем, мы же белые;)

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

Заключение

Как мы с вами видим, в каждом приложении существовала уязвимость, от низкой до критической степени серьезности. Все разработчики были уведомлены об уязвимостях, большая часть была исправлена, а некоторые просто неоднократно проигнорировали мои обращения.

Изначальная цель моего исследования: протестировать и попробовать воспользоваться шерингами бесплатно, но результаты меня всё равно порадовали, что даже простой перебор мог привести к полному захвату учётной записи пользователя. Очевидная и простая в эксплуатации уязвимость.

В общем, не теряйте исследовательский интерес, пробуйте и исследуйте, всегда найдете что-то интересное;)

Удачи, баг-хантеры!)

P.s Кстати, в свободное время я веду свой личный телеграмм канал по переводу статей и книг по информационной безопасности. Если кому интересно — подписывайтесь!)

© Habrahabr.ru