Спасибо!
Мы свяжемся с вами в ближайшее время
Практическая защита от SSRF: показываем атаку и защиту на примерах
Об атаке SSRF
Атака подделки запросов на стороне сервера (SSRF) — это техника, которая позволяет злоумышленнику манипулировать уязвимостью программы на стороне сервера и делать злонамеренный запрос к внутренним ресурсам. Речь идет о тех компонентах приложения, которые отвечают за получение правильных конфигураций, метаданных информации о подключении к базам данных и т. д. В нормальном состоянии эти ресурсы не взаимодействуют с внешним миром, находясь «под капотом» приложения и обеспечивая его функционирование. Суть SSRF заключается в создании или изменении URL-адресов, с которыми взаимодействуют внутренние ресурсы, таким образом, чтобы сервер получал и раскрывал конфиденциальные данные с внутренних серверов.
Демонстрация
В ходе демонстрации создадим SSRF-атаку и нейтрализуем ее с помощью платформы F5 Distributed Cloud.
Мы используем:
Инстанс AWS использует внутреннюю веб-службу для сбора собственных метаданных о себе, и получить их можно только с инстанса. Когда экземпляру EC2 нужны любые метаданные, он инициирует запрос к этой службе, и информация предоставляется в соответствии со сделанным запросом. AWS использует адрес 169.254.169.254 для получения метаданных инстанса.
Как показано в приведенной выше архитектуре, уязвимое приложение развертывается в экземпляре AWS. Злоумышленники могут получить доступ к программе и попытаться использовать эту уязвимую программу. Это можно сделать, изменив или предоставив URL-адрес, который будет инициировать запрос от экземпляра AWS к внутренней веб-службе и получать конфиденциальные метаданные.
Пошаговый процесс:
Обратите внимание, что страница программы отображает конфиденциальные метаданные экземпляра EC2.
Полученные метаданные отображаются в уязвимом приложении:
Шаг 1: Создание исходного пула
● Из нужного пространства имен переходим к пункту Manage > Load Balancers > Origin pools ● Нажимаем "Add Origin Pool" и вводим название для исходного пула ● Настраиваем детали исходного сервера с реальными деталями порта
Шаг 2: Конфигурация балансировщика нагрузки с включенным WAF
● Переходим к пункту Manage -> Load Balancers -> HTTP Load Balancers ● Нажимаем "Add HTTP load balancer" и вводим имя для балансировщика нагрузки. ● Указываем реальное доменное имя и выбираем соответствующий тип балансировщика нагрузки в базовой конфигурации. ● Связываем созданный выше исходный пул с балансировщиком нагрузки. ● Включаем "Web Application Firewall" и создаем конфигурацию WAF с режимом блокировки. ● Нажимаем «Продолжить» и наблюдаем, что используется созданная выше конфигурация WAF. ● Нажимаем «Сохранить и выйти».
Шаг 3. Получаем доступ к уязвимой программе и повторяем сценарий атаки.
● В браузере открываем серверную программу с помощью настроенного домена балансировщика нагрузки. ● Ждем, пока программа загрузится, и входим в нее. ● Переходим на страницу "Включение файла" в программе.
● В URL-адресе изменяем значение параметра запроса «page» на http://169.254.169.254/latest/meta-data/ ● Обратите внимание, что страница не может прочитать метаданные сервера, и запрос блокируется через политику WAF.
Шаг 4. Проверяем журналы и детали заблокированного запроса.
● Переходим в Virtual Hosts -> HTTP Load Balancers -> выбираем соответствующий балансировщик нагрузки -> Security Monitoring -> Security events ● Обратите внимание, что вредоносный запрос блокируется через примененную политику WAF. ● Разворачиваем запрос и просматриваем детали о нем.
Вывод
Как видим из приведенной выше демонстрации, атаки SSRF можно избежать, настроив политику WAF в F5 Load Balancer, которая автоматически обнаруживает сигнатуры атак и блокирует их.