Где и как искать этот ваш SSRF: первые шаги в багхантинге

Привет, меня зовут Олег Уланов (aka brain). Я занимаюсь пентестами веб-приложений и активно участвую в багбаунти, зарабатывая на чужих ошибках. Свой путь в наступательной безопасности я начал совсем недавно, но, несмотря на это, меньше чем за год мне удалось ворваться в топ-10 исследователей на Standoff Bug Bounty (сейчас я на 5-м месте — можете проверить ).

В своем дебютном посте кратко расскажу об уязвимости с подделкой запросов на стороне сервера (SSRF) и ее видах, покажу, как обнаруживать этот баг и почему его стоит искать даже на статических сайтах, а заодно подсвечу особенности работы с Burp Suite, Collaborator Everywhere и Wappalyzer. Статья будет полезна для прокачки скилов и поможет легче и быстрее обнаруживать SSRF в сервисах, размещенных на площадках багбаунти.

Статью можно послушать — если удобнее, включайте стрим.

Тем, кто еще сомневается и думает, что багхантить — это очень сложно, советую посмотреть остальные выпуски (например, здесь и здесь). Ребята из комьюнити Standoff Bug Bounty вспоминают, как они начинали охотиться за багами, и делятся с новичками лайфхаками.

Пролог

Существуют два вида атак на веб-приложения: атаки на его клиентскую часть и на серверную.

Главная героиня моего рассказа — уязвимость server-side request forgery (SSRF) — относится ко второй группе. Ее эксплуатация позволяет отправлять произвольные HTTP-запросы к внешним или внутренним ресурсам от имени уязвимого веб-приложения. В 2021 году SSRF попала в топ-10 наиболее опасных угроз для веб-приложений по версии Open Web Application Security Project (OWASP).

Зачем злоумышленники ищут SSRF

Представьте, что у вас есть внутренний сервис (для простоты буду называть его «админкой»), веб-сервис, к которому можно обращаться, и киберпреступник. В идеале последний хочет сразу получить доступ в «админку», чтобы узнать, какие в ней хранятся данные. Однако сервисы, как правило, защищены, доступ к ним предупредительно ограничивают, поэтому так называемая «админка» может находиться, например, за межсетевым экраном (из-за чего доступ к ней напрямую невозможен) либо в локальной сети, в которую злоумышленник попасть не может.

Но что, если веб-сервис имеет функционал, позволяющий выполнять запросы по URL-адресу, и мы подменим адрес для запроса данных на внутренний? По сути, таким образом мы заставим сервер отправить запрос на ресурс, куда доступа извне нет, и получим возможность взаимодействовать с ним, что позволит в дальнейшем начать поиск способов раскрытия информации, работы с данными в критичном сервисе. Существует множество сценариев, когда можно осуществлять подделку запросов на стороне сервера, к примеру, это может быть простейший генератор картинок по URL-адресу контента. Разработчики сервиса, в свою очередь, могут не предусмотреть, что таким способом киберпреступники могут передавать веб-серверу адрес внутреннего сервиса и похищать данные. Главная задача SSRF-атаки — масштабировать последующие кибератаки на внутреннюю инфраструктуру компании.

SSRF-уязвимость бывает трех видов: неслепой, полуслепой и слепой. Особенности каждой представлены ниже.

Отмечу, что контроль данных является важным элементом любого SSRF-бага. Этот параметр позволяет ответить на вопросы:

• Есть ли у хакера возможность контролировать путь, по которому будет выполнен запрос сервером?

• Есть ли возможность передать в запрос параметры?

• Можно ли изменить метод, с помощью которого выполняется запрос?

Где искать SSRF

Самые очевидные SSRF следует искать в функциональности сервиса и его фичах. Среди них могут быть генераторы (файлов PDF или изображений) и парсеры данных, например вектором атаки может быть приложение онлайн-магазина, в котором при редактировании карточек товара можно передавать URL-адрес изображения товаров. Так, при отправке сервер сделает запрос, чтобы получить информацию о картинке, а затем добавит ее в базу данных. В этом случае, подменив адрес, можно попытаться прочитать данные из внутренних сервисов и таким образом исследовать инфраструктуру. Вспомните, что большинство сайтов имеет favicon — иконку страницы, которую также видно на вкладке в браузере, она может стать средством обнаружения доступности внутренних сервисов вроде GitLab.

