OGNL设计及使用不当造成的远程代码执行漏洞(5)

也就是这个经典的POC,大家开始第一次认识struts2漏洞(之前也有，只是那时很少有人去关注,或许很容易就能找到一个0day(而且是永远的0day,回溯一下框架历史,我不能再提示了!)。 myibatis框架也有引入OGNL的,亲!

由于ONGL的调用可以通过http传参来执行，为了防止攻击者以此来调用任意方法，Xwork设置了两个参数来进行防护：

OgnlContext的属性 'xwork.MethodAccessor.denyMethodExecution'（默认为真）
SecurityMemberAccess私有字段'allowStaticMethodAccess'（默认为假）

(这里我现在还没想明白,既然都有这步限制了?为什么后面的那些还会出现,难道官方只会看着公布的PoC打补丁?)

这里大家都知道,是使用#限制OgnlContext 'xwork.MethodAccessor.denyMethodExecution'和'allowStaticMethodAccess'上下文访问以及静态方法调用的值设置.而漏洞作者使用十六进制编码绕过了限制,从而调用@java.lang.Runtime@getRuntime()这个静态方法执行命令.

java.lang.Runtime.getRuntime().exit(1) （终止当前正在运行的 Java 虚拟机）

在某些struts2漏洞中已经开始改变这个观念,因为我们很难再绕过上面的安全限制了.去调用上下文的属性及静态方法执行恶意java代码.

但是"危险清单"中还有一个可以利用,OGNL表达式中居然可以去new一个java对象(见危险项清单 4.),对于构造PoC足够用了，而不需要上面那些条件.(之前也有类似的相关漏洞,我发现官方并不喜欢做代码审计的)

Apache Struts CVE-2013-2251 Multiple Remote Command Execution Vulnerabilities

这里漏洞原理大致是这样,作者一共提供了三个PoC:

http://.example.com/struts2-blank/example/X.action?action:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()} (这个和后面两个是有点区别的，多测试目标时你会发现！)

http://.example.com/struts2-showcase/employee/save.action?redirect:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}

http://.example.com/struts2-showcase/employee/save.action?redirectAction:%25{(new+java.lang.ProcessBuilder(new+java.lang.String[]{'command','goes','here'})).start()}

action:
redirect:
redirectAction:

这三关键字是struts2设计出来做短地址导航的,但它奇葩地方在于,如：redirectAction:${恶意代码}后面可以跟OGNL表达式执行,找这种相关的漏洞很好找（如果还有）,查看struts2源代码${},%{}等(struts2只认定这些特征的代码进入OGNL表达式执行流程)，struts2执行ognl表达式的实现功能的地方.

而java.lang.ProcessBuilder是另外一个可以执行命令的java基础类,还有后面大家手中的PoC(new文件操作及输入输出流相关危险类等),此时我们发现只要new对象然后调用其方法就可以了.不再需要上面的一些静态方法等.

这里只能将OGNL和struts2各打50大板了!

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-32032-5.html