Эскалация привилегий через функционал имперсонации
Я хочу поделиться с вами интересной уязвимостью, которую я обнаружил в одной из программ Bugcrowd. Она была связана с функцией «имперсонации пользователя».
Имперсонация позволяет администраторам «войти от имени» другого пользователя без необходимости знать его учетные данные. Эта функция распространена на платформах, где администраторам может понадобиться отладить проблемы, проверить разрешения пользователей или отреагировать на жалобы.
Администраторы используют имперсонацию для:
• Поиска и устранения проблем, о которых сообщили пользователи.
• Проверки пользовательских настроек.
• Отладки поведения платформы для пользователя.
Например, если пользователь сообщает, что не может получить доступ к своим файлам, администратор может имперсонировать этого пользователя, чтобы протестировать функцию загрузки файлов и выяснить причину проблемы. После завершения расследования администратор завершает сессию имперсонации и возвращается к своей учетной записи администратора.
Как работает имперсонация на целевой системе
Теперь поговорим о целевой системе — example.com. Платформа предоставляет функцию имперсонации пользователей, чтобы помочь им устранить проблемы.
Вот как это работает:
1. Имперсонация пользователя администратором:
◦ Администратор переходит в раздел «Пользователи» и выбирает пользователя, которого хочет имперсонировать.
◦ После нажатия на «Имперсонация» приложение создает новую сессию, позволяющую администратору действовать от имени пользователя.
2. Управление сессиями:
◦ Во время имперсонации оригинальная сессия администратора приостанавливается.
◦ Создается новая сессия имперсонации, которая связывается с имперсонируемым пользователем.
3. Завершение имперсонации:
◦ Когда администратор нажимает «Завершить имперсонацию», он возвращается к своей оригинальной сессии.
Во время исследования функции «Активная сессия» (которая относится к другому endpoint), я обнаружил, что страница отображает все активные сессии, привязанные к учетной записи пользователя, включая те, которые были созданы путем имперсонации.
Пример отображаемой информации:
Я решил завершить все сессии, кроме текущей. Теперь активной осталась только моя сессия.
Теперь, когда администратор начнет имитировать мою учетную запись, мы обнаружим нечто интересное:
Да, когда администратор начинает имитировать мою учетную запись, сессия отображается в разделе Active Sessions с видимым идентификатором сессии двумя способами:
Вариант 1: Проверяя HTML-код страницы для кнопки "Revoke" через инструменты разработчика (F12). Идентификатор сессии указывается в данных запроса:
<button id="revoke-session-1234" class="revoke-button" data-session-id="abcd1234efgh5678ijklmnop">Revoke</button>
Вариант 2: Перехватив HTTP-запрос после нажатия на кнопку "Revoke". Запрос выглядит следующим образом:
POST /users/sessions/revoke HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <access_token>
{
"session_id": "abcd1234efgh5678ijklmnop"
}Я скопировал идентификатор сессии из перехваченного запроса и удалил его. Теперь у меня был временный идентификатор сессии, назначенный администратору, имитирующему мою учетную запись.
Чтобы получить контроль, я:
1. Открыл инструменты разработчика (F12), перешел в раздел Cookies.
2. Заменил идентификатор моей сессии на идентификатор сессии администратора:
Альтернативно, я мог вручную установить идентификатор сессии через консоль:
document.cookie = "_session_id=SESSION_ID";
На этом этапе я вошел в систему как администратор, который использует мою учетную запись.
Эксплуатация уязвимости сработала, потому что временная сессия все еще была активна, и администратор продолжал использовать ее для имитации. По сути, я "перехватил" временную сессию, которую использовал администратор, вместо его исходной сессии.
Когда администратор запрашивает имитацию пользователя, приложение сначала проверяет, является ли он администратором. Если да, то создается временный идентификатор сессии для имитации. Когда администратор завершает имитацию, приложение проверяет идентификатор сессии и восстанавливает исходную сессию администратора.
После получения доступа к учетной записи администратора я нажал кнопку «Завершить имперсонацию», что завершило сессию имитации и восстановило исходную сессию администратора. Однако, поскольку система проверяла только значение временного идентификатора сессии, я смог остаться в системе как администратор, эффективно повысив свои привилегии.
Шаги для эксплуатации уязвимости:
1. Войти в платформу как обычный пользователь (атакующий).
2. Отозвать все сессии на вкладке «Активные сессии», кроме своей собственной.
3. Администратор входит в систему и начинает имитацию учетной записи атакующего.
4. После начала имитации администратор получает временный идентификатор сессии, связанный с учетной записью атакующего.
5. Атакующий исследует HTML-код кнопки «Отозвать» или перехватывает запрос и копирует идентификатор сессии из запроса.
6. Атакующий открывает консоль разработчика (F12), переходит в раздел «Cookies», очищает свои текущие cookie-файлы и заменяет их идентификатором сессии администратора. Затем обновляет страницу.
7. Теперь атакующий вошел в систему как администратор. Затем он может нажать кнопку «Завершить имперсонацию» , которую обычно нажимает администратор.
8. Поскольку сессия атакующего теперь использует временный идентификатор сессии имитации, нажатие «Завершить имитацию» вернет его в исходную сессию администратора.
Компания признала проблему как уязвимость высокой степени опасности и выплатила вознаграждение в размере $1250.
