freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

Spring Framework CVE-2022-22965漏洞分析
2022-04-13 09:15:07
所属地 广东省

一.     漏洞利用条件

jdk9+

Spring 及其衍生框架

使用tomcat部署spring项目

使用了POJO参数绑定

Spring Framework 5.3.X < 5.3.18 、2.X < 5.2.20 或者其他版本

二.     漏洞分析

一开始复现这个漏洞的时候,听其他师傅说是一个老漏洞CVE-2010-1266的绕过,之前也没调试过这个漏洞,看了些分析文章后,大概明白是对Spring中的bean的漏洞利用,通过API Introspector. getBeanInfo 可以获取到POJO的基类Object.class的属性class,进一步可以获取到Class.class的其他属性,其中就包括了classloader,再利用获取到的属性构造利用链,这次爆出来的漏洞既然是绕过,那么原理应该也差不多,首先先搭建环境,构造一个简单的POJO:

public class User {

private String name;

public String getName() {

return name;

}

public void setName(String name) {

this.name = name;

}

}

再写个简单的controller:

@RequestMapping("/test")

public String test(User user){

System.out.println(user.getName());

return "hello spring-mvc";

}

发送get请求:http://localhost:8080/test?name=test 即可完成一次简单的数据绑定。

在开始调试分析之前,首先需要对spring的数据绑定体系机构有个简单的了解,其中涉及到一个关键类org.springframework.validation.DataBinder类,DataBinder类实现了TypeConverter和PropertyEditorRegistry接口,作用主要是把字符串形式的参数转换成服务端真正需要的类型的转换,同时还有校验功能,其中有如下这些属性:

@Nullable

private final Object target;//需要数据绑定的对象

private final String objectName;//给对象起得名字默认target

@Nullable

private AbstractPropertyBindingResult bindingResult;//数据绑定后的结果

@Nullable

private SimpleTypeConverter typeConverter;//当target!=null时不会用到

private boolean ignoreUnknownFields = true;//忽略target不存在的属性,作用于PropertyAccessor的setPropertyValues()方法

private boolean ignoreInvalidFields = false;//忽略target不能访问的属性

private boolean autoGrowNestedPaths = true;//当嵌套属性为空时,是否可以实例化该属性

private int autoGrowCollectionLimit = DEFAULT_AUTO_GROW_COLLECTION_LIMIT;//对于集合类型容量的最大值

@Nullable

private String[] allowedFields;//允许数据绑定的资源

@Nullable

private String[] disallowedFields;//不允许的

@Nullable

private String[] requiredFields;//数据绑定必须存在的字段

@Nullable

private ConversionService conversionService;//为getPropertyAccessor().setConversionService(conversionService);

@Nullable

private MessageCodesResolver messageCodesResolver;//同bindingResult的

private BindingErrorProcessor bindingErrorProcessor = new DefaultBindingErrorProcessor();

private final List<Validator> validators = new ArrayList<>();//自定义数据校验器

其中bindingResult是BeanPropertyBindingResult的实例,内部会持有一个BeanWrapperImpl。

bind()是数据绑定对象的核心方法:将给定的属性值绑定到此绑定程序的目标,源码如下:

publicvoid bind(PropertyValues pvs) {
MutablePropertyValues mpvs = pvs instanceofMutablePropertyValues ? (MutablePropertyValues)pvs : newMutablePropertyValues(pvs);
this.doBind(mpvs);
}
protectedvoid doBind(MutablePropertyValues mpvs) {
this.checkAllowedFields(mpvs);
this.checkRequiredFields(mpvs);
this.applyPropertyValues(mpvs);
}

再来看看DataBinder类的继承关系,DataBinder有一个子类WebDataBinder,是一个特殊的DataBinder,用于从Web请求参数到JavaBean对象的数据绑定,而WebDataBinder的子类ServletRequestDataBinder用于执行从servlet请求参数到JavaBeans的数据绑定,包括对multipart文件的支持。

1649812116_6256229463f5ef9676628.png!small

在普通的Controller实现参数绑定的过程中自动实例化一个ServletRequestDataBinder,在客户端请求的过程中使用当前的ServletRequest作为参数调用bind()方法,于是可以来到这个地方下断点,这个过程中会调用到最上级的DataBinder类的dobind()方法,从而调用到DataBinder的applyPropertyValues方法:

