День 32 - SSRF

Узнайте, как использовать уязвимости типа Server-Side Request Forgery (SSRF), позволяющие получить доступ к внутренним ресурсам сервера.

1. Что такое SSRF?

Краткое описание номера

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

Что такое SSRF ?

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

Типы SSRF

Существует два типа уязвимостей SSRF : первый — это обычная SSRF-атака , при которой данные возвращаются на экран злоумышленника; второй — это «слепая» SSRF- атака, при которой происходит SSRF-атака , но никакая информация не возвращается на экран злоумышленника.

Каковы последствия?

Успешная SSRF- атака может привести к любому из следующих последствий:

• Доступ в несанкционированные зоны.
• Доступ к данным клиентов/организации.
• Возможность масштабирования до уровня внутренних сетей.
• Показать токены/учетные данные аутентификации.

2. Примеры SSRF

Нажмите кнопку « Просмотреть сайт» , которая познакомит вас с некоторыми распространенными примерами SSRF-атак , способами их эксплуатации и даже симуляцией, чтобы проверить, сможете ли вы воспользоваться уязвимостью SSRF, используя полученные знания.

3. Обнаружение SSRF-атаки

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

Когда в адресной строке в качестве параметра используется полный URL-адрес:

Скрытое поле в форме:

Частичный URL-адрес, например, только имя хоста:

Или, возможно, только путь к URL-адресу:

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

При работе со скрытой SSRF- атакой , когда на вас не поступает никакой обратной связи, вам потребуется использовать внешний инструмент для логирования HTTP- запросов, например, requestbin.com, ваш собственный HTTP- сервер или клиент Collaborator в Burp Suite .

4. Как обойти распространенные средства защиты от SSRF-атак

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

Список запрещенных

Запрещенный список — это список, в котором принимаются все запросы, кроме запросов к ресурсам, указанным в списке или соответствующим определенному шаблону. Веб-приложение может использовать запрещенный список для защиты конфиденциальных конечных точек, IP-адресов или доменов от доступа извне, одновременно разрешая доступ к другим ресурсам. Конкретной конечной точкой для ограничения доступа является localhost, который может содержать данные о производительности сервера или другую конфиденциальную информацию, поэтому доменные имена, такие как localhost и 127.0.0.1, будут отображаться в запрещенном списке. Злоумышленники могут обойти запрещенный список, используя альтернативные ссылки на localhost, такие как 0, 0.0.0.0, 0000, 127.1, 127.*.*.*, 2130706433, 017700000001, или поддомены, имеющие DNS- запись, которая разрешается в IP-адрес 127.0.0.1, например, 127.0.0.1.nip.io.

Кроме того, в облачной среде было бы полезно заблокировать доступ к IP-адресу 169.254.169.254, который содержит метаданные развернутого облачного сервера, включая, возможно, конфиденциальную информацию. Злоумышленник может обойти это, зарегистрировав поддомен в своем собственном домене с DNS- записью, указывающей на IP-адрес 169.254.169.254.

Список разрешенных

Список разрешенных запросов — это список, в который отклоняются все запросы, если они не включены в него или не соответствуют определенному шаблону, например, правилу, согласно которому URL-адрес, используемый в параметре, должен начинаться с https ://website.thm . Злоумышленник может быстро обойти это правило, создав поддомен на доменном имени злоумышленника, например, https://website.thm.attackers-domain.thm . Логика приложения теперь разрешит этот ввод и позволит злоумышленнику контролировать внутренний HTTP- запрос.

Открыть перенаправление

Если описанные выше способы обхода защиты не сработают, у злоумышленника есть ещё один козырь в рукаве — открытое перенаправление. Открытое перенаправление — это конечная точка на сервере, через которую посетитель сайта автоматически перенаправляется на другой адрес сайта. Возьмем, например, ссылку https://website.thm/link? url =https://tryhackme.com. Эта конечная точка была создана для записи количества переходов по этой ссылке в рекламных/маркетинговых целях. Но представьте, что существует потенциальная уязвимость SSRF со строгими правилами, разрешающими только URL-адреса, начинающиеся с https://website.thm/ . Злоумышленник мог бы использовать эту функцию для перенаправления внутреннего HTTP- запроса на домен по своему выбору.

