cve-2018-1273 Spring Expression Language 漏洞分析

目录

0x00 背景

x01 漏洞影响

受影响的范围

0x02 SpEL

类类型表达式

类实例化

变量和函数的使用

0x03 SpEL调试

0x04 实战分析

CVE-2018-1273

攻击Exploit的诞生

---

0x00 背景

最近Spring框架不大太平，接连爆出来多个RCE远程代码执行的CVE漏洞，其中有CVE-2018-1270，CVE-2018-1273，通过对造成漏洞部分代码进行分析,发现都是因为滥用SpEL的StandardEvaluationContext。

x01 漏洞影响

攻击者可以在未获得授权的情况下，将精心制作的请求参数注入到存在该漏洞的服务器上，从而发起远程代码执行攻击。

受影响的范围

· Spring Data Commons 1.13 - 1.13.10 (Ingalls SR10)

· Spring Data REST 2.6 - 2.6.10 (Ingalls SR10)
· Spring Data Commons 2.0 to 2.0.5 (Kay SR5)
· Spring Data REST 3.0 - 3.0.5 (Kay SR5)
· 更早的版本也会受到影响

0x02 SpEL

SpEL是一门非常简单的表达式语言，但是功能或者权限来说太大了，因此这里如果表达式能够被外部污染，基本上都可以造成RCE。

SpEL的具体语法，我这里就不一一介绍了，详情参考官方文档。我这里只说两个能够被有效利用的点。

类类型表达式

使用类类型表达式还可以进行访问类静态方法及类静态字段。使用T()来表示，其中类名必须是全称，java.lang包除外。因此这里就出现了第一类payload

类实例化

创建一个Java类实例，和上面一样，类名要求是全称。因此这里可以产生第二类payload

变量和函数的使用

在表达式里面要是用变量或者函数，需要提前在context使用setVariable和registerFunction才能使用，因此初步看没有太大利用价值。其中有两个内置变量#root根对象，#this代表Context对象。而在CVE-2018-1273的Spring Data Commons中

context在初始化的时候，没有传入根对象，但是后面显式调用了setRootObject，因此#root为Map对象，利用价值不大，#this为StandardEvaluationContext对象，方法比较多，还在研究中，感觉这里也能提取出一类payload，未完待续。

0x03 SpEL调试

我们在写出来payload后，需要校验一下payload是否有效，可以使用如下的代码快速进行校验。

0x04 实战分析

CVE-2018-1273

上面也贴出来部分造成漏洞的代码，现在把完整的代码贴出来，代码位于org,springframework.data.web.MapDataBinder类中

propertyName是攻击者可以控制的变量，但是代码中将它直接用来生成Expression。但是在使用之前我们发现有一段代码进行propertyName的有效性校验，它用来判断实体类的propertyName属性是否可写。

但是经过我们对这个isWritableProperty函数的分析，我们发现这里存在一个逻辑问题。

这个函数会造成propertyName如果是name和name[huangjacky]返回一个东西。

攻击Exploit的诞生

我们的演示程序中，实体类是这样定义的

因此我们对应的Exploit就应该为：

不出意外的话，这个时候可爱的计算器就出来了。