protected void applyPropertyValues(MutablePropertyValues mpvs) {
try {
this.getPropertyAccessor().setPropertyValues(mpvs, this.isIgnoreUnknownFields(), this.isIgnoreInvalidFields());
} catch (PropertyBatchUpdateException var7) {
PropertyAccessException[] var3 = var7.getPropertyAccessExceptions();
int var4 = var3.length;

for(int var5 = 0; var5 < var4; ++var5) {
PropertyAccessException pae = var3[var5];
this.getBindingErrorProcessor().processPropertyAccessException(pae, this.getInternalBindingResult());
}
}

}

applyPropertyValues()方法主要是使用resultBinding对象内的BeanWraperImpl对象完成属性的赋值操作。

1649812128_625622a0710a27593c204.png!small

后续会调用到。

org.springframework.beans.AbstractNestablePropertyAccessor#getPropertyAccessorForPropertyPath

1649812152_625622b82a07608d9752c.png!small

跟进AbstractNestablePropertyAccessor#getPropertyAccessorForPropertyPath。

protectedAbstractNestablePropertyAccessor getPropertyAccessorForPropertyPath(String propertyPath) {
int pos = PropertyAccessorUtils.getFirstNestedPropertySeparatorIndex(propertyPath);
if(pos > -1) {
String nestedProperty = propertyPath.substring(0, pos);
String nestedPath = propertyPath.substring(pos + 1);
AbstractNestablePropertyAccessor nestedPa = this.getNestedPropertyAccessor(nestedProperty);
returnnestedPa.getPropertyAccessorForPropertyPath(nestedPath);
} else{
returnthis;
}
}

这里如果传进来的propertyPath包含.符号,pos则会赋值大于-1,具体的逻辑就不跟了,进入if语句后调用getNestedPropertyAccessor方法,之后经过如下的调用栈,来到resultBinding对象内的BeanWraperImpl对象的getCachedIntrospectionResults方法。

1649812162_625622c27903f26daab31.png!small

private CachedIntrospectionResults getCachedIntrospectionResults() {
if (this.cachedIntrospectionResults == null) {
this.cachedIntrospectionResults = CachedIntrospectionResults.forClass(this.getWrappedClass());
}

return this.cachedIntrospectionResults;
}

CachedIntrospectionResults 缓存了所有的bean中属性的信息,通过调试最后return的cachedIntrospectionResults变量可以看到,能够获取到的PropertyDescriptor属性描述器不仅仅有name,还有关键的class属性。

1649812249_6256231913537444be9e8.png!small

也可以在本地新建一个测试类来获取user这个bean的属性,如下:

1649812257_62562321c862ce2ebe9b3.png!small

至此,我们还需要了解到怎么去绕过CachedIntrospectionResults中的黑名单,看到CachedIntrospectionResults的构造方法。

1649812346_6256237a914a7a33f6726.png!small

for(int var5 = 0; var5 < var4; ++var5) {
PropertyDescriptor pd = var3[var5];
if(Class.class != beanClass || !"classLoader".equals(pd.getName()) && !"protectionDomain".equals(pd.getName())) {
if(logger.isTraceEnabled()) {
logger.trace("Found bean property '" + pd.getName() + "'" + (pd.getPropertyType() != null? " of type [" + pd.getPropertyType().getName() + "]" : "") + (pd.getPropertyEditorClass() != null? "; editor [" + pd.getPropertyEditorClass().getName() + "]" : ""));
}

pd = this.buildGenericTypeAwarePropertyDescriptor(beanClass, pd);
this.propertyDescriptorCache.put(pd.getName(), pd);
}
}

在第一次获取Bean的属性信息过程中,会初始化CachedIntrospectionResults从而去调用到其构造方法,但其中有个classLoader和protectionDomain的黑名单,导致于在所有jdk版本下面都不能直接去通过class属性中的classloader进行漏洞利用,所以到这里即便能够操作从bean中获得的动态class,也无法进行进一步利用。

绕过方法就是利用jdk9+的新特性,也就是module机制,简称模块化系统,在jdk9+中Class类有一个名为getModule()的新方法,它返回该类作为其成员的模块引用,而包含的模块引用当中就有classloader,如下:

1649812360_62562388b6a834bb77c13.png!small

于是可以通过class中的module去间接获取classloader,使CachedIntrospectionResults初始化时的黑名单无效化。

后面的利用思路,就是去思考能利用哪些可控的属性去完成漏洞利用,首先去枚举都有哪些属性,这里贴个小脚本:

