Кто я
Я Махмуд Круш, студент третьего курса факультета инженерии. Я стремлюсь стать тестировщиком на проникновение и в данный момент подрабатываю охотником за уязвимостями.
Введение
В этом отчете я расскажу о шагах, которые я предпринял для того, чтобы превратить "Pre-Account Takeover" в "Privilege Escalation". Уязвимость возникла из-за отсутствия надлежащего подтверждения электронной почты в процессе создания учетной записи в приложении.
Краткая информация о цели
Целевой платформой была система, предназначенная для создания и размещения веб-страниц, изображений и текста (с использованием интерфейса drag-and-drop). Платформа поддерживает совместную работу через рабочие пространства workSpace, предусматривающие разные уровни привилегий пользователей:
Owner → Обладает полными привилегиями в рабочей области.
Admin → Имеет те же привилегии, что и владелец, за исключением возможности управлять владельцем (удалять или изменять).
Publisher → Может публиковать и редактировать страницы, а также управлять содержимым в пределах публикации.
Editor → Может редактировать существующие страницы и создавать новые, но не может их публиковать.
Guest → Имеет только право просмотра.
Первый шаг
Во время изучения цели — назовем её example.com — я начал узнавать о различных уровнях привилегий на сайте и способах взаимодействия пользователей с платформой.
Зарегистрировавшись на сайте, я заметил, что могу сразу же получить доступ к своему аккаунту, не подтверждая свой адрес электронной почты. Хотя подтверждающее письмо было отправлено, оно не требовалось для активации или обеспечения доступа к аккаунту.
В тот момент я задумался о возможной уязвимости, связанной с предварительным захватом аккаунта. В прошлом, я сообщал об этой проблеме примерно три-четыре раза, но постоянно она помечалась как информативная, поэтому я решил двинуться дальше и прекратить её изучение.
Второй шаг
Исследуя цель как пользователь-гость, я обнаружил, что могу просматривать приглашенных пользователей, которые были в состоянии ожидания (т.е. они были приглашены, но еще не завершили свою регистрацию).
Это привлекло мое внимание — я понял, что потенциально это можно использовать в Pre-Account Takeover сценарии. Я задумался: что, если я смогу зарегистрироваться, используя тот же электронный адрес, который уже был приглашен, и получить доступ с повышенными привилегиями?
Третий шаг
Теперь давайте подумаем о том, как бы я мог принять приглашение, даже если оно отправлено только на электронную почту пользователя. Я пробовал несколько методов, таких как повторное использование ссылок (предыдущие приглашения), но ничего не сработало.
Помогая мне с этой задачей, мой друг обнаружил GraphQL запрос, который возвращал детальную информацию о рабочем пространстве, включая данные о приглашенных пользователях. Я решил исследовать этот запрос дальше, чтобы посмотреть, смогу ли я извлечь какую-либо полезную информацию, которая могла бы помочь в создании успешной атаки Pre-Account Takeover.
Просматривая GraphQL ответ, я нашел раздел, в котором содержалась информация о приглашенных пользователях, и, что самое важное, там был ID приглашения.
Затем я вернулся к анализу процесса принятия приглашения и обнаружил, что он использует мутацию GraphQL, которая требует ID приглашения для завершения процесса. Это было важным открытием — имея ID в открытом доступе, у меня было все необходимое, чтобы попытаться принять приглашение самостоятельно.
Итак, давайте соберем все воедино. Теперь у нас есть полный сценарий, который приводит к повышению привилегий на моем почтовом аккаунте.
Для достижения этого мне понадобились лишь две вещи:
Токен авторизации, который я получил через Pre-Account Takeover.
ID приглашения, который я обнаружил благодаря избыточному раскрытию данных в API (в частности, в ответе GraphQL).
С этими двумя элементами я смог успешно принять приглашение, предназначенное для другого пользователя, и получить доступ к рабочему пространству с привилегиями администратора — используя мой собственный email.
Теперь давайте пройдемся по полному сценарию шаг за шагом, чтобы понять, насколько опасна эта уязвимость на самом деле.
Сценарий атаки
Я начинаю как гость, ожидая, пока владелец пригласит пользователя с привилегиями администратора.
Я беру приглашенный адрес электронной почты и указав его прохожу регистрацю (пользуясь отсутствием подтверждения электронной почты).
С помощью Burp Suite нахожу UserSettingsWorkspace GraphQL запрос в ответе.
Извлекаю ID приглашения из этого ответа (благодаря избыточному раскрытию данных).
Получаю мутацию принятия приглашения (либо из GraphQL, либо из ранее перехваченного запроса).
Заменяю токен авторизации на токен недавно зарегистрированного (контролируемого атакующим) аккаунта, и внедряю ID приглашения.
Теперь я успешно получаю доступ к целевому рабочему пространству и повышаю свои привилегии с гостя до администратора.
Наконец, я удаляю оригинальный приглашенный email (тот, который я перехватил) и приглашаю снова, используя свой собственный email, чтобы полностью захватить роль администратора.
Заключение
В конце концов, отчет был отмечен как дубликат, но, честно говоря, меня это не расстроило. Я участвовал не только ради вознаграждения. Наибольшее значение для меня имел процесс обнаружения чего-либо значимого и совершенствование моих навыков, а затем уже ошибка, которую я хотел найти и нашел.
Еще больше познавательного контента в Telegram-канале — Life-Hack - Хакер