Критическая 0-day уязвимость в Spring Framework, применяемом во многих Java-проектах

В модуле Spring Core, поставляемом в составе фреймворка Spring Framework, выявлена критическая 0-day уязвимость, позволяющая неаутентифицированному удалённому атакующему выполнить свой код на сервере. Пока не ясно насколько катастрофичны могут быть последствия выявленной проблемы и будут атаки столь же массовыми, как в случае с уязвимостью в Log4j 2. Уязвимости присвоено кодовое имя Spring4Shell, но CVE-идентификатор пока не назначен. В Spring Framework проблема остаётся неисправленной и в сети уже доступно несколько рабочих прототипов эксплоитов (1, 2, 3, 4). Проблему усугубляет то, что многие корпоративные Java-приложения на базе Spring Framework выполняются с правами root и уязвимость позволяет полностью скомпрометировать систему.

По некоторым оценкам модуль Spring Core используется в 74% Java-приложений. Опасность уязвимости снижает то, что атаке подвержены только приложения, использующие аннотацию «@RequestMapping» при подключении обработчиков запросов и привязку параметров web-форм в формате «name=value» (POJO, Plain Old Java Object), вместо применения JSON/XML.

Какие именно Java-приложения и фреймворки подвержены проблеме ещё не ясно. Уязвимость блокирует добавление в чёрный список полей «class», «module» и «classLoader» или использование явного белого списка разрешённых полей. Эксплуатация уязвимости возможна только при использовании Java/JDK 9 или более новой версии. Проблема вызвана возможностью обхода защиты от уязвимости CVE-2010-1622, исправленной в Spring Framework ещё в 2010 году и связанной с выполнением обработчика classLoader при разборе параметров запроса.

Работа эксплоита сводится к отправке запроса с параметрами «class.module.classLoader.resources.context.parent.pipeline.first.*», обработка которых приводит к созданию jsp-файла в корневом окружении Apache Tomcat и записи в этот файл указанного атакующим кода. Созданный файл становится доступным для прямых запросов и может использоваться в качестве web shell. Для атаки на уязвимое приложение в окружении Apache Tomcat достаточно отправить запрос с определёнными параметрами при помощи утилиты curl. curl -v -d «class.module.classLoader.resources.context.parent.pipeline .first.pattern=код_для_вставки_в_файл &class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp &class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT &class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar &class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=» http://localhost:8080/springmvc5-helloworld-exmaple-0.0.1-SNAPSHOT/rapid7

Рассматриваемую проблему в Spring Core не стоит путать с выявленными на днях уязвимостями CVE-2022-22963 и CVE-2022-22950. Первая проблема затрагивают пакет Spring Cloud и устранена в выпусках 3.1.7 и 3.2.3. Вторая проблема присутствует в Spring Expression и исправлена во Spring Framework 5.3.17. Это принципиально другие уязвимости. Про новую уязвимость разработчики Spring Framework ещё не сделали никаких заявлений и не опубликовали исправление.

В качестве временной меры для защиты рекомендуется использовать в коде чёрный список недопустимых параметров запроса: import org.springframework.core.Ordered; 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 BinderControllerAdvice { @InitBinder public void setAllowedFields(WebDataBinder dataBinder) { String[] denylist = new String[]{«class.», «Class.», «.class.», «.Class.»}; dataBinder.setDisallowedFields(denylist); } }

Источник: opennet.ru