5. Практическое применение SSRF

Давайте проверим полученные нами знания о SSRF на практике в вымышленном сценарии.

В ходе проверки содержимого веб-сайта ИТ-поддержки компании Acme мы обнаружили две новые конечные точки . Первая — это /private , которая выдает сообщение об ошибке, объясняющее, что содержимое недоступно для просмотра с нашего IP-адреса. Вторая — это новая версия страницы учетной записи клиента по адресу /customers/new-account-page с новой функцией, позволяющей клиентам выбирать аватар для своей учетной записи.

Для начала нажмите кнопку «Запустить компьютер» , чтобы открыть веб-сайт ИТ-поддержки Acme . После запуска перейдите по адресу https://LAB_WEB_URL.p.thmlabs.com и следуйте приведенным ниже инструкциям, чтобы получить флаг.

Сначала создайте учетную запись клиента и войдите в систему. После входа в систему перейдите по ссылке https://LAB_WEB_URL.p.thmlabs.com/customers/new-account-page, чтобы увидеть новую функцию выбора аватара. Просмотрев исходный код формы выбора аватара, вы увидите, что значение поля формы содержит путь к изображению. Это можно подтвердить стилем background-image в элементе DIV, как показано на скриншоте ниже:

Если вы выберете один из аватаров, а затем нажмете кнопку «Обновить аватар» , вы увидите, как форма изменится, и над ней отобразится ваш текущий выбранный аватар.

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

Теперь давайте попробуем отправить запрос еще раз, но изменим значение параметра avatar на private в надежде, что сервер получит доступ к ресурсу и обойдет блокировку по IP-адресу. Для этого сначала щелкните правой кнопкой мыши по одному из переключателей в форме avatar и выберите «Просмотреть код элемента» :

Затем измените значение переключателя на "приватное":

Обязательно выберите отредактированный аватар, а затем нажмите кнопку «Обновить аватар» . К сожалению, похоже, что веб-приложение использует список запрещенных сайтов и заблокировало доступ к конечной точке /private.

Как видно из сообщения об ошибке, путь не может начинаться с /private, но не волнуйтесь, у нас есть способ обойти это правило. Мы можем использовать обход каталогов, чтобы добраться до нужной конечной точки. Попробуйте установить значение аватара на x/../private.

Вы увидите, что мы обошли это правило, и пользователь обновил аватар. Этот трюк работает, потому что, когда веб-сервер получает запрос на x/../private , он знает, что строка ../ означает перемещение на один каталог выше, что теперь преобразует запрос просто в /private .

Просматривая исходный код страницы формы аватара, вы увидите, что текущий установленный аватар содержит содержимое каталога /private в кодировке base64. Расшифруйте это содержимое, и вы увидите флаг, который можно ввести ниже.

Регаем аккаунт

Смотрим новую страницу

выбираем новый аватар

Смотрим что что то закодировано base64

находим наш аватар и меняем значение на private

Выбираем этот аватар и обновляем аватар
Как видно из сообщения об ошибке, путь не может начинаться с /private, но не волнуйтесь, у нас есть способ обойти это правило. Мы можем использовать обход каталогов, чтобы добраться до нужной конечной точки. Попробуйте установить значение аватара на x/../private.

Вы увидите, что мы обошли это правило, и пользователь обновил аватар. Этот трюк работает, потому что, когда веб-сервер получает запрос на x/../private , он знает, что строка ../ означает перемещение на один каталог выше, что теперь преобразует запрос просто в /private .

Попробуем дипсику дать эту задачу на раскодирование

Основная группа обучения ИБ
Lab-группу с полезным софтом / книгами / аудио.
Чат для обсуждений, задавай свои вопросы.
P.S. С вами был @Fnay_Offensive
До новой встречи, user_name!