再次攻破Facebook！MobileIron MDM未授权远程代码执行漏洞分析

本文详细分析了MobileIron MDM中的未授权远程代码执行漏洞，包括漏洞发现、利用链构造、JNDI注入绕过技术，以及如何成功在Facebook服务器上实现RCE的全过程。

再次攻破Facebook！MobileIron MDM未授权远程代码执行漏洞分析

作者：Orange Tsai
本文是DEVCORE的交叉发布博客。中文版请参阅这里

嗨，距离上一篇文章已经很久了。这篇新文章是关于我今年三月的研究，讲述了如何在一个领先的移动设备管理（MDM）产品中发现漏洞，并绕过多个限制实现未授权远程代码执行（RCE）。所有漏洞已报告给供应商，并在六月修复。之后，我们持续监控大公司以跟踪整体修复进度，发现Facebook超过两周未应用补丁，因此我们在Facebook上获取了shell并报告了他们的漏洞赏金计划！

这项研究也在HITCON 2020上展示。你可以查看幻灯片。

背景

作为红队成员，我们一直在寻找从外部渗透企业网络的新路径。就像去年在Black Hat USA上的研究一样，我们展示了如何破解领先的SSL VPN并将其变成你的虚拟“公共”网络！SSL VPN被信任为安全，并被认为是访问私有网络的唯一方式。但是，如果你信任的设备不安全呢？

基于这个场景，我们想探索企业安全的新攻击面，并对MDM产生了兴趣，因此有了这篇文章！

什么是MDM？

移动设备管理（MDM）是一种资产评估系统，使企业的员工自带设备（BYOD）更易管理。它于2012年提出，以应对平板电脑和移动设备数量的增长。MDM可以保证设备在公司策略和可信环境中运行。企业可以管理资产、安装证书、部署应用程序，甚至远程锁定/擦除设备以防止数据泄露。

统一端点管理（UEM）是一个与MDM相关的较新术语，对托管设备有更广泛的定义。以下我们使用MDM代表类似产品！

我们的目标

MDM作为一个集中式系统，可以管理和控制所有员工的设备。对于成长中的公司来说，它无疑是一个理想的资产评估系统。此外，MDM必须公开可访问以同步全球设备。一个集中且公开暴露的设备，对黑客来说还有什么比这更吸引人的呢？

因此，我们看到黑客和APT组织在这些年滥用MDM！例如，钓鱼受害者使MDM成为其移动设备的C&C服务器，甚至破坏企业暴露的MDM服务器以向所有设备推送恶意木马。你可以阅读Cisco Talos团队的报告[恶意MDM：让我们隐藏这个应用](Malicious MDM: Let’s Hide This App)和CheckPoint CPR团队的[首次在野外发现 - 恶意软件使用企业MDM作为攻击向量](First seen in the wild - Malware uses Corporate MDM as attack vector)了解更多细节！

从以前的案例中，我们知道MDM是黑客的坚实目标，我们想对其进行研究。有几种MDM解决方案，甚至微软、IBM和苹果等著名公司都有自己的MDM解决方案。我们应该从哪一个开始？

我们列出了已知的MDM解决方案，并扫描了互联网上的相应模式。我们发现最流行的MDM是VMware AirWatch和MobileIron！

那么，为什么我们选择MobileIron作为目标？根据其官方网站，超过20,000家企业选择MobileIron作为其MDM解决方案，并且我们的大多数客户也在使用它。我们还知道Facebook自2016年以来就暴露了MobileIron服务器。我们分析了财富全球500强，发现超过15%使用并将其MobileIron服务器公开暴露！由于以上原因，它成为我们的主要目标！

从哪里开始

从过去的漏洞中，我们了解到没有太多研究人员深入研究MobileIron。也许攻击向量仍然未知。但我们怀疑主要原因是固件太难获取。在研究设备时，将纯黑盒测试转为灰盒或白盒测试至关重要。我们花了大量时间在互联网上搜索各种信息，最终找到了一个RPM包。这个RPM文件应该是开发者的测试包。该文件只是放在一个可列表的WebRoot中，并被Google搜索索引。

无论如何，我们得到了一个文件进行研究。该文件的发布日期是2018年初。看起来有点旧，但总比没有好！

发现漏洞

经过一段痛苦的时间解决依赖地狱后，我们终于设置了测试包。该组件基于Java，并暴露三个端口：

  • 443 - 用户注册接口
  • 8443 - 设备管理接口
  • 9997 - MobileIron设备同步协议（MI协议）

