文章前，先Ps一下

这文章有漏洞影响到百度，所以先发百度，修补后，正在和剑心商量小范围群发各个互联网安全团队，结果老外也研究出，并且直接爆出这个文章的最终POC。想想刚好明天我生日，发了，庆祝吧。身在互联网公司安全团队，有研究的结果，总要先保证自己安全才会往外发，这是基本原则。

继上次struts远程代码执行漏洞后，前段时间又发布了一个远程代码执行漏洞。影响范围极广，利用方式相对上次要苛刻一点，但是读完本文，批量抓鸡不难。

几天前，KJ就在微博上把我卖了，我们确实在研究这个漏洞，官方早就发公告。看到漏洞介绍后，翻阅了struts官网后，作者第一时间想到的，就是没见过比apache更傻X的官方，struts网站没有任何页面有此漏洞的连接，凭空在那个目录下多出个s007.html页面（你能猜到这个地址？），如果不是看到apache的jira系统的一则留言信息，都不知道这个漏洞公告的存在。无奈的想起一个网络流行语，以及一些其他网络流行语。

官方公告

我们看看apache的jira系统中那则留言信息，作者重新描述下：

到达showcase的validation的case页面，选择field validation页面。

在int类型或date类型的输入框中，输入

<’+#application+’>

就会在返回页面中，显示出struts应用程序application context中的内容（toString后）。在application中，通常会放着数据库连接等重要数据，一旦被获取的后果很严重。

由于这个东西是个ognl，所以漏洞上说，可以执行任意ognl代码。但是漏洞公告只给出了简单poc，并没有告诉大家怎样执行代码。

之前研究过struts的ognl执行机制，所以能很快的写出执行任意代码的poc来。这个不是难题，而本文的意义，在于告诉大家这个漏洞背后的技术细节。

分析补丁

在官方的公告上，已经详细的指出了修补的代码。

这是漏洞修补的代码变动文件

https://issues.apache.org/jira/browse/WW-3668?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel#issue-tabs

那几个测试文件，就不必看了，也就是说，一共修改了这几个文件

MODIFY /struts/struts2/trunk/core/src/main/resources/template/simple/text.ftl 
 
MODIFY /struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/interceptor/ConversionErrorInterceptor.java 
 
MODIFY /struts/struts2/trunk/core/src/main/java/org/apache/struts2/interceptor/StrutsConversionErrorInterceptor.java 
 
MODIFY /struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/validator/validators/RepopulateConversionErrorFieldValidatorSupport.java

修补的手段非常的简洁，简洁到令人发指，居然用XSS的修补方式，前后加两个引号，之后escape一下。换句话说，这样的修补，除非你能绕过apache的escape，否则真的没辙。作者知道之前写过文章，说过可以绕过escape，不过那是在特定的条件下成功，而当前这里，是行不通的。

看不懂OGNL没关系，我们举个贴近的例子，后面也会有真实代码解析，比较复杂，不熟悉的可能看不懂，所以先用js伪代码给大家看看原理。下面是段JAVASCRIPT代码：

Var stringOgnlExec = ‘$url’;

原来的这段代码中，$url，是可以被用户控制的，于是，攻击者提交了

<’+#application+’>

这段就变成了

Var stringOgnlExec = ‘<’+#application+’>’;

最终，#application会被执行，并返回结果。至于那个“<”符号，和“>”符号，一点用处都没有，可以忽略。官方的修补代码，也相当于对$url变量，做了EscapeJava，过滤双引号。看到这里，作者的心都凉了。尝试了几种转义绕过，均以失败告终。官方还是有长进的，补丁简单，有效（ps：我后来看了看，好像是别人建议官方这么做得，当然也可能百度翻译的不准确）。

漏洞原理

这些开源的系统，我们总是能通过补丁，可以有效的反推的出漏洞的产生和关键点。从上一段可以看到，它的精髓，其实是“注入”。

这段文字，可以明确的指出研究方向：“User input is evaluated as an OGNL expression when there’s a conversion error”，像作者这种英语不好的人，居然也看懂了。发生类型转换失败错误时，用户输入的ognl表达式，会被执行掉。这个漏洞好眼熟啊，我们看看这个。

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

真是屡洞屡补啊，这是struts2.0.8时代遗留下来的老问题。当时的修补补丁，作者也看过，也研究过补丁绕过的可能性。

