Всех приветствую, дорогие читатели! В этой статье поделюсь с вами историей о том, как я тестировал приложения различных шеринговых сервисов, начиная с сервисов по аренде самокатов/велосипедов и заканчивая повербанками. Моя заинтересованность в тестировании привела к раскрытию различного рода уязвимостей, о которых вы узнаете далее. Приятного чтения!) Отдельно хочу поблагодарить@tururu_secза участие в моём исследовании. Спасибо! Сразу скажу, что в этой статье не будет разглашаться информация о тестируемых приложениях и сервисах в целях конфиденциальности и безопасности. Всё началось с момента, когда по городу начали появляться шеринговые сервисы, а именно самокаты, велосипеды и повербанки. Всегда, когда проходил мимо них, задавался вопросом, а можно ли их взломать? Думаю, подобное чувство многим знакомо:) Мне было очень интересно узнать как они работают и как выглядит общение между мобильным приложением и самой техникой. Для тестирования мне пришлось приобрести БУ смартфон с уже установленными root-правами и модулями Xposed, так как эмуляторы Android не хотели нормально работать из-за отсутствия необходимых ресурсов на моём компьютере, да и мне лично, так было удобнее работать. Первым делом я установил модуль Xposed под названием "LSposed", куда уже отдельно установил модуль под названием "SSLUnpinning". После установки и запуска модуля, я выбрал несколько приложений для тестирования и проставил им галочки, чтобы модуль внёс все необходимые изменения для обхода SSL Pinning и после чего перезагрузил свой телефон. Далее я запустил Burp Suite, настроил прокси-сервер в настройках WiFi, подключил к нему смартфон, выгрузил сертификат и сделал его системным. Никаких манипуляций с Frida выполнять не приходилось, сделать сертификат Burp корневым было достаточным для тестирования. Да-да, в нескольких приложениях я обнаружил одинаковую проблему, а именно отсутствие ограничений при отправке запросов. Проблема была обнаружена при проверке кода для авторизации в аккаунте жертвы. Простыми словами, злоумышленник мог перебрать 4-х значный код пользователя и попасть в его аккаунт. Её эксплуатацию может выполнить абсолютно любой. Первую такую проблему я обнаружил в приложении по аренде велосипедов. В главном меню приложения требуется ввести номер телефона, на который в дальнейшем отправляется 4-х значный смс-код, который нужно ввести для подтверждения, чтобы авторизоваться в аккаунте. Первая мысль, которая пришла мне в голову, а могу ли я перебрать код, чтобы попасть в аккаунт? Мысль оказалась верной, код перебрать удалось, никаких ограничений не было! Уязвимость как раз присутствует на 4-ом этапе авторизации во время проверки кода. После обнаружения уязвимости, я сразу связался с разработчиками, предоставил небольшой отчёт и они исправили её в течении месяца и выплатили небольшое денежное вознаграждение. Ниже находятся PoC-и с эксплуатацией уязвимости: Здесь происходит основная авторизация Мы открываем приложение и начинаем вводить номер телефона. Приложение его проверяет, зарегистрирован ли он или нет. Происходит отправка кода на указанный номер И начинается процесс его проверки в параметре "code". Этот запрос мы отправляем в Intruder > захватываем параметр "code" и выставляем настройки, как указано ниже. И нажимаем Start Attack. Ждём результата. Как мы можем с вами видеть, было отправлено 8417 запросов для подбора верного кода. Далее мы копируем результат из параметра message и вставляем его в параметр accessToken и вуаля, мы попадаем в чужой аккаунт! После того как я сообщил им об уязвимости, они в течении месяца её исправили. После нескольких неудачных попыток отправки кода, сервер сразу же нас блокирует из-за превышения лимита отправляемых запросов. Молодцы, ребята) Они выполнили одну из моих рекомендаций. Вот те самые пункты из отчёта: Включить на стороне сервера лимит отправляемых пользователем запросов, чтобы затруднить перебор цифр. Использовать 6-ти значные цифры для подтверждения авторизации, чтобы ещё сильнее затруднить перебор цифр. В таком случае злоумышленнику придется отправить 1.000.000 запросов, чтобы угадать верную комбинацию кода. Для 4-х же цифр, необходимо отправить 10.000 запросов. Следующее приложение занимается кикшерингом, в небольших городах сдают в аренду электросамокаты. У них я обнаружил точно такую же уязвимость, ниже представлю несколько PoC-ов с её эксплуатацией. Было опять отправлено большое количество запросов, и сервер не ограничивал их отправку. Как я им сообщил, её исправили также за месяц. После отправки нескольких запросов с неверным смс-кодом, сервер тут же его забывает и сообщает нам о том, что смс-код не найден. После сообщения об уязвимости, они проявили инициативу и выплатили мне денежное вознаграждение в размере 20.000р, за что очень приятно и было для меня неожиданным. Считай, это было моё первое самое крупное денежное вознаграждение за найденную уязвимость!! Если сотрудники читают эту статью, то передаю вам огромный привет, относитесь к честным баг-хантерам так и дальше, это правда важно!) Вместе с отчётом об уязвимости я тут же упомянул и про другую уязвимость низкого уровня, которая не является очень критичной, но может использоваться для парсинга зарегистрированных пользователей в мобильном приложении. Как мы видим, если в параметр phone ввести номер незарегистрированного пользователя, то в ответе мы получил false, в ином же случае мы получим ответ true, что означает что пользователь зарегистрирован. Уязвимость не особо критичная, но может использоваться для сбора информации. Такая же уязвимость была обнаружена в приложении по аренде и сдаче парковочных мест. Здесь ситуация аналогичная, после отправки большого количества запросов, мы успешно перебрали отправленный пользователю смс-код и попали в аккаунт. После сообщения об уязвимости и предоставления отчёта, через какое-то определенное время они сообщили, что её устранили ещё до получения моего письма. Видимо, заметили мою активность и поняли в чём дело:) Такая же уязвимость была обнаружена и в 2-ух приложениях. Оба эти приложения работают по одному и тому же домену, видимо кто-то из них является агрегатором. Причём, регистрация требуется в каждом приложении. Ну и ситуация точно такая же, перебираем код и получаем доступ к аккаунту. Следующая уязвимость была обнаружена в другом шеринговом сервисе. Уязвимость возникала при обращении к ресурсу после истечения токена пользователя, когда приложение сообщало о том, что доступ к ресурсу запрещён из-за отсутствия авторизации (HTTP-код 401) и вместе с ним появлялась ошибка, которая раскрывала внутренние пути системы и используемые библиотеки, включая их версии. Знание этой информации может быть полезна для этапа разведки и в дальнейшем поиска эксплойтов под конкретную версию библиотек. В общем, всё что необходимо для планирования атаки:) Уязвимость, к сожалению, остается актуальной по сей день. Мои неоднократные обращения были проигнорированы и не доведены до конца. Вроде и хорошо, что нашёл, но и плохо, что не исправили:( Следующая уязвимость была обнаружена в том же приложении, где и была найдена уязвимость раскрытия информации. Уязвимость возникала при генерации ссылок промокода, когда приложение автоматически её генерирует, отправляя свой URL-адрес. В параметре "link" мы можем указать любой другой URL-адрес, сервер успешно его примет и сгенерирует короткую ссылку под своим именем. На рисунке выше, мы успешно замаскировали введённую ссылку под их именем. Злоумышленники могут распространять вредоносные ссылки под видом легитимного адреса, что в последствии может сказаться на репутации компании. Но мы проверять это не будем, мы же белые ;) Здесь же рекомендации довольно очевидные - использовать белый список доменов для которых разрешена генерация ссылок, а все остальные другие вовсе запрещать. Как мы с вами видим, в каждом приложении существовала уязвимость, от низкой до критической степени серьезности. Все разработчики были уведомлены об уязвимостях, большая часть была исправлена, а некоторые просто неоднократно проигнорировали мои обращения. Изначальная цель моего исследования: протестировать и попробовать воспользоваться шерингами бесплатно, но результаты меня всё равно порадовали, что даже простой перебор мог привести к полному захвату учётной записи пользователя. Очевидная и простая в эксплуатации уязвимость. В общем, не теряйте исследовательский интерес, пробуйте и исследуйте, всегда найдете что-то интересное;) Удачи, баг-хантеры!) P.s Кстати, в свободное время я веду свой личный телеграмм канал по переводу статей и книг по информационной безопасности. Если кому интересно - подписывайтесь!)  Исследователь по информационной безопасности