От Гостя до Администратора: Объединяем Pre-Account Takeover с Privilege Escalation

Кто я

Я Махмуд Круш, студент третьего курса факультета инженерии. Я стремлюсь стать тестировщиком на проникновение и в данный момент подрабатываю охотником за уязвимостями.

Введение

В этом отчете я расскажу о шагах, которые я предпринял для того, чтобы превратить «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 — Хакер