很惭愧，作者没有慧眼识英雄，研究方向错了，没有深究下去，导致丧失良洞啊！当时的漏洞原理，是发生错误的时候，输入了“%{xxxxx}”，就会执行，因为ognl会自动多次翻译（while语句）代码中“%{xxx}”，当做新的一段ognl执行。而官方的修补，是把这个多次翻译的功能，从代码中阉割掉了。当时的作者，就像今天的作者一样，认为“补丁简单，有效”，所以也就没想到，还可以注入攻击。所以，大家看了作者的文章后，千万不要以为作者分析完，就结束了，如果你能坚持再多分析一遍，指不定会有大惊喜，大机缘。

这里会有个关键词，叫做“validate”，struts2的世界里，这个叫做“验证框架”，是struts2的一个自带插件。它的功能，从用户可见的角度上说，是该输入数字的时候输错为字母了，这时会返回原来的页面，显示出一个错误消息，同时显示用户原本输入的内容。

问题就出在“同时显示用户原本输入的内容”里，struts2验证框架，要显示这个内容。

一旦发生了类型转换错误，就会走以下流程：

相关代码第一步，设置ExprOverrides

/struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/validator/validators/RepopulateConversionErrorFieldValidatorSupport.java：181行
 
stack.setExprOverrides(fakeParams);

这个函数放入了一个MAP，map会被后面的代码，作为OGNL执行。

MAP的内容来自代码：

fakeParams.put(fullFieldName, "'" + tmpValue[0] + "'");

很明显看到，这里是用单引号拼接的，可以注入。

tmpValue[0]的值，来自

Object value = conversionErrors.get(fullFieldName);

也就是发生了类型转换错误后，放入错误字段，和错误字段的值。

到了这里，其实并不会执行ognl，只有在有去调用findValue(“”)，并传入相关错误字段名称时，才会执行对应的值内容，也就是被注入的OGNL语句。

什么时候会执行findvalue，并且刚好是find错误字段的value呢？

还得再普及一个知识，潜规则太多了，作者研究时，也发生了很多错误，更新了N遍文章。在条件好公司就是好，当研究成果分析发生错误时，立刻会有各种各样的实际场景，供你实时分析，达到纠正错误的目的。嗯。阿里巴巴招聘安全工程师，果断向我邮箱投简历把，你懂得。

Struts把request的getAttribute方法再次重写，在jsp层调用的request，其实是个struts包装过的，并非原本apache提供的request类。在这个方法里：

attribute = stack.findValue(s);

s是方法传入的参数。也就是说，真正决定执行注入OGNL代码的，是这个方法。

这个方法有多么恐怖啊，我们举几个调用此方法的地方。

1、 jsp中得request.getAttribute(“kxlzx”);

这个感觉还好，调用不多是吧？最起码不如request. getParameter多。虽然大家有用到，但是不多。

2、 struts标签库几乎所有标签，在获取标签value时，都会调用这个方法。

这次够恐怖了，所有标签都会用到value的时候，否则标签意义何在。这个属于框架自动调用，不需要开发人员参与。开发人员只需要使用struts标签库就好。

3、 事实上几乎所有标签库，展现层，几乎都会用这个方法从action中拿用户提交的变量值。

粗略统计一下，包括velocity、freemarker等。

漏洞利用的条件

公告上其实给出了一个经典场景，从漏洞描述上看，这些条件，缺一不可。

1、 使用了struts验证框架做验证。

2、 针对可利用的字段，验证框架做了类型转换验证。

3、 页面使用了struts标签库。

4、 错误页面刚好会显示可利用字段的值。

非常苛刻的利用条件，其实后来证明这是个误区，作者当初在这里被骗了很久。回到刚刚拿到公告时，简要的解析一下条件的苛刻性。这么解析虽然意义不大，但是不可否认，这是开发人员会存在侥幸心理的起始。

使用了struts验证框架做验证

简要说下，不使用struts验证框架的理由。

1） 时代在发展，已经到了web2.0，新时代，大家都知道使用ajax了，输入时候，就已经去验证。

2） 即使是老的时代，很多开发为了偷懒，会使用js验证，而不适用服务端验证，这就避免了还要写服务端代码。当然，有经验的开发，会建议开发使用服务端验证框架，因为这样才“安全”。

3） 验证框架使用起来，其实并不比专门写段代码做验证简单。除非是出于良好的架构考虑，才会要求大家一定要用。

以经验来说，作者做过一段时间的开发，验证框架这个烂东西，能不用，基本上作者不用。

针对可利用的字段，验证框架做了类型转换验证

这个必须是一个int类型，或date类型等等需要类型转换的类型。像email验证、string长度验证，正则表达式验证等等，都不在此列。难以找到一个明明应该用下拉框解决的，非要用户输入数字。很不友好。顺便普及一下，所谓的类型转换错误，就是这个字段本身是一个int类型或date等类型，但是用户输入了一段字母，所以错误了。

页面使用了struts标签库