Кроме того, при багхантинге стоит обращать внимание на используемые технологии и сервисы (Next.js, Sentry, Skype for Business): часто в них уже встроены фичи, которые разработчики могут забыть отключить либо настроить некорректно, что также позволит исследовать и атаковать инфраструктуру.

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

Вдобавок, если удалось найти отравление кэша, простейшую HTML-инъекцию или любую другую уязвимость, можно попытаться повысить их импакт до SSRF.

Например, если на сайте присутствует генератор изображений по HTML-разметке, то инъекция тега изображения может позволить стриггерить SSRF.

 <img src=”http://10.0.0.5"/>

Или, например, содержимое сервера кэшируется в сети доставки контента, тогда внедрение тега для кэширования динамического контента может также позволить выполнить подделку запроса:

<esi:include src="http://10.0.0.5"/>

А что, если сервер ограничивает адреса, к которым можно выполнять запрос?

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

1. Если знаете, что используется библиотека для обработки URL, — смотрите ее версию и проверяйте на наличие известных CVE.

2. Если неизвестно, что используется на бэкенде, анализируйте поведение парсера: вдруг там startswith? Один из простейших примеров байпаса — применение базовой аутентификации.

   Базовая аутентификация — один из простейших и первых способов аутентификации в системе при помощи простой ссылки. Она имеет следующий синтаксис: https://login:pass@attacker.com. Если разработчик использует небезопасный парсер, можно его обмануть, указав, что домен — это логин, затем указать пароль и через знак @ добавить произвольный домен. Таким образом, запрос отправится на attacker.com. Соответственно, если сервер настроен на проверку начального фрагмента URL, то парсер можно обойти, указав вместо логина разрешенный домен.

3. На всякий случай всегда записывайте все обнаруженные уязвимости открытого перенаправления (Open Redirect). У многих фреймворков, отправляющих запрос стороннему ресурсу, может быть включено следование переадресации (follows redirect), а значит, можно обмануть парсер, передав ему разрешенный адрес с полезной нагрузкой, которая выполнит переадресацию запроса на произвольный узел.

Механизм работы уязвимости SSRF через открытое перенаправление в общих чертах выглядит так:

• парсер выполняет проверку домена, к которому выполняется запрос, проверка проходит успешно, поскольку домен входит в список разрешенных для выполнения запроса;

  в ходе выполнения запроса сервис получит ответ с переадресацией и перейдет по ней на указанный ресурс, при этом проверка осуществляться уже не будет;

  Так как проверки не происходит и запрос выполняется, атакующий получает возможность обойти защиту от SSRF.

Что почитать, прежде чем ломать делать сервисы безопаснее

Теория на PortSwigger, где изложена основная информация.

Памятки, которыми я пользуюсь:

Памятка из репозитория Payloads All The Thing, где перечислены самые распространенные байпасы (мне кажется, они здесь на все случаи жизни есть ?).

Памятка от HackTricks для обхода формата URL-адреса — там также собраны полезные нагрузки, которые включают различные представления локального адреса, в том числе с вектором его нормализации.

Порешать задачки

Тем, кто только начинает багхантить, я очень советую применять плагин Collaborator Everywhere, который для идентификации узла в автоматическом режиме может отправлять каждый ваш запрос вместе с дополнительными заголовками (прокси-заголовками, заголовками-реферами и пр.). Плагин сообщит, когда сервер сделает запрос к узлу, указанному в каком-либо из заголовков запроса, чтобы вы могли перейти к дальнейшему анализу и тестированию.

Еще один плагин — Wappalyzer — позволяет определять технологии, на которых базируется веб-сервис. Имейте в виду, что даже статическая страница, не имеющая ничего, кроме текста и фотографий, может быть уязвимой.

Это базовые инструменты, которые позволят уже сейчас начать поиск уязвимостей к SSRF. Со временем вы сами расширите перечень инструментов до тех, которые будут удобны лично вам!

Время размять мозги и порешать задачки

