От раскрытия информации до интересного повышения привилегий

[Benzema]

​

Данная статья является переводом и ведется со слов автора. Оригинал тут.

Программа bug bounty, в которой была обнаружена эта уязвимость, не разрешила публичное раскрытие. Поэтому буду называть ее как REDACTED.com.

Резюме:​

В этом веб-приложении (subdomain.REDACTED.com) пользователи могут создать денежную программу для своей собственной компании.

Я смог найти классное раскрытие информации, которое в конечном итоге привело меня к тому, что я стал администратором приложения.

Описание:​

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

Однако мое внимание привлекла функция «Редактировать учетную запись».

Я открыл Burp Suite и перехватил запрос после редактирования некоторых полей в моем профиле. Там я увидел , что запрос был отправлен к следующей конечной точке:

/ProgramManagerREDACTED/REDACTED/updateuser

Метод запроса был «PUT» с множеством параметров, но что бросилось в глаза, так это «role_id» и «user_info_id»:

Итак, первое, что я сделал, - изменил значение параметра «role_id» с 1 на 2. Однако ответ сервера был «401 Unauthorized» :(

(Не забываем, что у нас еще есть второй параметр, с которым можно поиграть, но оставим его на потом)

Поиграв с конечной точкой (/ProgramManagerREDACTED/REDACTED/updateuser) я удалил тело запроса и две последние директории и изменил запрос «PUT» на «GET». Ответ сервера был «200 OK», а тело ответа содержало обширную информацию о скрытых конечных точках:

Тело ответа было довольно большим, поэтому я решил поискать по нескольким ключевым словам, таким как admin, passwords, user и т. д.

Ключевое слово «user» привело к интересной конечной точке:

/ProgramManagerREDACTED/userInfoDetailsEntities

Попадание в эту конечную точку с помощью запроса «GET» меня поразило. Тело ответа сервера содержало огромные утечки информации о каждом пользователе в веб-приложении (здесь я также понял, что существует четыре идентификатора ролей):

Обнаружив такую утечку информации я подумал о том, чтобы сразу отправить отчет об уязвимости в BugCrowd, но что-то внутри меня подсказало мне, что есть еще кое-что, так что ... я продолжил копать и пытаться найти что-то круче:)

Поэтому я отправил другой запрос к этой конечной точке, но теперь я использовал свое значение «user_info_id» для поиска только информации о моем пользователе:

/ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}

Я смог увидеть информацию о моем пользователе в ответе сервера, включая «role_id» и «mail» (еще одна важная деталь, то что почта не была представлена в виде открытого текста, а была некоторым хешем):

Я решил выполнить первый запрос («Изменить учетную запись») с тем же исходным телом запроса, но изменив конечную точку на ту, которую я только что нашел:

/ProgramManagerREDACTED/userInfoDetailsEntities/{user_info_id}

Поэтому я отправил «PUT» запрос, с изменением значения параметра «role_id» на «4» и значения параметра «mail» на хэш-почту.

Мой Burp Suite не отвечал, поэтому я подумал про себя, что я больше ничего не могу сделать. НО, через 5 секунд я получил ответ от сервера с кодом состояния «200 OK», и я понял, что role_id был успешно изменен; Я БЫЛ ШОКИРОВАН!

role_id успешно изменен на 4 (admin)
Я вышел из приложения, а затем заново вошел в систему, и я был уже администратором!!

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

Через 10 минут после отправки ошибки в BugCrowd она была определена как критическая уязвимость и устранена в течение 1 дня.

Вывод:​

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