Иногда небольшие баги, которые часто встречаются в проектах, при совместной эксплуатации могут привести к критичным последствиям. Например, уязвимости IDOR и XSS, в совокупности с неправильной настройкой CSP, могут быть использованы для обхода защиты и захвата учетных записей пользователей.
Рассмотрим один из таких проектов – сервис, через который доступна покупка услуг, где эксплуатация нескольких уязвимостей с невысоким импактом привела к захвату аккаунтов.
Для начала стоит рассказать об уязвимостях, который были обнаружены довольно быстро, но сами по себе не могли привести к каким-то серьезным последствиям.
Обнаруженные уязвимости
Проведение анализа защищенности нового проекта мы начали с изучения основных пользовательских функций. В первую очередь внимание привлёк интерфейс, связанный с обработкой заявок — возвратами и обменами, а также возможностью комментирования этих заявок.
При дальнейшем изучении стало очевидно, что один из параметров, отвечающих за идентификацию заявки, передаётся в запросе в формате обычного числового значения. Это вызвало интерес: мы решили проверить, как система отреагирует на подмену этого значения.
Так была обнаружена первая уязвимость — IDOR (Insecure Direct Object Reference). Оказалось, что пользователь, зная идентификатор чужой заявки, может добавить в неё собственный комментарий. При этом проверка прав доступа на стороне сервера либо отсутствует, либо реализована некорректно.
Для эксплуатации такой уязвимости достаточно отправить следующий запрос:
Следующей найденной уязвимостью стала Stored XSS, обнаруженная также в комментариях к заявкам. Полезная нагрузка, добавленная в комментарий, сохранялась и обрабатывалась при открытии заявки. Дальше появилась идея: а что если попробовать использовать уязвимость IDOR в связке с Stored XSS, чтобы внедрить вредоносный скрипт не просто в свой комментарий, а в комментарий к чужой заявке?
Пример такого запроса, в котором происходит эксплуатация сразу двух уязвимостей выглядит следующим образом:
Однако, эксплуатация XSS уязвимости осложнялась наличием Content Security Policy – HTTP-заголовка, который сообщает браузеру, что разрешается выполнение скриптов только из ограниченного списка источников.
Поскольку на данном этапе дальнейшая эксплуатация XSS была затруднена, мы приняли решение продолжить исследование других частей интерфейса.
В ходе дальнейшего изучения была обнаружена уязвимость Open Redirect, позволяющая перенаправить пользователя на внешний сервис:
Content Security Policy и её недостатки
В ходе дальнейшего исследования выяснилось, что политику CSP в приложении можно обойти, поскольку в директиве script-src не указан флаг strict-dynamic, а разрешён список источников, из которых могут выполняться скрипты. Также присутствует флаг unsafe-eval, что позволяет использовать конструкции вроде eval() или Function().
Мы обратили внимание на то, что в список “разрешённых” источников попал сайт yastatic.net, откуда загружаются скрипты Яндекса:
Библиотека AngularJS версии 1.6.4, которая также доступна для скачивания с этого домена, может быть использована для внедрения вредоносного кода. AngularJS версии 1.6.x позволяет использовать expression-синтаксис прямо в HTML-атрибутах. А если есть unsafe-eval — можно сделать даже eval() через expression внутри тега <i>:
<code><i ng-app>{{$on.constructor('alert(1)')()}}</i>
Мы можем подключить этот JS-файл, используя обнаруженную уязвимость Open Redirect. Согласно спецификации CSP, браузер будет игнорировать путь, указанный после редиректа. О данной особенности можно почитать подробнее — https://www.w3.org/TR/CSP3/#source-list-paths-and-redirects.
Ниже продемонстрирована полезная нагрузка, позволяющая полноценно провести эксплуатацию XSS уязвимости, обойдя при этом политику CSP:
<iframe srcdoc="<script src='https://site.ru/auth?redirect=https://yastatic.net/s3/milab/js/angular.min.js'></script><i ng-app>{{$on.constructor('alert(origin)')()}}</i>"></iframe>
Перехват учетных данных
Сами по себе уязвимости IDOR + XSS + CSP — не уникальны и достаточно часто встречаются в веб-приложениях. Но в данном случае интерес представляет то, как эти уязвимости можно было использовать в процессе SSO-авторизации.
Пошаговая эксплуатация:
1. В комментарий к чужой заявке через уязвимость IDOR вставляется следующую полезную нагрузку:
Декодированный пэйлоад из eval:
2. На этом этапе вставляются четыре cookie (a, b, c, d) по 4095 байт, чтобы перегрузить заголовки запроса. Такой подход называют cookie bomb — техника, когда создаются огромные cookie специально для того, чтобы превысить лимит размера HTTP-заголовков. Сервер, получив такой запрос, просто не может его корректно обработать и вместо нормального ответа возвращает ошибку. В результате — не происходит ни перенаправления, ни очистки URL, а code и session остаются прямо в адресной строке.
3. Далее инициализируется процесс SSO путем добавления iframe с URL https://site.ru/auth?redirect=/.
После перехода по нему, сервер пытается обработать code и session, однако, из-за переполнения заголовков возникает ошибка.
4. Так как данные (code, session) все еще находятся в URL, вредоносный код может вытащить их и отправить на внешний сервер:
5. Если злоумышленник успеет открыть полученный URL в течение 5 секунд, он сможет инициировать авторизацию под жертвой, получив полноценный доступ к аккаунту
Заключение
Вся цепочка — от безобидного IDOR до полного захвата аккаунта — демонстрирует, что даже такие простые уязвимости могут стать критическими при их комбинировании.
Пентест
Вы можете нанять одну из лучших команд хакеров в мире для проведения тестирования на проникновение.
Мы работаем как с крупными корпорациями, так и со стартапами, знаем про требования регуляторов, нужды бизнеса и реальные угрозы.