所有打开的端口都经过TLS加密。Apache位于Web部分的前端，并将所有连接代理到后端，一个带有Spring MVC的Tomcat。

由于Spring MVC，很难从单一视图找到传统漏洞，如SQL注入或XSS。因此，检查逻辑和架构是我们这次的目标！

谈到漏洞，根本原因很简单。Tomcat暴露了一个Web服务，该服务使用Hessian格式反序列化用户输入。然而，这并不意味着我们可以为所欲为！本文的主要努力是解决这个问题，请参见下面的利用部分。

尽管我们知道Web服务反序列化用户输入，但我们无法触发它。端点位于两个位置：

  • 用户注册接口 - https://mobileiron/mifs/services/
  • 管理接口 - https://mobileiron:8443/mics/services/

我们只能通过管理接口触及反序列化，因为用户接口阻止了Web服务访问。这对我们来说是一个关键打击，因为大多数企业不会将其管理接口暴露给互联网，而仅限管理的漏洞对我们没有用处，因此我们必须更加努力。:(

仔细检查架构后，我们发现Apache通过重写规则阻止了我们的访问。看起来不错，对吧？

1
2

RewriteRule ^/mifs/services/(.*)$ https://%{SERVER_NAME}:8443/mifs/services/$1 [R=307,L]
RewriteRule ^/mifs/services [F]

MobileIron依赖Apache重写规则来阻止所有对Web服务的访问。它位于反向代理架构的前端，后端是一个基于Java的Web服务器。
你回忆起什么了吗？

是的，解析逻辑突破！这是我在2015年提出的反向代理攻击面，并在Black Hat USA 2018上展示。该技术利用Apache和Tomcat之间的不一致来绕过ACL控制并重新访问Web服务。顺便说一句，这种优秀技术也应用于最近的F5 BIG-IP TMUI RCE漏洞！

1

https://mobileiron/mifs/.;/services/someService

利用漏洞

好的，现在我们可以访问反序列化，无论它在注册接口还是管理接口上。让我们回到利用部分！

Moritz Bechler有一个很棒的研究，在他的白皮书[Java Unmarshaller Security](Java Unmarshaller Security)中总结了Hessian反序列化漏洞。从[marshalsec源代码](marshalsec source code)中，我们了解到Hessian反序列化在重构HashMap时触发equals()和hashcode()。它也可以通过XString触发toString()，目前已知的利用小工具包括：

  • Apache XBean
  • Caucho Resin
  • Spring AOP
  • ROME EqualsBean/ToStringBean

在我们的环境中，我们只能触发Spring AOP小工具链并获得JNDI注入。

名称 效果
x Apache XBean
x Caucho Resin
√ Spring AOP
x ROME EqualsBean

一旦我们有了JNDI注入，利用的其余部分就很容易了！我们可以利用Alvaro Muñoz和Oleksandr Mirosh在Black Hat USA 2016上的工作[JNDI/LDAP到远程代码执行梦想之旅](A Journey From JNDI/LDAP to Remote Code Execution Dream Land)来获得代码执行……这是真的吗？

自从Alvaro Muñoz和Oleksandr Mirosh在Black Hat上介绍这个技术以来，我们可以说这个技术帮助了无数安全研究人员，并将Java反序列化漏洞带入了一个新时代。然而，Java最终在2018年10月缓解了最后一个JNDI/LDAP难题。之后，所有高于8u181、7u191和6u201的Java版本都无法再通过JNDI远程URL类加载获得代码执行。因此，如果我们在最新的MobileIron上利用Hessian反序列化，我们必须面对这个问题！

Java将com.sun.jndi.ldap.object.trustURLCodebase的默认值更改为False，以防止攻击者下载远程URL类以获得代码执行。但只有这个被禁止了。我们仍然可以操纵JNDI并将命名引用重定向到本地Java类！

这个概念有点类似于返回导向编程（ROP），利用本地现有的Java类进行进一步利用。你可以参考Michael Stepankin在2019年初的文章[利用Java中的JNDI注入](Exploiting JNDI Injections in Java)了解细节。它描述了后JNDI利用的攻击，以及如何滥用Tomcat的BeanFactory来填充ELProcessor小工具以获得代码执行。基于这个概念，研究人员Welkin还在Groovy上提供了另一个ParseClass小工具。正如他的（中文）文章所述：

除了javax.el.ELProcessor，当然也还有很多其他的类符合条件可以作为beanClass注入到BeanFactory中实现利用。举个例子，如果目标机器classpath中有groovy的库，则可以结合之前Orange师傅发过的Jenkins的漏洞实现利用

看起来我先前Jenkins研究中的元编程利用也可以在这里使用。它让元编程再次伟大起来：D

这种方法很棒，看起来对我们可行。但由于目标库过时，ELProcessor和ParseClass两个小工具都不可用。Tomcat从8.5开始引入ELProcessor，但我们的目标是7。至于Groovy小工具，目标Groovy版本太旧（2008年的1.5.6）无法支持元编程，因此我们仍然必须自己找到一个新的小工具。我们最终在GroovyShell上找到了一个新的小工具。如果你感兴趣，可以查看我发送给[JNDI-Injection-Bypass项目](JNDI-Injection-Bypass project)的拉取请求！

攻击Facebook

现在，我们通过链式利用JNDI注入、Tomcat BeanFactory和GroovyShell获得了完美的RCE。是时候攻击Facebook了！
如前所述，我们知道Facebook自2016年以来使用MobileIron。尽管服务器的索引响应现在是403 Forbidden，但Web服务仍然可访问！

一切准备就绪，等待我们的利用！然而，在我们计划攻击的前几天，我们意识到我们的利用存在一个关键问题。从我们上次在Facebook上获取shell的经验中，我们注意到由于安全考虑，它阻止了出站连接。出站连接对JNDI注入至关重要，因为想法是让受害者连接到恶意服务器以进行进一步利用。但现在，我们甚至无法建立出站连接，更不用说其他了。

到目前为止，JNDI注入的所有攻击面都已关闭，我们别无选择，只能回到Hessian反序列化。但由于缺乏可用的小工具，我们必须自己发现一个新的！

在发现新小工具之前，我们必须正确理解现有小工具的根本原因。重读Moritz Bechler的论文后，某个词引起了我的兴趣：

无法恢复Groovy的MethodClosure，因为调用了readResolve()并抛出异常。

一个问题迅速浮现在我的脑海中：作者为什么在这里留下这个词？尽管它因异常而失败，但一定有什么特别之处，所以作者写下了这个。

我们的目标运行着一个非常旧的Groovy，因此我们猜测readResolve()约束可能尚未应用于代码库！我们比较了最新版本和1.5.6之间的文件groovy/runtime/MethodClosure.java。

1
2
3
4
5
6
7
8

$ diff 1_5_6/MethodClosure.java 3_0_4/MethodClosure.java

>     private Object readResolve() {
>         if (ALLOW_RESOLVE) {
>             return this;
>         }
>         throw new UnsupportedOperationException();
>     }

是的，我们是对的。Groovy 1.5.6中没有ALLOW_RESOLVE，我们后来了解到CVE-2015-3253就是为了这个。这是对2015年兴起的Java反序列化漏洞的缓解。由于Groovy是一个内部使用的库，如果没有紧急情况，开发人员不会更新它。过时的Groovy也可以作为一个很好的案例研究，展示一个无害的组件如何让你被入侵！

当然，我们最终在Facebook上获得了shell。这是视频：

[视频链接]

漏洞报告和补丁

我们在三月完成了所有研究，并于4月3日向MobileIron发送了咨询。MobileIron于6月15日发布了补丁，并为此分配了三个CVE。你可以查看[官方网站](official website)了解细节！

  • CVE-2020-15505 - 远程代码执行
  • CVE-2020-15506 - 认证绕过
  • CVE-2020-15507 - 任意文件读取

补丁发布后，我们开始监控互联网以跟踪整体修复进度。这里我们检查静态文件上的Last-Modified头，因此结果仅供参考。（未知代表服务器关闭了443和8443端口）

同时，我们也密切关注Facebook。在确认15天未打补丁后，我们最终在7月2日获取了shell并报告了他们的漏洞赏金计划！

结论

到目前为止，我们展示了在MobileIron上的完全未授权RCE。从如何获取固件、发现漏洞，到绕过JNDI缓解和网络限制。还有其他故事，但由于时间关系，我们只在这里列出了感兴趣的主题：

  • 如何从MDM接管员工设备
  • 反汇编MI协议
  • 以及CVE-2020-15506，一个有趣的认证绕过

我希望这篇文章能引起对MDM和企业安全重要性的关注！感谢阅读。:D

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次