Spring Framework RCE分析(CVE-2022-22965)

admin 2025年2月24日13:00:41评论17 views字数 2435阅读8分7秒阅读模式

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.18

Spring Framework 5.2.X < 5.2.20

漏洞分析

Spring中对象绑定是由org.springframework.beans.BeanWrapperImpl实现的。在参数绑定过程中,由其父类AbstractPropertyAccessorsetPropertyValues方法为请求中所有参数对应的bean对象属性赋值。

Spring Framework RCE分析(CVE-2022-22965)

跟进到setPropertyValue方法,由属性名获取BeanWrapperImpl的方法getPropertyAccessorForPropertyPath返回到的是封装了tomcat日志属性的对象org.apache.catalina.valves.AccessLogValveBeanWrapperImplSpring Framework RCE分析(CVE-2022-22965)

再跟进到到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中,后续用请求参数键值对pvnestedPa封装的AccessLogValve对象中相应的属性赋值。结合以上,可以得出Spring这么一个特性:Spring对象绑定请求参数的路由Mapping,其POJO类所有具有settergetter属性,也包括属性对应类的属性,都可通过请求参数修改。

Spring Framework RCE分析(CVE-2022-22965)

这时稍加思考会发现,我们的示例类User并没有显示的设置一个class属性,但回看封装了示例类的BeanWrapperImpl对象,nestedPropertyAccessors属性中存在一个封装ClassBeanWrapperImpl对象。Spring Framework RCE分析(CVE-2022-22965)

那是因为每个对象都继承于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构造方法可以体现。

Spring Framework RCE分析(CVE-2022-22965)

而在JDK9后出现的java.lang.Module存在一个ClassLoader属性:loader,又存在它的getter方法:getClassLoader,CVE-2010-1622的修复就这么被轻松绕过了。这也是目前的POC只能攻击JDK9的原因。

以下是具体验证截图:

Spring Framework RCE分析(CVE-2022-22965)

原文始发于微信公众号(天玄安全实验室):Spring Framework RCE分析(CVE-2022-22965)

免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年2月24日13:00:41
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   Spring Framework RCE分析(CVE-2022-22965)https://cn-sec.com/archives/897836.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉.

发表评论

匿名网友 填写信息