Struts2和Webwork远程命令执行漏洞分析(1)

本文希望看懂文章的人，可以专注于分析思路，但是不希望大家拿着POC到处搞站，本文不提供任何黑客工具，所有的POC，都是已经公布过，无数人都知道的。

xwork修补漏洞的悲剧(漏洞历史)：

xwork作为struts2和webwork的核心组件，曾经在已经修补过了“xwork参数拦截器允许ognl方法执行”漏洞，并给出了漏洞公告

http://struts.apache.org/2.x/docs/s2-003.html

S2-003

第一次修补

但是这个修补，最终的结果是个悲剧。大家还记得我以前说过，在《Struts2框架安全缺陷》一文中，完全不懂web安全的开发人员，为了修补XSS，竟然仅仅针对POC，过滤了这段字符“〈script〉”，一旦用户提交“〈script xxx〉”就绕过的傻X修补方式。

他们保持一贯的风格，利用正则“{\\p{Graph}&&[^,#:=]}*”修补此漏洞。并且又仅仅针对攻击者给出的POC，做出修补，使用POC测试通过就发布了。

解析下xwork开发人员使用POC的几个悲剧的测试用例。

为了让ParametersInterceptor认为它是个合法ognl语句，变量中必须最终包含#。

这行无法通过验证，java在做字符串运算时，\u0023会被转义为#之后，才会做匹配，所以返回false。下图可以看到，\u0023和#是完全相等的。

所以修补漏洞的开发人员，自作聪明，直接用正则把#干掉了。

攻击者发来的虽然是\u0023，但是这段字符在内存中做字符串运算时，会先变成\\u0023然后才做运算。java在处理用户提交的一段string包含\时，为了保证数据完整性，会自动多加一个\用做转义，比如用户提交了数据“\n”，在内存中作字符串运算时，不会真的用换行做运算，而是拿”\\n”这段字符做比较。那么用户提交的\u0023被转为\\u0023，就会绕过对#的检查。

证据如图：

这两个case没有通过代码验证原因同上。

悲剧就在这里，这里虽然是\\u0023，符合用户提交的场景，悲剧是这段字符里面因为有空格，就在+两边，所以无法通过，而攻击者如果去掉空格，就通过了。

官方就这样发布了，其实发布的是个漏洞版。

这是第一次修补，这次修补其实是大家都知道，因为发了公告出来，官方虽然公告说是高危，但是官方只知道攻击者可以通过ognl表达式修改server端的session等信息。这时官方还没有意识到这其实是个远程代码执行漏洞，ognl不仅仅支持修改，还支持执行一些静态方法，比如@Runtime@getRuntime().exec(“calc”)。

服务器租用/服务器托管中国五强！虚拟主机域名注册顶级提供商！15年品质保障！--亿恩科技[ENKJ.COM]