index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html
![]()
本文详细介绍了Spring Framework中存在的远程代码执行漏洞,该漏洞影响JDK 9及以上版本。攻击者可通过框架的参数绑定功能,利用AccessLogValve对象写入恶意代码,从而导致远程代码执行。文章深入分析了漏洞的触发条件、实现原理,以及与Struts2漏洞的异同。此外,文章还解释了绕过CVE-2010-1622修复的原因,并提供了具体的验证截图,为读者提供了对该漏洞的全面理解。
💥 漏洞触发条件:该漏洞主要存在于使用JDK 9及以上版本的Spring MVC框架中,且需要Spring框架及其衍生的spring-beans-*.jar文件,或存在CachedIntrospectionResults.class。
🔑 漏洞核心原理:攻击者利用Spring的对象绑定功能,通过构造特定的请求参数,获取AccessLogValve对象并注入恶意字段值,进而触发pipeline机制,最终实现任意文件写入。
🔍 漏洞绕过机制:在JDK 9之后,由于java.lang.Module的引入,其ClassLoader属性可以通过getClassLoader的getter方法访问,从而绕过了CVE-2010-1622的修复。
💡 漏洞利用关键:攻击者可以利用Spring框架的特性,通过请求参数修改POJO类(包括属性对应类的属性)的属性值,进而控制AccessLogValve类,实现恶意代码注入。
原创 p1ay2win 2022-04-01 10:49
3月29日,Spring Framework 存在远程代码执行漏洞,在 JDK 9 及以上版本环境下,远程攻

3月29日,Spring Framework 存在远程代码执行漏洞,在 JDK 9 及以上版本环境下,远程攻击者可利用该漏洞写入恶意代码导 致远程代码执行漏洞。
漏洞描述作为目前全球最受欢迎的Java轻量级开源框架,在Spring框架的JDK9版本(及以上版本)中,远程攻击者可在满足特定条件的基础上,通过框架的参数绑定功能获取AccessLogValve对象并诸如恶意字段值,从而触发pipeline机制并 写入任意路径下的文件。目前已知,触发该漏洞需要满足两个基本条件:使用JDK9及以上版本的Spring MVC框架Spring 框架以及衍生的框架spring-beans-*.jar 文件或者存在CachedIntrospectionResults.class
影响范围Spring Framework 5.3.X < 5.3.18Spring Framework 5.2.X < 5.2.20
漏洞分析Spring中对象绑定是由
org.springframework.beans.BeanWrapperImpl
实现的。在参数绑定过程中,由其父类
AbstractPropertyAccessor
的
setPropertyValues
方法为请求中所有参数对应的bean对象属性赋值。

跟进到
setPropertyValue
方法,由属性名获取
BeanWrapperImpl
的方法
getPropertyAccessorForPropertyPath
返回到的是封装了tomcat日志属性的对象
org.apache.catalina.valves.AccessLogValve
的
BeanWrapperImpl
。再跟进到到
AbstractNestablePropertyAccessor
,发现它的逻辑是会用
.
号分割,递归获取封装对应属性的
BeanWrapperImpl
直到最后一个属性并返回。
protected AbstractNestablePropertyAccessor getPropertyAccessorForPropertyPath(String propertyPath) {
int pos = PropertyAccessorUtils.getFirstNestedPropertySeparatorIndex(propertyPath);
// Handle nested properties recursively.
if (pos > -1) {
String nestedProperty = propertyPath.substring(0, pos);
String nestedPath = propertyPath.substring(pos + 1);
AbstractNestablePropertyAccessor nestedPa = getNestedPropertyAccessor(nestedProperty);
return nestedPa.getPropertyAccessorForPropertyPath(nestedPath);
}
else {
return this;
}
}
最后回到
setPropertyValue
中,后续用请求参数键值对
pv
为
nestedPa
封装的
AccessLogValve
对象中相应的属性赋值。结合以上,可以得出Spring这么一个特性:
Spring对象绑定请求参数的路由Mapping,其POJO类所有具有setter
和getter
属性,也包括属性对应类的属性,都可通过请求参数修改。
这时稍加思考会发现,我们的示例类User
并没有显示的设置一个class
属性,但回看封装了示例类的BeanWrapperImpl
对象,nestedPropertyAccessors
属性中存在一个封装Class
的BeanWrapperImpl
对象。那是因为每个对象都继承于Object
类,都存在getClass
方法,所以class
就是每个对象的嵌套属性,可以被这样神不知鬼不觉的被访问到。还有细心的同学会发现这个漏洞的利用方式很像Struts2的S2-020,都是用class
属性最后控制AccessLogValve
类,但差别是Spring中先通过class获取module,再从module获取classLoader。class.classLoader.resources.context.parent.pipeline.first.directory =logs
class.classLoader.resources.context.parent.pipeline.first.prefix =localhost_access_log
class.classLoader.resources.context.parent.pipeline.first.suffix = .txt
class.classLoader.resources.context.parent.pipeline.first.fileDateFormat =.yyyy-mm-dd
那是因为在CVE-2010-1622后,Spring限制了bean直接从Class实例直接获取classLoader,具体在org.springframework.beans.CachedIntrospectionResults#CachedIntrospectionResults
构造方法可以体现。
而在JDK9后出现的java.lang.Module
存在一个ClassLoader属性:loader
,又存在它的getter
方法:getClassLoader
,CVE-2010-1622的修复就这么被轻松绕过了。这也是目前的POC只能攻击JDK9的原因。以下是具体验证截图:阅读原文
跳转微信打开