icon

UA

icon

UA

Практическая защита от SSRF: показываем атаку и защиту на примерах 

Согласно последнему отчету OWASP Web Application Top 10, SSRF является одной из наиболее распространенных атак на веб-приложения. Понимание того, как именно устроена угроза, является ключом к эффективному противодействию. В статье мы моделируем атаку SSRF и рассматриваем технику ее смягчения с помощью платформы F5 Distributed Cloud.

Об атаке SSRF

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

Демонстрация

В ходе демонстрации создадим SSRF-атаку и нейтрализуем ее с помощью платформы F5 Distributed Cloud. 

Мы используем:

    Инстанс AWS с Docker

    DVWA (Vulnerable Web Application), установленную как контейнер, чтобы действовать как цель для атаки SSRF

    Платформу F5 Distributed Cloud для смягчения атаки

Кратко о сценарии атаки SSRF в AWS:


Инстанс AWS использует внутреннюю веб-службу для сбора собственных метаданных о себе, и получить их можно только с инстанса. Когда экземпляру EC2 нужны любые метаданные, он инициирует запрос к этой службе, и информация предоставляется в соответствии со сделанным запросом. AWS использует адрес 169.254.169.254 для получения метаданных инстанса.

Illustration

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

Пошаговый процесс:

    Запускаем экземпляр EC2

    Разворачиваем Vulnerable Web Application в инстансе и убеждаемся, что он работает

    Настраиваем балансировщик нагрузки HTTP в F5 Distributed Cloud без включения политики WAF

    Получаем доступ к серверной Vulnerable Web Application с помощью настроенного домена балансировщика нагрузки

    Ждем, пока программа загрузится, и заходим в нее

    Переходим на страницу "File Inclusion" в программе

    В URL-адресе меняем значение параметра запроса "страница" на http://169.254.169.254/latest/meta-data/ 

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

Полученные метаданные отображаются в уязвимом приложении:

Illustration
Illustration

Конфигурация HTTP Load Balancer для смягчения атаки

Heading photo

Шаг 1: Создание исходного пула

● Из нужного пространства имен переходим к пункту Manage > Load Balancers > Origin pools ● Нажимаем "Add Origin Pool" и вводим название для исходного пула ● Настраиваем детали исходного сервера с реальными деталями порта

Heading photo

Шаг 2: Конфигурация балансировщика нагрузки с включенным WAF

● Переходим к пункту Manage -> Load Balancers -> HTTP Load Balancers ● Нажимаем "Add HTTP load balancer" и вводим имя для балансировщика нагрузки. ● Указываем реальное доменное имя и выбираем соответствующий тип балансировщика нагрузки в базовой конфигурации. ● Связываем созданный выше исходный пул с балансировщиком нагрузки. ● Включаем "Web Application Firewall" и создаем конфигурацию WAF с режимом блокировки. ● Нажимаем «Продолжить» и наблюдаем, что используется созданная выше конфигурация WAF. ● Нажимаем «Сохранить и выйти».

Heading photo

Шаг 3. Получаем доступ к уязвимой программе и повторяем сценарий атаки.

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

Heading photo


● В URL-адресе изменяем значение параметра запроса «page» на http://169.254.169.254/latest/meta-data/ ● Обратите внимание, что страница не может прочитать метаданные сервера, и запрос блокируется через политику WAF.

Heading photo

Шаг 4. Проверяем журналы и детали заблокированного запроса.


● Переходим в Virtual Hosts -> HTTP Load Balancers -> выбираем соответствующий балансировщик нагрузки -> Security Monitoring -> Security events ● Обратите внимание, что вредоносный запрос блокируется через примененную политику WAF. ● Разворачиваем запрос и просматриваем детали о нем.

Вывод

Как видим из приведенной выше демонстрации, атаки SSRF можно избежать, настроив политику WAF в F5 Load Balancer, которая автоматически обнаруживает сигнатуры атак и блокирует их. 

SSRF — только одна угроза из множества возможных, но с помощью инструментов F5 вы сможете активно противодействовать им всем. Заполните форму и получите детальную консультацию с экспертом относительно продуктов F5.

ЗАПРОС НА КОНСУЛЬТАЦИЮ

Спасибо!

Мы свяжемся с вами в ближайшее время

Can't send form.

Please try again later.