围观orange大佬在Amazon内部协作系统上实现RCE

阅读量    100798 |   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

(本文作者是orange,以其第一人称叙述。)
这是我在Black Hat USA 2018和DEFCON 26上的案例研究,PPT可在这里下载:
Breaking Parser Logic! Take Your Path Normalization Off and Pop 0days Out
这两年我一直在关注网络安全中的“不一致”的问题。什么叫做“不一致”的问题呢? 打个比方,就像我去年在Black Hat展示的GitHub的由SSRF导致RCE案例中出现的, URL解析器和URL获取器之间的不一致导致整个SSRF绕过!
这里还推荐一篇文章@ 0x09AL,Bypassing Web-Application Firewalls by abusing SSL/TLS ,从中足以看出“不一致”问题的可怕。
所以今年,我开始关注路径解析器和路径规范化中的“不一致”的问题!
编写一款设计良好的解析器很难。因为不同的实体都有着不同的标准和实施方式。一般为了在不影响业务逻辑的情况下来修复错误,都会增加一个过滤器而不是直接给漏洞打补丁。那如果过滤器和被调用方法之间存在任何不一致,就可以轻松绕过安全机制!
在阅读文档说明的时候,我注意到一个叫URL Path Parameter的功能。 一些研究人员早就指出过这个功能可能会导致安全问题,但是是说它仍然取决于编程是否有问题! 画个思维导图,然后我发现这个功能可以完美地应用在多层体系结构上,而且是默认情况下就很容易受到攻击。如果你使用反向代理,并且是Java作为后端服务,那么就危险了!
早先在2015年第一次发现这个攻击面是在一次红队测试中。我觉得这个问题很牛x,想看看有多少人知道,然后就在WCTF 2016中出了一道相关的题目。
不过后来事实证明,没人知道这个问题,因为没有参赛队伍做出这个题。
今年我打算分享这个问题。为了说服审查委员会,我要更多的案例证明它有效!然而在寻找案列的过程中发现这个攻击面不仅可以泄漏信息,还可以绕过ACL(例如优步的OneLogin bypass),并在几个赏金计划中导致RCE。 这篇文章介绍的就是其中之一!
(PPT里有以上的案例说明)
↓多层架构的不一致性!p1

 

前言

首先,感谢亚马逊的漏洞披露计划。与亚马逊安全团队合作感觉特别好(当然Nuxeo团队也是)。

整个故事始于一个域名collaborate-corp.amazon.com,它貌似是一个内部协作系统。 从网页下面的copyright来看,这个系统是用一个开源项目Nuxeo构建的。 它是一个非常庞大的Java项目,起初我就想提高一下Java审计技能。所以就从它开始了。

 

Bugs

我的个人习惯是拿到java源码之后先去看pom.xml,看看有没有引用一些过时的包什么的。在java漏洞里面很多问题都是OWASP Top 10 – A9上列的已知易受攻击的组件,比如Struts2,FastJSON,XStream或具有反序列化问题的组件等等。
Nuxeo的包大部分都是最新的。不过还是有一个“老朋友”——Seam Framework。 Seam是JBoss开发的Web应用程序框架,几年前它是一个相当流行的Web框架,到现在仍有许多基于Seam的应用程序:P

1. 路径规范化错误导致ACL绕过

通过WEB-INF / web.xml查看访问控制时,我发现Nuxeo使用自定义的身份验证过滤器NuxeoAuthenticationFilter并映射/ *。 从过滤器来看大多数页面都需要身份验证,但是有一个白名单,例如login.jsp。这些都是在bypassAuth方法中实现的。p2从上面可以看出来,bypassAuth检索当前请求的页面,与unAuthenticatedURLPrefix进行比较。 但bypassAuth如何检索当前请求的页面? Nuxeo编写了一个从HttpServletRequest.RequestURI中提取请求页面的方法,第一个问题出现在这里!P4为了处理URL路径参数,Nuxeo以分号截断所有尾随部分。 但是URL路径参数是多种多样的。 每个Web服务器都有自己的实现。 Nuxeo的方式在WildFly,JBoss和WebLogic等容器中可能是安全的。 但它在Tomcat下就不行了! 因此getRequestedPage方法和Servlet容器之间的区别会导致安全问题!
根据截断方式,我们可以伪造一个与ACL中的白名单匹配但是到达Servlet中未授权区域的请求!
我们选择login.jsp作为前缀! ACL绕过可能如下所示:p4

如图所示,绕过了重定向进行身份验证,不过大多数页面还是返回500错误。这是因为servlet逻辑无法获得有效的用户原则,因此它会抛出Java NullPointerException。 但这并不影响进一步操作。

附: 虽然有一个更快捷的方式来实现这个目的,不过还是值得写下第一次尝试!

2. 代码重用功能导致部分EL调用

我之前也说到,Seam框架中有许多安全隐患。所以下一步我要做的就是回到第一个问题中去访问未经认证的Seam servlet!

这个部分我将逐一详细解释这些“功能”.
为了控制浏览器应该重定向的位置,Seam引入了一系列HTTP参数,并且在这些HTTP参数中也存在问题… actionOutcome就是其中之一。 2013年,@meder发现了一个远程代码执行漏洞。见CVE-2010-1871:JBoss Seam Framework remote code execution for details!但今天,我们将讨论另一个 – actionMethod!

