В модулa 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» при свързването на обработчици на заявки и обвързване на параметри на уеб формуляри в формат «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 и записването на атакуващия код в този файл. Създаденият файл става достъпен за директни заявки и може да се използва като уеб черупка. За атака на уязвимо приложение в средата на 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
