seanpesce/cve-2024-22243Примеры эксплуатируемых сценариев для CVE-2024-22243, затрагивающего Spring framework (открытое перенаправление и SSRF).
Автор: Sean Pesce
Этот проект содержит пример веб-приложения, демонстрирующего сценарии эксплуатации для CVE-2024-22243, уязвимости разбора URL в Java-фреймворке Spring Framework (официальное раскрытие здесь).
Затронутые версии Spring разбирают сегмент userinfo URL-адресов уникальным образом, из-за чего извлечённый сегмент имени хоста может отличаться от того, что получают многие другие распространённые библиотеки.
Аномальное поведение вызвано следующим регулярным выражением ("regex") в классе
UriComponentsBuilder
(добавленным
этим коммитом
в 2014 году):
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
Это регулярное выражение не допускает символ «левая квадратная скобка» ([) в сегменте userinfo. Однако,
судя по всему, Spring является исключением в этом поведении, поэтому вызов для объекта
,
созданного с помощью
или
,
может приводить к неожиданному поведению. Классы
,
и
также затронуты из-за их внутреннего использования ; следовательно,
реализации могут оказаться уязвимыми даже без прямого использования .
getHost()UriComponentsBuilderUriComponentsBuilderДля специально сформированных входных данных Spring возвращает значение имени хоста, которое отличается от всех перечисленных ниже:
java.net.URI (по сообщениям, только для определённых версий Java; другие версии вызывают URISyntaxException)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(Обратите внимание, что этот список не является исчерпывающим.)
Это поведение потенциально делает веб-приложения на основе Spring уязвимыми к открытому перенаправлению и подделке серверных запросов (SSRF), если зависящая от этих классов реализация использует доверенные имена хостов для авторизации или других механизмов, связанных с безопасностью.
Пример веб-приложения содержит два уязвимых эндпоинта.
Первый эндпоинт /redirect показывает, как аномальный разбор URL в Spring может привести к открытому
перенаправлению. Его можно эксплуатировать с помощью URL-адреса, например:
https://127.0.0.1[@evil.com
Второй эндпоинт /health-check демонстрирует, как расхождение в разборе URL между Spring и
классом URL из стандартной библиотеки Java может привести к подделке серверных запросов (SSRF). Его
можно эксплуатировать с помощью URL-адреса, например:
https://evil.com[@127.0.0.1
Чтобы собрать этот проект с помощью Maven, просто выполните следующую команду (проверено на OpenJDK 17):
mvn clean package
Затем запустите веб-приложение, например, следующей командой:
java -jar seanpesce-cve-2024-22243.jar 9999
Веб-приложение будет доступно по адресу http://127.0.0.1:9999/.
Чтобы собрать docker-образ, выполните следующую команду:
docker build -t seanpesce-cve-2024-22243:latest .
Затем запустите веб-приложение, например, следующей командой:
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
Веб-приложение будет доступно по адресу http://127.0.0.1:9999/ на хосте Docker.
Этот репозиторий также содержит правила semgrep для поиска
потенциально уязвимых путей кода. spring-cve-2024-22243_loose.yaml
выполняет наивные проверки на любое использование уязвимых API; поэтому он часто возвращает большое
количество ложных срабатываний. spring-cve-2024-22243_strict.yaml
пытается использовать более строгую логику и анализ потоков данных (taint analysis); однако он не был
тщательно протестирован и с высокой вероятностью может пропустить некоторые уязвимые реализации (особенно при отсутствии
Semgrep Pro, который требуется для межфайлового анализа).