История о том, как я шеринги ломал
Всех приветствую, дорогие читатели! В этой статье поделюсь с вами историей о том, как я тестировал приложения различных шеринговых сервисов, начиная с сервисов по аренде самокатов/велосипедов и заканчивая повербанками. Моя заинтересованность в тестировании привела к раскрытию различного рода уязвимостей, о которых вы узнаете далее. Приятного чтения!)
Предыстория
Отдельно хочу поблагодарить@tururu_secза участие в моём исследовании. Спасибо!
Сразу скажу, что в этой статье не будет разглашаться информация о тестируемых приложениях и сервисах в целях конфиденциальности и безопасности.
Всё началось с момента, когда по городу начали появляться шеринговые сервисы, а именно самокаты, велосипеды и повербанки. Всегда, когда проходил мимо них, задавался вопросом, а можно ли их взломать? Думаю, подобное чувство многим знакомо:)
Мне было очень интересно узнать как они работают и как выглядит общение между мобильным приложением и самой техникой.
Подготовка
Для тестирования мне пришлось приобрести БУ смартфон с уже установленными root-правами и модулями Xposed, так как эмуляторы Android не хотели нормально работать из-за отсутствия необходимых ресурсов на моём компьютере, да и мне лично, так было удобнее работать.
Первым делом я установил модуль Xposed под названием «LSposed», куда уже отдельно установил модуль под названием «SSLUnpinning». После установки и запуска модуля, я выбрал несколько приложений для тестирования и проставил им галочки, чтобы модуль внёс все необходимые изменения для обхода SSL Pinning и после чего перезагрузил свой телефон.
Далее я запустил Burp Suite, настроил прокси-сервер в настройках WiFi, подключил к нему смартфон, выгрузил сертификат и сделал его системным. Никаких манипуляций с Frida выполнять не приходилось, сделать сертификат Burp корневым было достаточным для тестирования.
Уязвимость #1 — Отсутствие Rate Limit
Да-да, в нескольких приложениях я обнаружил одинаковую проблему, а именно отсутствие ограничений при отправке запросов. Проблема была обнаружена при проверке кода для авторизации в аккаунте жертвы. Простыми словами, злоумышленник мог перебрать 4-х значный код пользователя и попасть в его аккаунт. Её эксплуатацию может выполнить абсолютно любой.
Приложение #1
Первую такую проблему я обнаружил в приложении по аренде велосипедов. В главном меню приложения требуется ввести номер телефона, на который в дальнейшем отправляется 4-х значный смс-код, который нужно ввести для подтверждения, чтобы авторизоваться в аккаунте. Первая мысль, которая пришла мне в голову, а могу ли я перебрать код, чтобы попасть в аккаунт? Мысль оказалась верной, код перебрать удалось, никаких ограничений не было!
Рисунок 1 — Этапы авторизации в приложении
Уязвимость как раз присутствует на 4-ом этапе авторизации во время проверки кода. После обнаружения уязвимости, я сразу связался с разработчиками, предоставил небольшой отчёт и они исправили её в течении месяца и выплатили небольшое денежное вознаграждение.
Рисунок 2 — Связь с разработчиками приложения
Ниже находятся PoC-и с эксплуатацией уязвимости:
Рисунок 3 — Начало авторизации
Здесь происходит основная авторизация
Мы открываем приложение и начинаем вводить номер телефона.
Рисунок 4 — Проверка номера телефона
Приложение его проверяет, зарегистрирован ли он или нет.
Рисунок 5 — Отправка кода на указанный номер
Происходит отправка кода на указанный номер
Рисунок 6 — Проверка кода
И начинается процесс его проверки в параметре «code».
Этот запрос мы отправляем в Intruder > захватываем параметр «code» и выставляем настройки, как указано ниже.
Рисунок 7 — Настройка пэйлоада
И нажимаем Start Attack. Ждём результата.
Рисунок 8 — Успешный перебор кода
Как мы можем с вами видеть, было отправлено 8417 запросов для подбора верного кода. Далее мы копируем результат из параметра message и вставляем его в параметр accessToken и вуаля, мы попадаем в чужой аккаунт!
Рисунок 9 — Авторизация в аккаунте
После того как я сообщил им об уязвимости, они в течении месяца её исправили. После нескольких неудачных попыток отправки кода, сервер сразу же нас блокирует из-за превышения лимита отправляемых запросов. Молодцы, ребята)
Рисунок 10 — Исправление уязвимости
Они выполнили одну из моих рекомендаций. Вот те самые пункты из отчёта:
Включить на стороне сервера лимит отправляемых пользователем запросов, чтобы затруднить перебор цифр.
Использовать 6-ти значные цифры для подтверждения авторизации, чтобы ещё сильнее затруднить перебор цифр. В таком случае злоумышленнику придется отправить 1.000.000 запросов, чтобы угадать верную комбинацию кода. Для 4-х же цифр, необходимо отправить 10.000 запросов.
Приложение #2
Следующее приложение занимается кикшерингом, в небольших городах сдают в аренду электросамокаты. У них я обнаружил точно такую же уязвимость, ниже представлю несколько PoC-ов с её эксплуатацией.
Рисунок 11 — Отправка кода на указанный номер
Рисунок 12 — Успешный перебор кода
Было опять отправлено большое количество запросов, и сервер не ограничивал их отправку. Как я им сообщил, её исправили также за месяц.
Рисунок 13 — Исправление уязвимости
После отправки нескольких запросов с неверным смс-кодом, сервер тут же его забывает и сообщает нам о том, что смс-код не найден.
Рисунок 14 — Благодарность за сообщение об уязвимости
Рисунок 15 — Выплата вознаграждения
После сообщения об уязвимости, они проявили инициативу и выплатили мне денежное вознаграждение в размере 20.000р, за что очень приятно и было для меня неожиданным. Считай, это было моё первое самое крупное денежное вознаграждение за найденную уязвимость!
Если сотрудники читают эту статью, то передаю вам огромный привет, относитесь к честным баг-хантерам так и дальше, это правда важно!)
Вместе с отчётом об уязвимости я тут же упомянул и про другую уязвимость низкого уровня, которая не является очень критичной, но может использоваться для парсинга зарегистрированных пользователей в мобильном приложении.
Рисунок 16 — Ввод незарегистрированного номера
Рисунок 17 — Ввод зарегистрированного номера
Как мы видим, если в параметр phone ввести номер незарегистрированного пользователя, то в ответе мы получил false, в ином же случае мы получим ответ true, что означает что пользователь зарегистрирован.
Уязвимость не особо критичная, но может использоваться для сбора информации.
Приложение #3
Такая же уязвимость была обнаружена в приложении по аренде и сдаче парковочных мест.
Рисунок 18 — Получение доступа к аккаунту
Здесь ситуация аналогичная, после отправки большого количества запросов, мы успешно перебрали отправленный пользователю смс-код и попали в аккаунт.
После сообщения об уязвимости и предоставления отчёта, через какое-то определенное время они сообщили, что её устранили ещё до получения моего письма. Видимо, заметили мою активность и поняли в чём дело:)
Рисунок 19 — Ответ на сообщение об уязвимости
Приложение #4 и #5
Такая же уязвимость была обнаружена и в 2-ух приложениях. Оба эти приложения работают по одному и тому же домену, видимо кто-то из них является агрегатором. Причём, регистрация требуется в каждом приложении.
Рисунок 20 — Получение доступа к аккаунту
Ну и ситуация точно такая же, перебираем код и получаем доступ к аккаунту.
Уязвимость #2 — Раскрытие информации
Следующая уязвимость была обнаружена в другом шеринговом сервисе.
Уязвимость возникала при обращении к ресурсу после истечения токена пользователя, когда приложение сообщало о том, что доступ к ресурсу запрещён из-за отсутствия авторизации (HTTP-код 401) и вместе с ним появлялась ошибка, которая раскрывала внутренние пути системы и используемые библиотеки, включая их версии.
Рисунок 21 — Раскрытие информации
Знание этой информации может быть полезна для этапа разведки и в дальнейшем поиска эксплойтов под конкретную версию библиотек. В общем, всё что необходимо для планирования атаки:)
Уязвимость, к сожалению, остается актуальной по сей день. Мои неоднократные обращения были проигнорированы и не доведены до конца.
Вроде и хорошо, что нашёл, но и плохо, что не исправили:(
Уязвимость #3 — Open Redirect
Следующая уязвимость была обнаружена в том же приложении, где и была найдена уязвимость раскрытия информации.
Уязвимость возникала при генерации ссылок промокода, когда приложение автоматически её генерирует, отправляя свой URL-адрес.
Рисунок 22 — Генерация короткой ссылки
В параметре «link» мы можем указать любой другой URL-адрес, сервер успешно его примет и сгенерирует короткую ссылку под своим именем.
Рисунок 23 — Генерация ссылки с произвольным адресом
На рисунке выше, мы успешно замаскировали введённую ссылку под их именем. Злоумышленники могут распространять вредоносные ссылки под видом легитимного адреса, что в последствии может сказаться на репутации компании. Но мы проверять это не будем, мы же белые;)
Здесь же рекомендации довольно очевидные — использовать белый список доменов для которых разрешена генерация ссылок, а все остальные другие вовсе запрещать.
Заключение
Как мы с вами видим, в каждом приложении существовала уязвимость, от низкой до критической степени серьезности. Все разработчики были уведомлены об уязвимостях, большая часть была исправлена, а некоторые просто неоднократно проигнорировали мои обращения.
Изначальная цель моего исследования: протестировать и попробовать воспользоваться шерингами бесплатно, но результаты меня всё равно порадовали, что даже простой перебор мог привести к полному захвату учётной записи пользователя. Очевидная и простая в эксплуатации уязвимость.
В общем, не теряйте исследовательский интерес, пробуйте и исследуйте, всегда найдете что-то интересное;)
Удачи, баг-хантеры!)
P.s Кстати, в свободное время я веду свой личный телеграмм канал по переводу статей и книг по информационной безопасности. Если кому интересно — подписывайтесь!)