这也是一个特定条件，众所周知，struts和webwork的标签库，是所有的标签库中，性能最让人抓狂的几个之一。有经验的架构师，通常会用velocity等来替代，实在不行，也会用el表达式加jsp搞定。所以并不是每个页面，都会启用struts标签库。

错误页面刚好会显示可利用字段的值

用户输入错误，很多时候，都是一个错误页面，不一定就要显示出原来用户输入了什么。

个人经验来看，最最难以接受的，就是得找一个让用户输入数字的文本框。是不是很失望呢，这个漏洞，并不像原来的那个，指哪打哪。

利用条件的减免

为了扩大漏洞影响，必须从这四个地方下手，让漏洞出现的几率高一点，容易利用一点。

其他的几点，可能真的不好撬动，但是这“针对可利用的字段，验证框架做了类型转换验证”，经过研究，发现没有想象中的难。有很多开发总抱着侥幸心理：“是不是我的项目不使用验证框架，就没事了”。事实上框架提供的便利，struts框架会自动对所有字段，执行类型转换验证，并不是非要开发人员指定某个action做验证。换句话说，这个条件完全可以消失了。作者写在这里，是因为很多人都会有这个误区，而作者当时也走进了这个误区，所以专门写一下。

也就是说，其实利用条件是：

1、 发生类型转换错误

2、 返回页面会显示错误字段的内容

小小的统计一下，发现会显示错误字段内容的标签，实在太多了，仅仅是struts的标签库里，就可以搜出一大把（并不全）：

<s:text name="kxlzx" />         //输出一段文字
 
<s:property name="kxlzx" />        //输出一段文字
 
<s:textfield name="kxlzx" />        //一个input输入框
 
<s:hidden name="kxlzx" />          //一个隐藏域

以上这些标签，在项目里，不可能不被使用。

换个场景，velocity：

$kxlzx           //输出一段文字

别说你不用这个输出，那你干脆不要用velocity好了。

还有其他场景，不再一一列举，最终得出下图，大家可以对照上文，重新梳理一下流程。

这真的是个好消息，作者一向认为：“默认的不安全，才是最好的不安全”，“如果一个框架漏洞的产生，还需要开发人员冗长的代码配合我们，那是多么的悲催”。这两句很通顺，打算申请个专利。

漏洞特征和批量抓漏洞

这是大家最关心的地方，有很多很多的struts，怎样能够确定，这个系统有漏洞呢。

我们看看showcase的页面

这个地方，是个integer validation，我们输入poc，有经验的能看出来，作者的EXP是经过处理的。这种技巧，不打算多说，后文会给出指引。

原来的地方，变成了

<true>

弹出calc，就是说，ognl被执行了。大家看懂了，得从应用程序中，找每个input，一个一个试，从结果页面，判断漏洞是否存在。

然而，这只是第二步。

第一步当然是找到struts了，为了批量的找到struts，最好的办法就是搜索引擎。“inurl:action”，“filetype:action”都是可以找到struts的。

为了更加精准的找出来，作者还得提到一个struts的特性：“不分GET和POST”。这个就是传说中得潜规则。搜索引擎去抓取的时候，通常是get方式，提交很多参数，有变态的搜索引擎，也会自动提交表单的。如果一个连接，进去后，页面直接报出“Invalid field value”，这基本上，就是struts的框架验证失败了。

别小看这英文的短句，即使是中文的系统，如果没有定义表单验证中得类型转换错误信息，表单中数字等类型，会自动说出验证结果。这个自动说的结果，就是框架提供的默认信息“Invalid field value”。程序员懒得去给类型转换失败，写一条专用的错误信息，也给我们提供了便利。

综合来说，我们搜索“filetype:action Invalid field value”，就能看到N多站了。这些站，基本上都是使用了struts标签库的站。

攻击步骤

再总结一下

1、 找到可以输入的表单，最好有日期类型，数字类型等。

2、 提交表单，修改包，把所有的表单值内容，都改为POC。

3、 查看页面返回源码，如果有POC执行后的返回，就成功了。

实际利用场景

Google搜索结果的第一页，当时真的是一眼定位目标，为什么能一眼定位呢？

因为它“非死不可”！

没错，就是facebook。

遵循这个逻辑，黑掉“非死不可”

http://apps.facebook.com/sparechange/showTopUp.action?senderId=$sc_senderId&devId=$sc_devId&returnUrl=$sc_returnUrl&appId=$sc_appId&item=$sc_item&itemDesc=$sc_itemDesc&t=$sc_amt&

这个页面爆出：

所以提交下面表单