<%!
publicvoid processClass(Object instance, javax.servlet.jsp.JspWriter out, java.util.HashSet set, String poc){
try{
Class<?> c = instance.getClass();
set.add(instance);
Method[] allMethods = c.getMethods();
for(Method m : allMethods) {
if(!m.getName().startsWith("set")) {
continue;
}
if(!m.toGenericString().startsWith("public")) {
continue;
}
Class<?>[] pType  = m.getParameterTypes();
if(pType.length!=1) continue;

if(pType[0].getName().equals("java.lang.String")||
pType[0].getName().equals("boolean")||
pType[0].getName().equals("int")){
String fieldName = m.getName().substring(3,4).toLowerCase()+m.getName().substring(4);
out.print(poc+"."+fieldName + "<br>");
}
}
for(Method m : allMethods) {
if(!m.getName().startsWith("get")) {
continue;
}
if(!m.toGenericString().startsWith("public")) {
continue;
}
Class<?>[] pType  = m.getParameterTypes();
if(pType.length!=0) continue;
if(m.getReturnType() == Void.TYPE) continue;
Object o = m.invoke(instance);
if(o!=null)
{
if(set.contains(o)) continue;
processClass(o,out, set, poc+"."+m.getName().substring(3,4).toLowerCase()+m.getName().substring(4));
}
}
} catch(java.io.IOException x) {
x.printStackTrace();
} catch(java.lang.IllegalAccessException x) {
x.printStackTrace();
} catch(java.lang.reflect.InvocationTargetException x) {
x.printStackTrace();
}
}
%>
<%
java.util.HashSet set = newjava.util.HashSet<Object>();
String poc = "class.module.classLoader";
User user = newUser();
processClass(user.getClass().getModule().getClassLoader(),out,set,poc);
%>

这段脚本只获取了int、string与boolean这些基本类型参数的属性,访问得到如下:

1649812375_6256239770d7ebddb7efa.png!small

枚举出来大概有两百八多个属性,在这些属性当中有几个控制着在tomcat上生成的access log的文件名,其默认值如下:

class.module.classLoader.resources.context.parent.pipeline.first.directory =logs
//将放置由此阀创建的日志文件的目录的绝对路径名或相对路径名。
class.module.classLoader.resources.context.parent.pipeline.first.prefix =localhost_access_log
//前缀添加到每个日志文件名称的开头
class.module.classLoader.resources.context.parent.pipeline.first.suffix = .txt
//后缀添加到每个日志文件名称的末尾
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat =.yyyy-mm-dd
//日志文件名中的自定义日期格式
class.module.classLoader.resources.context.parent.pipeline.first.pattern
//一种格式化布局,用于标识要记录的请求和响应中的各种信息字段,或单词 common或combined选择标准格式

其中比较值得注意的是其中的pattern,在tomcat中其属性的值由文字文本字符串组成,与前缀为“%”字符的模式标识符组合,还支持从cookie,传入头,传出响应头,Session或ServletRequest中的其他内容中写入信息,有如下模型:

%{xxx}i 传入请求头

%{xxx}o 用于传出响应头

%{xxx}c 对于特定的请求cookie

%{xxx}r xxx是ServletRequest中的一个属性

%{xxx}s xxx是HttpSession中的一个属性

然后通过调试也可以观察出各属性默认值:

1649812389_625623a58e8094e8572c9.png!small

于是就可以构造请求包,将log日志文件后缀改为.jsp,在请求头加入标识符变量值在pattern中构造webshell内容,发送完payload后重新调试可发现已成功修改日志配置。

1649812401_625623b1df2c679be7f17.png!small

在实际生产环境中,如果是tomcat直接单独启动的话,可以直接控制写入相对路径为“./webapps/ROOT/”下即可正常访问webshell。

1649812411_625623bb997f38e589c7e.png!small

三.     修复方式

目前官方已经发布了补丁,在最新版本v5.3.18和v5.2.20中已经完成了修复,如下:

https://github.com/spring-projects/spring-framework/commit/002546b3e4b8d791ea6acccb81eb3168f51abb15

1649812424_625623c8ad2d3891b38ce.png!small

修复过后class类中缓存的属性只包含以下这几个:

1649812431_625623cf41a18e91267c7.png!small

四.     Reference

https://blog.csdn.net/god_7z1/article/details/24416717

https://blog.csdn.net/lixiangchibang/article/details/84024253

# Spring漏洞 # 漏洞分析
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者