Базовый SSRF против другой внутренней системы

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

Слепая SSRF с обнаружением через запрос к контролируемому узлу

В этой задаче разберем, как анализировать HTTP-заголовки, которые могут применяться для отслеживания действий пользователей и проксирования трафика. Кроме того, я покажу, как правильно пользоваться плагином Collaborator. Один из нюансов состоит в том, что сервер может обрабатывать определенный заголовок только в конкретных случаях, например не на главной странице сайта, а при просмотре карточек товаров (для отслеживания того, откуда пользователи смотрят товары, а также для оценки эффективности различных сервисов, например рекламных). Соответственно, следует проверять заголовки с помощью множества запросов. Для этого можно обратиться к Burp Suite, вручную добавляя заголовки с требуемым доменом, либо к Collaborator, если в сети не установлен межсетевой экран.

SSRF с обходом фильтра через уязвимость открытого перенаправления

Обнаруживаем SSRF через Open Redirect.

Вишенка на торте: мой сайт, который «не взломать»

Я написал небольшой простой статический сайт на Next.js и продемонстрирую, как его можно взломать.

Кейс с баг-трекером

Sentry — сервис мониторинга производительности и ошибок на фронтенде, который позволяет разработчикам быстро отслеживать и исправлять ошибки на веб-сайтах. Он используется либо как self-hosted-решение, либо как SaaS. Его работу легко определяет Wappalyzer.

Одна из фичей Sentry, если он развернут в корпоративной инфраструктуре, позволяет выполнять запрос к файлу и непосредственно увидеть код, в котором произошла ошибка. Другими словами, сервис разрешает просматривать трассировку стека при возникновении ошибок в бразуерах пользователей. Адреса, к которым может обращаться Sentry, никак не ограничиваются сервисом, а разработчики забывают внедрить проксирование запросов. При багхантинге можно обнаружить использование Sentry в прокси всего лишь путем просмотра запросов.

Либо выяснить параметры ключ-проекта Sentry в коде страниц ресурса.

Таким образом, появляется возможность подмены имени файла с ошибкой, и баг-трекер, если в нем включена фича с запросом исходного кода, в котором возникло исключение, выполнит его к необходимому ресурсу. При этом мы не сможем получить ответ, но сможем поймать HTTP interaction, который и подтвердит, что фича отправки запросов на произвольные веб-адреса в Sentry не ограничена, а значит, наличие проксирования запросов не подтверждается.

Эпилог

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

Напоследок поделюсь коротким планом действий, следуя которому вы легко сможете начать поиск SSRF-уязвимостей:

1. Выявить функционал и технологии, которые могут применяться для работы с запросами на стороне сервера.

2. Внимательно проанализировать их работу и при необходимости попытаться обмануть парсер.

3. Обязательно подтверждать наличие уязвимости ссылками на авторитетные исследования, репорты, упоминания ошибок конфигурации либо запросами к внутренним сервисам, если есть такая возможность.

4. Излагать свои мысли в отчете последовательно и подробно, так как часто за качественно составленный репорт вендор дополнительно может дать небольшой бонус (ну и чтобы вам самим за собственный отчет не было стыдно). Вот пример хорошего репорта на Standoff Bug Bounty.

Кроме того, хочу сделать акцент на том, что каждое действие, которое вы выполняете при поиске бага, должно быть осознанным и логичным, ведь все ошибки — результат несовершенства процессов разработки и тестирования (увы, этого не избежать), а не случайность. Немаловажным фактором является и время, которое затрачивается на поиск уязвимостей: чем больше времени вы уделяете исследованию сервиса, тем выше вероятность того, что вам удастся найти что-нибудь интересное и зарепортить свой первый баг!

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

Что еще интересного о багхантинге можно почитать

• Как начать заниматься багхантингом веб-приложений (Часть 1, Часть 2, Часть 3)

• Как багхантеру искать XSS-уязвимости через наложение парсеров: исследование Positive Technologies

• Как багхантеры ищут уязвимости: лайфхаки и неочевидные нюансы

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

Полезное, которое живет не на Хабре: 15 навыков, чтобы начать свой путь в багхантинге, а также карта знаний и советы топовых багхантеров.