actionMethod是一个特殊的参数,可以从查询字符串中调用特定的JBoss EL(Expression Language)。这看起来相当危险,但在调用之前有一些先决条件。详细的实现可以在方法callAction中找到。为了调用EL,必须满足以下前提条件:
1.actionMethod的值必须是一对,例如:FILENAME:EL_CODE
2.FILENAME部分必须是context-root下的真实文件
3.文件FILENAME必须包含内容“#{EL_CODE}”(双引号是必需的)

例如:
context-root下有一个名为login.xhtml的文件:
p5

可以通过URL调用EL user.username
p6

3. 双重评估导致EL注入

之前的功能看起来没啥毛病,你无法控制context-root下的任何文件,因此无法在远程服务器上调用任意EL。 然而,还有一个更疯狂的功能:
如果返回一个字符串,并且该字符串看起来像一个EL就糟糕了, Seam框架将再次调用!
p7

请看更细节的调用堆栈信息

1.CallAction(Pages.java)
2.handleOutcome(Pages.java)
3.handleNavigation(SeamNavigationHandler.java)
4.interpolateAndRedirect(FacesManager.java)
5.interpolate(Interpolator.java)
6.interpolateExpressions(Interpolator.java)
7.createValueExpression(Expressions.java)

有了这个功能,如果我们可以控制返回值,我们可以执行任意EL!
这与二进制利用中的ROP(Return-Oriented Programming)非常相似。 所以我们需要找到一个合适的工具!

这里我用的是 widgets/suggest_add_new_directory_entry_iframe.xhtml

p8

为什么选用这个呢?这是因为request.getParameter返回一个我们可以从查询字符串控制的字符串! 虽然整个标记是分配变量,但我们可以滥用语义!
现在将第二阶段payload放在directoryNameForPopup中。 对于第一个bug,我们可以将它们链接在一起以执行任意EL而无需任何身份验证! PoC:p9

虽然我们现在可以执行任意EL,但仍然无法反弹shell。 为什么?继续看。

4. EL黑名单绕过导致RCE

Seam也知道EL的问题。 从Seam 2.2.2.Final开始,用一个EL黑名单来阻止危险的调用! 不幸的是,Nuxeo使用最新版本的Seam(2.3.1.Final),因此必须找到绕过黑名单的方法。 黑名单可以在resources/org/jboss/seam/blacklist.properties中找到。p10

研究一下发现黑名单只是一个简单的字符串匹配,我们都知道黑名单一般都是下下策。 我刚看到这个,就想起了Struts2 S2-020。这两个有相似之处。 使用类似数组的运算符来处理黑名单模式:

"".getClass().forName("java.lang.Runtime")

改成

""["class"].forName("java.lang.Runtime")

最后,在JBoss EL中编写shellcode。 我们使用Java反射API来获取java.lang.Runtime对象,并列出所有方法。 getRuntime()返回Runtime实例,exec(String)执行我们的命令!

最后总结一下所有所有步骤并将它们连在一起利用:

1.路径规范化错误导致ACL绕过
2.绕过白名单访问未经授权的Seam servlet
3.使用Seam功能actionMethod调用文件中的小工具suggest_add_new_directory_entry_iframe.xhtml
4.在HTTP参数directoryNameForPopup中准备第二阶段payload
5.使用类似数组的运算符绕过EL黑名单
6.使用Java反射API编写shellcode
7.坐等shell

这是整个漏洞利用:
p12

通过执行perl脚本,成功反弹shell:
p14

 

修复

修复分为三块:

1. JPBoos

最麻烦的是Seam框架。 我已于2016年9月向security@jboss.org报告了这些问题。但他们的回复是:
p15

由于EOL这些问题似乎没有官方补丁。 但是,许多Seam应用程序仍然被广为使用。 所以如果你使用Seam。 建议你用Nuxeo的方案来缓解这个问题。

2. Amazon

亚马逊安全团队隔离了服务器,与报告者讨论了如何解决,并列出了他们采取的方案! 与他们合作是一个很好的经历:)

3. Nuxeo

在亚马逊发出通知后,Nuxeo迅速发布了8.10版的补丁。 补丁重写了方法callAction()! 如果需要Seam的补丁,可以在这里下载
时间线
2018年3月10日01:13 GMT + 8通过aws-security@amazon.com向亚马逊安全团队报告
2018年3月10日01:38 GMT + 8收到回复他们正在调查
2018年3月10日03:12 GMT + 8要求我参加安全团队的电话会议
2018年3月10日05:30 GMT + 8与亚马逊召开电话会议,了解他们为此漏洞采取的措施
2018年3月10日16:05 GMT + 8询问是否可以公开披露
2018年3月15日04:58 GMT + 8 Nuxeo发布了新版本8.10,修补了RCE漏洞
2018年3月15日23:00 GMT+8 与亚马逊召开电话会议,了解情况并讨论公开细节
2018年4月 5日05:40 GMT + 8获得亚马逊奖金

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多