Введение
Подделка запроса на стороне сервера (Server-Side Request Forgery, SSRF) — это уязвимость веб-безопасности, которая позволяет злоумышленнику заставить серверное приложение выполнять HTTP-запросы к произвольному домену по выбору злоумышленника.
Ключевой момент заключается в том, что запрос выполняет сервер, а не сам злоумышленник напрямую. Это означает, что запрос наследует сетевое положение сервера, его доверительные отношения и доступ к ресурсам, предназначенным только для внутреннего использования.
В типичной атаке SSRF злоумышленник может заставить сервер установить соединение с внутренними службами в инфраструктуре организации. В других случаях он может принудить сервер подключиться к произвольным внешним системам, что потенциально приведет к утечке конфиденциальных данных, таких как учетные данные для авторизации.
В этой лабораторной работе вы будете взаимодействовать с симулированным уязвимым веб-приложением. Вы научитесь выявлять уязвимость SSRF, наблюдать за тем, как базовые фильтры безопасности пытаются блокировать вредоносные запросы, обходить эти фильтры и, в конечном итоге, извлекать конфиденциальные внутренние данные и симулированные облачные метаданные. Чтобы упражнение было совместимо с общими лабораторными средами, служба метаданных использует непривилегированный высокий порт вместо порта 80.
Определение параметров URL
На этом этапе вы научитесь выявлять потенциальные уязвимости SSRF, ища функции приложения, которые получают данные с внешних URL-адресов.
Многим веб-приложениям необходимо получать ресурсы с других серверов. Например, приложение может загружать фотографию профиля с сайта социальной сети или получать данные из стороннего API. Если приложение принимает URL-адрес в качестве пользовательского ввода и выполняет запрос без надлежащей проверки, оно может быть уязвимо для SSRF.
Именно поэтому SSRF часто встречается в, казалось бы, легитимных функциях «получения URL». Опасное поведение скрыто внутри рабочего процесса, который с точки зрения продукта выглядит вполне нормально.
Для вас запущено уязвимое веб-приложение на порту 8080. Это приложение имеет конечную точку /check, которая принимает параметр url. Оно предназначено для проверки статуса внешних веб-сайтов.
Вы можете протестировать эту функциональность, попросив приложение получить данные с безобидного внешнего веб-сайта, например http://example.com. Используйте команду curl в своем терминале, чтобы отправить HTTP GET-запрос к уязвимому приложению. Если вы не знакомы с curl, представьте его как простой веб-браузер командной строки, который отправляет запросы и выводит ответ сервера в терминал.
curl "http://localhost:8080/check?url=http://example.com"
Когда вы выполняете эту команду, уязвимое приложение, работающее на порту 8080, получает ваш запрос, извлекает параметр url и выполняет собственный HTTP-запрос к http://example.com. Затем оно возвращает вам HTML-ответ.
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
Наблюдая за тем, как сервер успешно получил и вернул содержимое запрошенного URL, вы подтвердили, что параметр url активно обрабатывается и используется для выполнения запросов на стороне сервера. Это первый признак уязвимости SSRF.
Тестирование SSRF против Localhost (127.0.0.1)
На этом этапе вы попытаетесь использовать уязвимость SSRF для доступа к внутренней службе, работающей на сервере.
Основная опасность SSRF заключается в том, что сервер, выполняющий запрос, часто занимает привилегированное положение в сети. Он может получить доступ к внутренним службам, которые не выставлены в общедоступный интернет. В нашем сценарии на порту 5000 работает внутренняя панель администратора. Эта панель привязана к 127.0.0.1 (localhost), что означает, что доступ к ней возможен только с самого сервера, а не с другой машины. Вы можете представить 127.0.0.1 как компьютер, «разговаривающий сам с собой».
Как злоумышленник, вы можете использовать уязвимость SSRF на порту 8080, чтобы обманом заставить сервер получить доступ к панели администратора на порту 5000 от вашего имени.
Попробуйте получить доступ к внутренней панели администратора, передав её локальный URL в уязвимую конечную точку /check.
curl "http://localhost:8080/check?url=http://127.0.0.1:5000/admin"
При выполнении этой команды вы заметите, что запрос не увенчался успехом. Вместо этого вы получите сообщение об ошибке.
Error: Localhost access is blocked by WAF!
Разработчики часто внедряют межсетевые экраны веб-приложений (WAF) или фильтры ввода для предотвращения атак SSRF. В данном случае приложение проверяет, содержит ли предоставленный URL строку 127.0.0.1 или localhost. Поскольку ваш ввод совпал с этим фильтром, приложение заблокировало запрос.
Простые строковые фильтры ненадежны, поскольку сетевые адреса назначения могут иметь несколько эквивалентных представлений. Защитникам необходима проверка, которая понимает каноническое сетевое значение, а не просто буквальный текст.
Понимание того, как приложение фильтрует ввод, является важным шагом в эксплуатации SSRF, так как это указывает на то, какие ограничения вам нужно обойти.
Обход фильтров ввода
На этом этапе вы узнаете, как обойти базовый фильтр ввода, с которым столкнулись на предыдущем шаге.
Методы обхода работают здесь потому, что синтаксический анализ URL, разрешение имен хостов и фильтрация ввода не всегда используют одни и те же правила интерпретации.
Фильтры ввода, основанные на простом сопоставлении строк (например, блокировка 127.0.0.1), часто ошибочны, поскольку IP-адреса могут быть представлены несколькими способами. Сетевой стек операционной системы все равно разрешит эти альтернативные представления в один и тот же пункт назначения, но текстовый фильтр приложения может их не распознать.
Вот несколько распространенных способов представления IP-адреса localhost (127.0.0.1), которые могут обойти плохо реализованный фильтр. Вы можете использовать сокращенный IP, например 127.1, десятичный IP, такой как 2130706433, восьмеричный IP, например 0177.000.000.001, или шестнадцатеричный IP, такой как 0x7f000001.
Поскольку приложение блокирует только точные строки 127.0.0.1 и localhost, вы можете использовать сокращенное представление IP 127.1, чтобы обойти фильтр и получить доступ к внутренней панели администратора.
Выполните следующую команду, чтобы протестировать метод обхода:
curl "http://localhost:8080/check?url=http://127.1:5000/admin"
Поскольку 127.1 не совпадает с заблокированными строками, приложение разрешает выполнение запроса. Сетевой стек сервера разрешает 127.1 в 127.0.0.1 и успешно получает страницу внутреннего администратора.
Welcome to the Internal Admin Panel. Secret Key: SSRF_ADMIN_SUCCESS
Вы успешно обошли фильтр ввода и использовали уязвимость SSRF для доступа к ограниченной внутренней службе.
Доступ к внутренним метаданным
На этом этапе вы используете уязвимость SSRF для доступа к конфиденциальным облачным метаданным.
Когда приложения размещаются в облачных средах (например, AWS, Google Cloud или Azure), они часто имеют доступ к специальному немаршрутизируемому IP-адресу: 169.254.169.254. По этому адресу находится служба метаданных экземпляра (Instance Metadata Service, IMDS), которая предоставляет информацию о запущенном облачном экземпляре, включая высокочувствительные временные учетные данные IAM (Identity and Access Management). «Немаршрутизируемый» означает, что адрес предназначен для локальной облачной инфраструктуры, а не для общего доступа через публичный интернет.
Если злоумышленник обнаруживает уязвимость SSRF в облачном приложении, запрос к этой конечной точке метаданных часто является его главной целью, так как это может привести к полному компрометированию облачной среды.
В этой лабораторной среде симулированная служба облачных метаданных работает на 169.254.169.254:8000. Реальная служба облачных метаданных обычно использует порт 80, но в этой лабораторной работе намеренно используется порт 8000, чтобы служба могла запуститься без специальных привилегий и не конфликтовать с другим программным обеспечением. Сначала используйте уязвимость SSRF, чтобы перечислить доступные каталоги метаданных.
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/"
Сервер получит список каталогов метаданных и вернет его вам.
iam/security-credentials/admin-role
Вывод показывает роль IAM с именем admin-role. Теперь вы можете добавить этот путь к вашему SSRF-пейлоаду, чтобы извлечь фактические учетные данные безопасности, связанные с этой ролью.
Выполните следующую команду, чтобы получить конфиденциальные учетные данные:
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/iam/security-credentials/admin-role"
Симулированная служба метаданных вернет учетные данные в формате JSON.
{"AccessKeyId":"AKIAIOSFODNN7EXAMPLE","SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}
Если этот запрос не возвращает данные в вашей среде, кратко проверьте /tmp/meta.log и убедитесь, что служба прослушивает 169.254.169.254:8000.
Успешно извлекая эти учетные данные, вы продемонстрировали серьезное влияние уязвимости SSRF в облачной среде.
Резюме
В этой лабораторной работе вы успешно изучили и использовали уязвимость подделки запроса на стороне сервера (SSRF). Вы узнали, как выявлять уязвимые параметры URL, наблюдая за поведением сервера при получении данных. Затем вы столкнулись с базовым фильтром ввода, предназначенным для блокировки локального доступа, и успешно обошли его, используя альтернативные представления IP-адресов. Наконец, вы продемонстрировали критическое влияние SSRF, извлекая конфиденциальные симулированные учетные данные облачных метаданных. Понимание этих методов необходимо как для выявления уязвимостей во время оценки безопасности, так и для внедрения надежных средств защиты в веб-приложениях.
