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

Я не имею права раскрывать информацию о цели, поэтому давайте назовём её example.com. Это был обычный сайт. Ничего особенного: можно создать аккаунт, войти, поменять пароль и так далее.

Как обычно, я создал два аккаунта. Сначала зарегистрировался и вошёл в аккаунт жертвы, после чего проверил все запросы и ответы через Burp Suite. Я обнаружил, что сайт использует какой-то CSRF-токен для защиты от CSRF-атак. В исходном коде страницы я заметил, что сайтом каждому пользователю присваивается userID. Это шестизначный идентификатор, поэтому его можно легко угадать.

Далее я перешёл в настройки аккаунта, изменил часть своей информации (я всё ещё нахожусь в аккаунте жертвы) и зафиксировал этот запрос.

Теперь я зарегистрировался и вошёл в аккаунт атакующего. Потом попытался через функцию смены имени пользователя изменить данные жертвы (как видно на скриншоте выше) — и… БАЦ, ничего не произошло.

Я также проверил страницу смены электронной почты, но, похоже, без CSRF-токена жертвы нельзя изменить никакую информацию. Я пытался убрать CSRF-токен, заменить POST на GET и так далее — ничего не помогало.

Тогда я начал изучать другие функции сайта. Пора проверить, как реализована смена пароля. Чтобы изменить пароль, нужно ввести текущий пароль, а затем новый. Я обнаружил, что если убрать параметр текущего пароля, всё равно можно изменить пароль пользователя.

Итак, я мог сменить свой пароль, без знания старого. Иногда это P4 проблема, иногда P5, точно не знаю. Я не стал это репортить и на несколько часов сделал паузу.

Когда я не занимаюсь взломом, я общаюсь с другими хакерами. Я позвонил своему другу, который нашёл CSRF баг в своей частной программе и смог включать и выключать уведомления любого пользователя. Я спросил его, почему бы не попробовать поменять email или имя другого пользователя и т.д. Он сказал, что сайт проверяет CSRF-токен на странице изменения информации, но не на странице переключения уведомлений. После разговора с ним я сел за ноутбук и решил проверить, валидируется ли токен CSRF на странице смены пароля.

Я обнаружил, что если убрать csrf_token и вместо него использовать null, например так:

Я могу сменить свой пароль. Но всё равно это P4, потому что если я захочу изменить пароль другого пользователя, мне необходимо знать его email (чтобы войти в аккаунт).

Если внимательно посмотришь на скриншот, то увидишь, что там нет userID. Я попытался проверить /api/user/userID/change_password и другие подобные эндпоинты. Но ничего не произошло...

Пора сделать последнюю попытку. Я подумал, а что если использовать userID в теле JSON? Может получится найти что-то интереснее? Но я не знаю название параметра, поэтому пришло время использовать Param Miner.

Если вы не знаете, что такое Param Miner, это бесплатное расширение для Burp Suite. Оно помогает находить скрытые, неявные параметры.

Нам нужно найти скрытый параметр в JSON-теле, поэтому выберем вариант Guess JSON parameter.

Через несколько минут я нашёл параметр uid. Теперь ты, наверное, догадываешься, что я собираюсь сделать. Да, я использую параметр uid в теле JSON для смены пароля. Теперь я могу менять пароли всех пользователей без их участия.

Вы можете сказать: «Всё равно ты не знаешь email других пользователей. Значит, ты можешь сменить пароль, но не войти в их аккаунт, потому что не знаешь их email».

Да, вы правы, но я сообщил об этом и указал в своём отчёте: я тестировал только свой аккаунт, но если вы хотите увидеть наглядный эффект, я могу сменить пароли всех пользователей и войти, например, в admin@website.com.

После того, как я сообщил об этом, команда ответила мне, исправила проблему и наградила меня $1000.

Надеюсь вам было интересно читать.

Ещё больше познавательного контента в Telegram-канале — Life-Hack - Хакер