0x00 前言

这个漏洞与之前那个SpringBoot的SpEL表达式注入漏洞点基本一样,而且漏洞爆出来的时间点也差不多,可是没有找到那个漏洞的CVE编号,不知道是什么原因。

这个漏洞的触发点也是对用户传的参数的递归解析,从而导致SpEL注入,可是两者的补丁方式大不相同。Springboot的修复方法是创建一个NonRecursive类,使解析函数不进行递归。而SpringSecurityOauth的修复方法则是在前缀${前生成一个六位的字符串,只有六位字符串与之相同才会对其作为表达式进行解析。然而如果请求足够多,这种补丁也是会失效的。

0x01 调试分析

payload:
http://localhost:8080/oauth/authorize?response_type=token&client_id=acme&redirect_uri=${new%20java.lang.ProcessBuilder(new%20java.lang.String(new%20byte[]{99,97,108,99})).start()}

首先,这个漏洞是在错误页触发的,所以这里在错误页的控制器打个断点。可以看到,最后渲染视图的时候使用了SpelView,并传入一个模板字符串,跟springboot的洞类似。

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

然后跟到render方法,接收模板字符串之后,接着使用replacePlaceholders方法,对模板进行解析。

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

跟进一下replacePlaceholders方法

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

跟进parseStringValue方法,这个方法与springboot中的方法基本相同,简单看一下。

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

72行进行一次递归,用于解析模板中类似于${${}}的结构。由于这里的模板只是一个单纯的${errorSummary},故不跟进这里。

73行是将errorSummary作为参数传入SpEL模板解析引擎

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

可以看到,35行将errorSummary转换成了一个字符串,注意看这个值,其中包含我们的payload:${xxxx}。

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

return之后回到parseStringValue函数,将返回值赋值给propVal。

继续跟进,到87行,这里对propVal又进行了一次递归解析。而propVal的值中刚好包含我们的payload(即包含“${}”)

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

跟进递归,到66行成功将我们的payload从${}中提取出来,马上就到触发点了

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

跟进到73行,将payload传入resolvePlaceholder,继续跟进

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

成功在35行将payload作为SpEL表达式解析,弹出了计算器。

0x02 补丁分析

SpringSecurityOauth RCE (CVE-2016-4977) 分析与复现-LMLPHP

可以看到,这里在${前加了个

RandomValueStringGenerator().generate(),用于生成一个随机字符串。可是正如前面说的,如果可以发出足够多的请求,那么这个补丁依旧是可以被利用的。

0x03 参考

Spring Security OAuth RCE (CVE-2016-4977) 漏洞分析

05-04 01:41