<form action="http://apps.facebook.com/sparechange/showTopUp.action?senderId=$sc_senderId&devId=$sc_devId&returnUrl=$sc_returnUrl&item=$sc_item&itemDesc=$sc_itemDesc&t=$sc_amt&" method="POST">
 
<input name=”appId”>
 
<input type=”submit”>
 
</form>

输入：

查看源码

          <input type="hidden" name="devId" value="$sc_devId" />
 
          <input value="$sc_senderId" name="senderId" type="hidden" />
 
          <input value="&#123;javax.servlet.context.tempdir=/usr/local/tomcat/work/Catalina/localhost/fb, org.apache.catalina.jsp_classpath=/usr/local/tomcat/work/Catalina/localhost/fb/WEB-INF/classes/:/usr/local/tomcat/shared/classes/:/usr/local/tomcat/shared/lib/axis.jar, org.apache.catalina.resources=org.apache.naming.resources.ProxyDirContext&#064;119015b&#125;" name="appId" type="hidden" />
 
          <input value="" name="flowType" type="hidden" />

其实input的value很长很长，这里文中截断了。

触发这个漏洞后，作者也给facebook发了邮件。找安全团队地址时，看到facebook居然有赏金，很开心。但是马上又看到apps下面的应用，不参与悬赏，那个不爽啊，虽然出于职业道德，还是给它发了邮件，真不爽。只能自我安慰一下：“哥邮件里写的英文，你们真的以为能当英文看么？“

从侧面撬动苛刻条件

最后讨论一下“错误页面刚好会显示可利用字段的值”，这一条还是从侧面，可以撬动的。搜索引擎的结果里，很多都是页面上有“Invalid field value”，其实并不会在当前页面展示字段的内容，也就无法触发漏洞了。

当前页面真的无法触发漏洞么？

真的。。。-_-!

别忙泼水，作者要说得是，只是当前页面不会触发而已。出现这个错误，代表了这个系统的开发人员，喜欢struts，喜欢struts的标签库。你懂么？他好这口儿！

我们来看看另一个例子。

这位虽然没有非死不可，但是想百毒不侵，那是没有的。

猜到了？百度！

搜索引擎里看到了一个url：

http://wm123.baidu.com/site/detail.action?siteId=1..

很不爽的页面，这个页面没有input，不会显示它的值，也就不会调用getAttribute。但是它告诉我，百度的开发，使用了struts标签库。

所以，很不幸（当然作者其实觉得很幸运），在另一个地方，找到了想要的东西。提交下面表单

POST http://beidou.baidu.com/tool/addGroupClone.action?task.userid=3701034 HTTP/1.1
 
struts.token.name=groupCloneToken&groupCloneToken=fdasfdsafdsa&list-filter=&sub-list-filter=&task.groupIdList=2201994&task.unitstate=0&task.copyRegion=true&task.copyNetWork=true&task.copyDirectType=true&task.planid=-1&task.newPlan=true&task.planname=fdsafdsafdsa&task.budget=' %2B #application %2B '

就能看到一个令人惊喜的结果。

直接提交是不行的，里面有token，一次验证立刻失效。必须找到页面，在发送到服务器之前，拦截http请求，修改后提交，才能看到结果。

看到这里，大家都会批量抓鸡了。关于执行任意代码的exp怎么写，这个时候当然不会放出来，不然过些天，还有谁会关注我的微薄（http://t.qq.com/javasecurity）呢？想知道的，请把作者之前写过的《Struts2和Webwork远程命令执行漏洞分析》“http://www.inbreak.net/archives/167”，认真读几遍，会有大机缘。作者当时看到漏洞介绍后，1分钟之内，写好了执行任意代码的EXP。只要你懂，你就懂了。

最后插一句，

感谢KJ一起研究

感谢小笨笨（cnben）建议

感谢 寻者 提供各种反驳本文错误分析的实际场景

By kxlzx http://www.inbreak.net

微薄（http://t.qq.com/javasecurity）

建议继续学习：

1. 程序员疫苗：代码注入    (阅读：6779)
2. PHP数据类型隐性转换的陷阱    (阅读：2968)
3. 使用参数化查询防止SQL注入漏洞    (阅读：2768)
4. Android安全–加强版Smali Log注入    (阅读：2781)
5. javascript运算/转换技巧    (阅读：2720)
6. 编写安全代码：再论整数类型转换    (阅读：2639)
7. JavaScript ( (__ = !$ + $)[+$] + ({} + $)[_/_] +({} + $)[_/_] )    (阅读：2596)
8. MySQL防范SQL注入风险    (阅读：2549)
9. struts2框架XSLTResult本地文件代码执行漏洞    (阅读：2450)
10. javascript依赖注入    (阅读：2405)