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

Предыстория

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

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

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

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

Подготовка

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

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

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

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

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

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

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

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

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

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

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

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

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

4. И начинается процесс его проверки в параметре "code".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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