spring-shell-vuln

Spring4Shell: Уязвимость удаленного выполнения кода в Spring Core

Компания Spring подтвердила наличие RCE в Spring Framework. Команда только что опубликовала заявление вместе с руководствами по смягчению последствий этой проблемы. Теперь эта уязвимость может отслеживаться как CVE-2022-22965.

Предоставлена некоторая информация об уязвимости Spring4Shell, а также подробности в статье Spring4Shell: Детали и эксплойт. Кроме того, команда безопасности из Praetorian подтвердила, что Spring Core на JDK9+ уязвим для удаленного выполнения кода из-за обхода CVE-2010-1622.

Изначально это началось 30 марта: первое уведомление об уязвимости было намекнуто лидером команды KnownSec 404, Heige. Он написал в твиттере предупреждающее сообщение "Spring core RCE （JDK >=9" вместе с изображением PoC.

Когда мы начали освещать историю этой уязвимости, Heige исчез из Twitter. Причина этого неизвестна, но, возможно, в этом что-то есть.

События

В конце 2021 года интернет был в огне из-за публикации Zero-day уязвимости удаленного выполнения кода, также известной как Log4Shell, в Apache Log4j2. Уязвимость была найдена командой безопасности Alibaba Cloud.

- Эта уязвимость НЕ так серьезна, как Log4Shell. Все сценарии атак более сложны из-за природы атак на манипуляцию загрузчиком классов (Class Loader Manipulation) в Java. Эксплуатация Spring4Shell требует глубоких знаний Java для получения работающего PoC. Манипуляция загрузчиком классов сложнее для понимания, чем уязвимость Log4Shell.

Сегодня исследователи нашли еще одну серьезную уязвимость, которая может нанести серьезный ущерб. Теперь ошибка отслеживается как CVE-2022-22965, мы можем называть ее Spring4Shell. Уязвимость существует в Spring Core с версией JDK больше или равной 9.0.

Spring Framework и производные фреймворки spring-beans-*.jar файлы или CachedIntrospectionResults.class

Все детали ниже теперь подтверждены. Я не несу ответственности за любой причиненный ущерб.

Детали уязвимости и расследование

Как один из самых популярных легковесных Java-фреймворков с открытым исходным кодом, Spring позволяет разработчикам сосредоточиться на бизнес-логике и упрощает цикл разработки корпоративных приложений на Java.

Эксплуатация требует конечной точки с включенным DataBinder (например, POST-запрос, который автоматически декодирует данные из тела запроса) и сильно зависит от сервлет-контейнера для приложения. Например, когда Spring развернут на Apache Tomcat, WebAppClassLoader доступен, что позволяет атакующему вызывать геттеры и сеттеры для записи вредоносного JSP-файла на диск. Однако, если Spring развернут с использованием встроенного сервлет-контейнера Tomcat, загрузчик классов является LaunchedURLClassLoader, который имеет ограниченный доступ.

Тем не менее, в версии JDK9 (и выше) Spring Framework, удаленный атакующий может получить объект AccessLogValve и вредоносные значения полей через функцию связывания параметров фреймворка при соблюдении определенных условий.

• В настоящее время известно, что для срабатывания этой уязвимости необходимы два основных условия:
• Использование Spring MVC Framework и JDK9 и выше

(1). Проверка номера версии JDK

На работающем сервере системы организации выполните команду "java -version" для проверки версии JDK. Если номер версии меньше или равен 8, то система не подвержена этой уязвимости.

(2). Проверка использования Spring Framework

1. Если проект системы организации развернут в виде war-пакета, выполните следующие шаги для проверки.

• Распакуйте war-пакет: Измените расширение war-файла на .zip и распакуйте zip-файл.
• Найдите jar-файл в формате spring-beans-*.jar (например, spring-beans-5.3.16.jar) в распакованной директории. Если он существует, это означает, что бизнес-система разработана с использованием Spring Framework.
• Если файл spring-beans-*.jar не существует, найдите наличие файла CachedIntrospectionResuLts.class в распакованной директории. Если он существует, это означает, что бизнес-система разработана с использованием Spring Framework.

2. Если проект системы организации запускается напрямую и самостоятельно в виде jar-пакета, выполните следующие шаги для проверки.

• Распакуйте jar-пакет: Измените расширение jar-файла на .zip и распакуйте zip-файл.
• Найдите jar-файл в формате spring-beans-*.jar (например, spring-beans-5.3.16.jar) в распакованной директории. Если он существует, это означает, что бизнес-система разработана с использованием Spring Framework.
• Если файл spring-beans-*.jar не существует, найдите наличие файла CachedIntrospectionResuLts.class в распакованной директории. Если он существует, это означает, что бизнес-система разработана с использованием Spring Framework.

(3) Комплексное расследование

После выполнения двух вышеуказанных шагов по проверке, если одновременно выполняются следующие два условия, можно определить, что система подвержена данной уязвимости:

1. Номер версии JDK 9 и выше;
2. использование Spring Framework или производного фреймворка.

Руководства по устранению уязвимости

Теперь команда Spring исправила уязвимость и выпустила последние версии Spring Boot 2.6.6 и 2.5.12, которые базируются на Spring Framework 5.3.18.

Защита с помощью WAF

На устройствах защиты сети, таких как WAF, реализуйте фильтрацию правил для строк, таких как "class.", "Class.", ".class." и ".Class.", в соответствии с фактическим трафиком развернутых сервисов. После фильтрации правил протестируйте работу бизнес-операций, чтобы избежать дополнительных воздействий.

Временные меры по исправлению

Временное устранение утечки должно выполняться одновременно в два этапа:

1. Найдите аннотацию @InitBinder глобально в приложении, чтобы проверить, вызывается ли метод dataBinder.setDisallowedFields в теле метода. Если обнаружено использование этого фрагмента кода, добавьте {"class.", "Class.", ".class.", ".Class."} в исходный черный список. (Примечание: если этот фрагмент кода используется часто, его нужно добавить везде.)

2. Создайте следующий глобальный класс в пакете проекта прикладной системы и убедитесь, что этот класс загружен Spring (рекомендуется добавить его в пакет, где находится Controller). После добавления класса необходимо перекомпилировать и упаковать проект, провести функциональную проверку и перевыложить проект.

import org.springframework.core.annotation.Order;

import org.springframework.web.bind.WebDataBinder;

import org.springframework.web.bind.annotation.ControllerAdvice;

import org.springframework.web.bind.annotation.InitBinder;

@ControllerAdvice

@Order(10000)

public class GlobalControllerAdvice{ 

     @InitBinder

     public void setAllowedFields(WebDataBinder dataBinder){

     String[] abd = new String[]{"class.*","Class.*","*.class.*","*.Class.*"};

     dataBinder.setDisallowedFields(abd);

     }

}

Из Git-репозитория проектов Spring видно, что разработчики Spring работают над исправлением уязвимости удаленного выполнения кода, но нам нужно дождаться официального подтверждения.