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

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

(本文作者是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里有以上的案例说明)

↓多层架构的不一致性
围观orange大佬在Amazon内部协作系统上实现RCE

前言

首先,感谢亚马逊的漏洞披露计划。与亚马逊安全团队合作感觉特别好(当然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方法中实现的。
围观orange大佬在Amazon内部协作系统上实现RCE 从上面可以看出来,bypassAuth检索当前请求的页面,与unAuthenticatedURLPrefix进行比较。 但bypassAuth如何检索当前请求的页面? Nuxeo编写了一个从HttpServletRequest.RequestURI中提取请求页面的方法,第一个问题出现在这里!
围观orange大佬在Amazon内部协作系统上实现RCE

为了处理URL路径参数,Nuxeo以分号截断所有尾随部分。 但是URL路径参数是多种多样的。 每个Web服务器都有自己的实现。 Nuxeo的方式在WildFly,JBoss和WebLogic等容器中可能是安全的。 但它在Tomcat下就不行了! 因此getRequestedPage方法和Servlet容器之间的区别会导致安全问题!

根据截断方式,我们可以伪造一个与ACL中的白名单匹配但是到达Servlet中未授权区域的请求!

我们选择login.jsp作为前缀! ACL绕过可能如下所示:
围观orange大佬在Amazon内部协作系统上实现RCE

如图所示,绕过了重定向进行身份验证,不过大多数页面还是返回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的文件:

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

可以通过URL调用EL user.username

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

3. 双重评估导致EL注入

之前的功能看起来没啥毛病,你无法控制context-root下的任何文件,因此无法在远程服务器上调用任意EL。 然而,还有一个更疯狂的功能:

如果返回一个字符串,并且该字符串看起来像一个EL就糟糕了, Seam框架将再次调用!

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

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

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

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

为什么选用这个呢?这是因为request.getParameter返回一个我们可以从查询字符串控制的字符串! 虽然整个标记是分配变量,但我们可以滥用语义!

现在将第二阶段payload放在directoryNameForPopup中。 对于第一个bug,我们可以将它们链接在一起以执行任意EL而无需任何身份验证! PoC:
围观orange大佬在Amazon内部协作系统上实现RCE

虽然我们现在可以执行任意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 中找到。 围观orange大佬在Amazon内部协作系统上实现RCE

研究一下发现黑名单只是一个简单的字符串匹配,我们都知道黑名单一般都是下下策。 我刚看到这个,就想起了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

这是整个漏洞利用:

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

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

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

修复

修复分为三块:

1. JPBoos

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

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

由于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获得亚马逊奖金

原文 

https://www.anquanke.com/post/id/156078

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 围观orange大佬在Amazon内部协作系统上实现RCE

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址