Критическая уязвимость Spring4Shell

Что случилось?

В популярном Java-фреймворке для разработки веб-приложений Spring Framework была обнаружена уязвимость нулевого дня (0-day), позволяющая удаленное выполнение кода без аутентификации. Уязвимости был присвоен номер CVE-2022-22965. Также ее называют Spring4Shell и SpringShell (по аналогии с нашумевшей в декабре 2021 года Log4Shell).

Уже наблюдаются попытки массовой эксплуатации уязвимости злоумышленниками в целях компрометации приложений и систем.

29-го марта исследователи codeplutos, meizjm3i из AntGroup FG Security Lab сообщили об уязвимости VMware, компании-владельцу фреймворка. На следующий день, пока готовилось исправление, произошла публичная утечка всех деталей уязвимости.

31-го марта Spring официально подтвердили наличие уязвимости и выпустили версии Spring Framework 5.3.18 и 5.2.20 с исправлениями. Также были выпущены версии Spring Boot 2.6.6 и 2.5.12, которые зависят от Spring Framework 5.3.18.

Отметим, что в то же время появилась информация о двух других, не связанных с CVE-2022-22965, уязвимостях, что создало путаницу. Первая из них, CVE-2022-22963, позволяет удаленное выполнение кода, была обнаружена в Spring Cloud Function (не входит в Spring Framework), и исправлена в версиях 3.1.7 и 3.2.3. Вторая, CVE-2022-22950, позволяет остановить работу приложения, была обнаружена в Spring Framework, и исправлена в версии 5.3.17.

Что затронуто?

Как минимум, уязвимость затрагивает приложения на базе SpringMVC и Spring WebFlux, работающие на JDK 9+.

Условия эксплуатации уязвимости в отдельном случае, который был описан в первичном отчете:

• JDK 9 или выше,
• Apache Tomcat в качестве контейнера сервлетов,
• упаковка в WAR (в отличие от исполняемого jar-файла Spring Boot),
• зависимость от spring-webmvc или spring-webflux,
• версия Spring Framework с 5.3.0 по 5.3.17, с 5.2.0 по 5.2.19, или устаревшая (неподдерживаемая) версия.

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

По оценке Rapid7, любые компоненты, использующие Spring Framework версии до 5.2.20 или 5.3.18 вместе с JDK версии 9 или выше, считаются потенциально уязвимыми. Компоненты, которые вдобавок к этим условиям используют аннотацию @RequestMapping и параметры типа Plain Old Java Object (POJO), считаются уязвимыми и подвержены риску эксплуатации. Компоненты, которые дополнительно ко всем предыдущим условиям используют Apache Tomcat, наиболее подвержены риску из-за наличия готового эксплойта.

Rapid7 приводят пример уязвимого кода в своем отчете. Помимо этого, Microsoft выпустили отчет с анализом уязвимости.

Администраторы и разработчики могут проверить свои приложения с помощью curl путем следующего запроса:

$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

Приложения, которые возвращают ответ с HTTP-кодом 400, считаются уязвимыми. Другие ответы не свидетельствуют о наличии или отсутствии уязвимости.

Что делать?

Наиболее оптимальным решением является обновление приложений до версий Spring Framework 5.3.18 и 5.2.20, в которых исправлена эта уязвимость.

Если это невозможно сделать сейчас, то в качестве простого временного решения разработчикам рекомендуется воспользоваться методом setDisallowedFields у WebDataBinder через @ControllerAdvice, чтобы запретить связанные с уязвимостью шаблоны полей запроса. Примеры этого решения приведены в блогах Spring и Praetorian.

Как отмечают Spring, предыдущее решение может оставить пробелы. В частности, если контроллер сам устанавливает запрещенные параметры через собственный метод @InitBinder, что переопределяет глобальную настройку.

Более продвинутым решением будет расширение RequestMappingHandlerAdapter для обновления WebDataBinder после всей остальной инициализации. Для этого приложение может определить бин (bean) WebMvcRegistrations (SpringMVC) или WebFluxRegistrations (Spring WebFlux). Пример этого решения доступен в упомянутом блоге Spring.

При наличии WAF в качестве временного решения можно блокировать HTTP-запросы, содержащие такие строки, как “class.”, “Class.”, “.class.”, и “.Class.”. Тем не менее, этот способ защиты легко обойти, поэтому не стоит рассчитывать на него в долгосрочной перспективе.

Наконец, организациям рекомендуется вести мониторинг журналов приложений, а также появление на серверах новых процессов, с целью своевременного выявления аномалий, которые могут свидетельствовать об успешном взломе.

Нужна помощь?

Наши специалисты готовы помочь вам с проверкой на наличие Spring4Shell и других уязвимостей с помощью тестирования на проникновение и расследований инцидентов. 

В случае выявления уязвимостей, угроз и атак мы поможем защитить и очистить вашу систему.

Обратитесь к нам за дополнительной информацией. Мы с радостью ответим на ваши вопросы.

Подпишитесь на наш канал Телеграм, чтобы не пропустить наши новости.