В конце сентября сообщество OWASP (Open Web Application Security Project) выпустило обновленную версию списка наиболее опасных угроз для веб-приложений OWASP Top-10. Примечательным стало появление в нем A10:2021 – Server-Side Request Forgery (SSRF) или подделка запроса на стороне сервера. При этом 2 из 10 категорий угроз, включая SSRF, были отобраны по результатам опросов профессионального сообщества. Пока, по оценке экспертов OWASP, позволяющие проводить атаки SSRF уязвимости с высоким уровнем критичности встречаются нечасто. Но потенциал эксплуатабельности у них высокий, и скоро SSRF может стать серьезной киберугрозой. Мы тоже встречаем SSRF при проведении работ по анализу защищенности веб-приложений, и иногда эта атака открывает пентестерам (а, значит, и реальным хакерам) массу возможностей. А каких именно – расскажем в этом посте.

SSRF – что это такое?

Подделка запроса на стороне сервера – это атака, которая позволяет отправлять запросы от имени сервера к внешним или внутренним ресурсам. При этом злоумышленник может контролировать либо весь запрос целиком, либо его отдельные части (например, домен).

На схеме ниже показан простой пример такой атаки:

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

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

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

Как часто мы встречаем SSRF?

Атака SSRF направлена прежде всего на веб-приложения. Причем результаты работ по анализу защищенности веб-приложений, которые эксперты "Ростелеком-Солар" проводили с начала 2021 года, показывают, насколько угроза опасна.  Так, уязвимости, позволяющие проводить атаки SSRF, были обнаружены в 41% исследуемых приложений. А ведь еще два года назад – в 2019-м – таких приложений было только 23%. Возможно, именно эта тревожная динамика и привлекла внимание экспертного сообщества.

А что с критичностью данной атаки? Тут мы полностью разделяем позицию OWASP. Большая часть уязвимостей, позволяющих проводить SSRF, имеет низкий и средний уровень критичности. Хотя были на нашей практике и проекты, где мы смогли добиться полной компрометации систем. Так что угрозу точно не стоит недооценивать.

Но хватит теории. Рассмотрим SSRF-атаки, их причины и последствия на практике.

Уязвимыми бывают не только параметры

Известный факт: заголовок Host является обязательным в HTTP-запросе, начиная с версии протокола 1.1. Он предназначен для определения внутреннего ресурса, с которым взаимодействует клиент. Уязвимости в заголовке Host обычно появляются из-за ошибочного предположения, что он не контролируется пользователем. В результате разработчики доверяют значению заголовка и используют его без дополнительных проверок. Но на самом деле злоумышленник может легко поменять заголовок с помощью локального прокси или других утилит.

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

Как видно, в заголовке не проверяется домен. А это значит, что при обработке следующего запроса сервер обратится уже к стороннему ресурсу:

От сервера не возвращался ответ на отправленный запрос, поэтому обнаруженная уязвимость позволяет проводить только Blind SSRF-атаку. При ней извлечение информации происходит не напрямую, а через сторонние параметры, например, код и время ответа сервера. Как уже говорилось выше, результат проведения атаки зависит от многих факторов. Кроме отсутствия ответа затрудняла атаку также невозможность отправки произвольного запроса через заголовок Host. Однако сервер уязвимого веб-приложения имел доступ к ресурсам внутренней сети, которые можно было идентифицировать на основе кода ответа сервера. В результате нам удалось просканировать внутренние серверы и идентифицировать внутренний домен.

Ниже представлен фрагмент сканирования веб-сервером самого себя (localhost). Как можно заметить, при обращении к различным портам возвращался ответ с различными кодами состояния: 200 или 500. Именно такое поведение приложения позволяет сказать, что на сервере открыты порты 80, 3306, 8080. А дальше можно воспользоваться списком известных портов и предположить, какие сервисы запущены. К примеру, открытый порт 3306 говорит о том, что на сервере используется база данных MySQL. Аналогичным образом происходило сканирование и других ресурсов.

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

Через SSRF – к компрометации сервера

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

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

Вроде бы все правильно: панель защищена. Но мы все-таки нашли в приложении возможность проведения SSRF-атаки, и административная панель оказалась доступна любому пользователю. Уязвимой была функциональность загрузки файлов по ссылке: при передаче адреса localhost/admin в ответе возвращалась интересующая нас страница.

В отличие от предыдущего примера обнаруженная уязвимость позволяла проводить Full SSRF-атаку, то есть от сервера возвращался полный ответ на отправленный запрос. Анализ ответов показал, что это действительно административная панель с функциональностью управления приложением и пользователями. И она была доступна без аутентификации с локального адреса!

Почему же так случилось? Очень часто ограничение доступа к административным страницам происходит на основе IP-адреса, с которого пришел запрос. В данном примере, разрешенным адресом оказался localhost. Плюс к этому в административном интерфейсе отсутствовала аутентификация. Так бывает, когда компании усиленно защищают внешний периметр, забывая при этом про внутренний. В итоге в корпоративной сети встречаются учетные данные по умолчанию или даже полное отсутствие паролей для доступа.

Словом, эти недочеты и привели нас в административную панель. В результате получился вполне ожидаемый сценарий атаки:

Еще один пример SSRF-атаки, приводящей к чтению локальных файлов, можно найти в нашем недавнем исследовании.

Рассмотренные примеры демонстрируют, что эксплуатация SSRF зависит еще и от общей конфигурации приложения. Blind SSRF-атака также могла использоваться для прямого обращения к конкретной функциональности, просто исследование внутреннего приложения было бы усложнено. Распространенной особенностью является и то, что тело POST-запросов можно отправлять также и в GET-параметрах. При этом оба запроса: POST и GET – будут одинаково обработаны сервером, что упрощает проведение ряда SSRF-атак. Поэтому некритичная для одного приложения уязвимость, в другом – уже может стать серьезной проблемой.

Что же делать?

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

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

Автор: Ольга Рыбакова, аналитик отдела анализа защищенности Solar JSOC компании "Ростелеком-Солар"