作者:0xcc
原文链接:https://mp.weixin.qq.com/s/TrSb4hMD6QUVyCth3IaBbg

这篇文章是上一次 realworld ctf 论坛上的议题《Bifr?st 揭秘:VMware Fusion REST API 漏洞分析》。本来去年这时候就该动笔写一下,正好当时 InfiltrateCon 的主办方看到了这个议题,邀请了投稿,我就想着讲完再写。没料到四月份的会议因为疫情一直拖到现在,最后只能改成线上。

http://infiltratecon.com/conference/briefings/bifrost-demystified-case-study-of-a-vmware-fusion-rce.html

VMware Fusion 在去五月修复了这个编号为 CVE-2019-5514 漏洞。与常规的虚拟机安全问题,即通过 guest 攻击 host 的方式不同,这是一个远程代码执行漏洞。它从 host 的浏览器远程触发,在 guest 里执行任意代码。PoC 极度简单,却需要花不少功夫逆向才能分析明白。

图片

除此之外我还(重新)发现了一种特殊配置下,不需要漏洞即可逃逸至 host 执行任意命令的方法。RWCTF 举办时还在和厂商沟通,所以我保留了这一部分没讲。这两部分串联起来之后,便是一个完整的 RCE 链条。 VM Fusion 11 引入了一个新功能,在 mac 桌面右上角添加了一个快捷菜单,可以操作虚拟机的开关机、快照等状态。当 guest 是 Windows 系统时,甚至可以将其“开始”菜单映射出来,在客户机里直接运行(任意?)程序。

这个功能引起了我的注意,事实上也找到了严重的问题。

经过简单的分析发现,这个菜单界面是一个 Electron 应用。而在后台有一个 go 语言 amsrv 进程开启了一个 HTTP 服务,通过 WebSocket 和 HTTP 协议与 Electron 界面通信,然后再由 amsrv 作为代理的角色操纵 VMware Fusion 剩余的组件。这个 http 服务的架构有些多余,毕竟 Electron 本身可以实现很多 native 的功能。笔者估计是因为 nodejs 嵌入 C 的库比 go 麻烦。

图片

问题出在 HTTP 和 WebSocket 的鉴权上。开发者应该是认为 localhost 的应用没有做访问控制的必要,然而 WebSocket 默认支持跨域访问,也就是任何一个浏览器都可以与之通信。更神奇的是 HTTP 协议的部分还开启了 CORS,不限制请求来源。简单复现一下弹计算器的命令,然后在 Wireshark 对 loopback 抓包,便得到了一个 PoC:

const ws = new WebSocket(`ws://127.0.0.1:8698/ws`)
ws.onopen = () => {
  ws.send(JSON.stringify({
    name: 'menu.onAction',
    object: '11 22 33 44 55 66 77 88-99 aa bb cc dd ee ff 00',
    userInfo: {
      action: 'launchGuestApp:',
      vmUUID: '11 22 33 44 55 66 77 88-99 aa bb cc dd ee ff 00',
      representedObject: 'calculator:'
    }
  }))
}
ws.onmessage = msg => {
  console.log(JSON.parse(msg.data))
  ws.close()
}

显然,其中的 vmUUID 字段是虚拟机的唯一标识符。但经过一番分析发现,这个字段保存在本地的一个 plist 文件里,Electron 通过解析对应的文件获取,而远程攻击者自然没有这个条件。这个格式也不能被简单的爆破。这个漏洞似乎不能利用,加上我一开始对逆向 go 没有耐心,于是就在网上公开了。

然而一段时间过后,我突然收到一条国外网友的私信说,他找到了利用的方法,让我非常震惊。

图片

https://theevilbit.github.io/posts/vmware_fusion_11_guest_vm_rce_cve-2019-5514/

他在 WebSocket 协议里找到了一个隐藏的参数 selectedIndex,可以完全取代 vmUUID。这个整型的参数可以遍历,有微博网友称,测试时把自己所有的虚拟机全部打开挨个弹了一遍 cmd,当场大惊失色。

这件事说明,为了负责任地披露,在完全搞清楚一个漏洞的可利用性之前,不要随便地公开讨论。

这也勾起了我的好奇心,于是我把手上的 binary 又打开梳理了一遍。

Redress 工具简单查看了一下 amsrv,其实这个程序并不是真正的服务端,而是一个类似守护进程的角色。服务端实现是在另一个叫 vmrest 的程序。在 VMware 官网上可以找到这个 vmrest 的文档,标题叫《Use the VMware Workstation Pro REST API Service》。但这个程序的帮助信息里却提示有一个 -D 的命令开关可以以 internal 模式运行,说明事情没这么简单。

Redress 提示这个程序用到了 web 框架 gorilla。以此为线索搜索 github_com_gorilla_mux__Router_HandleFunc 的交叉引用,找到了所有的后端 API 接口:

图片

WebSocket 后端的处理非常简单,在对 JSON 内容进行一些解码和重新序列化的操作和,几乎远洋通过 Mach Message 转发给下一个进程,也就是 VMware Fusion 主界面。我写了一端简单的 frida 脚本拦截 CFMessagePortSendRequest 函数调用,打印所有的进程间消息,也证实了这一点。

这一阶段的进程间通信主要靠 VMIPCServer 和 VMIPCClient 类实现。顾名思义,这一对 class 借鉴了 client/server 的角色,封装了基于消息的接口。在消息接收端有一个 VMIPCCommon 单例,其中的 observerTable 注册了所有的消息接收端。这是一个 NSDictionary 键值对,key 是指向具体 handler 类实例的指针,值则是一个 VMIPCObserverEntry 对象,记录了 WebSocket 协议当中的 name 字段和具体 handler 类处理方法的 selector 的对应关系:

图片

回到弹计算器的 PoC 上。根据 observerTable 的映射关系,这个消息会触发 -[PLVMStartMenuProxy onMenuAction:] 方法。最终消息来到 -[PLVMStartMenuManager onStartMenuPerformAction:withInfo:],在这个函数里居然是优先检查 selectedIndex 参数,如果不存在,再尝试将另一个可选的 vmUUID 参数转换成 selectedIndex。这也就解释了一开始被我漏掉的 PoC 的现象。而为了搞清楚这一步,我们已经逆了至少三个程序。

@interface DUIVMActionController : DUIActionController <DUISettingsCDROMOpenPanelDelegate>
- (void)togglePause:(id)arg1;
- (void)installVirtualPrinter:(id)arg1;
- (void)toggleToolsInstall:(id)arg1;
- (void)onSendKey:(id)arg1;
- (void)sendCtrlAltDel:(id)arg1;
...

除了启动客户机程序之外,以上的方法也是对 WebSocket 开放的。

接下来便是主界面和 vmx 进程的通信。VMware Fusion 的每一个虚拟机都用一个独立的 vmx 进程执行,即使界面崩溃了,也不会影响到 vmx 的稳定性;反之亦然。

这个阶段的通信使用一个叫 vmdb 的机制。

这是一个类似键值对数据库的集中化状态管理,既支持数据的存储也提供跨进程传递数据的能力。一个 key 类似文件系统的路径,类似这样的字符串:

vmx/vigor/ields/Audio/

vmdb 支持的基本数据类型有整形、字符串、二进制等。既然叫做 db,它还提供了类似 SQL 的查询机制,但实际上只支持 SELECT WHERE 语句。首先用 Vmdb_ParseQuery 从“SQL”创建一个查询,接着用 Vmdb_ExecuteQuery 函数执行,并用 Vmdb_NextResult 遍历结果集。这个 db 还支持事件处理,可以用 Vmdb_RegisterCallback 在特定的键上添加监听函数处理状态变化。

与常见的虚拟机漏洞不同,这一次攻击载荷是反向传递的——从 host 到 guest。常规的漏洞利用一个叫 RPCI 的“后门”通信接口来调用宿主的功能,而与之对等的是 TCLO。两者其实区别不大,仅仅是 Message_Open 时传入的 magic number 不同。命令的格式也是函数名、空格,然后紧跟参数的 buffer。

在 Windows 上,VMware Tools 有两个进程,一个具有 SYSTEM 权限,一个普通用户权限。用来弹计算器的命令叫做 unity.shell.open,最后来到 GHIPlatformShellCommandRun 函数。

这个函数并不完全等同于 ShellExecute,它还内置了一些特殊 URL 的处理。

  • x-vmware-share:// 打开共享目录
  • x-vmware-menuitem://{computer,documents,network,control-panel,printers,search,run} 开始菜单
  • x-vmware-metroapp-execpath:// 执行 UWP 应用

如果字符串不满足以上 URL,就会进入这个分支。只有命令包含一个“.”符号,才会触发支持命令行参数的逻辑:

图片

比如 cmd /c calc 必须写成 cmd.exe /c calc,否则没有反应。这时候可以使用 Powershell 下载逃逸的 payload 完成整个链路。

对于非 Windows 虚拟机,例如 Linux,unity.shell.open 早在 2008 年的一个 commit 便被移除掉了。不过前文提到,有一个命令可以模拟键盘输入,而且这个命令并不需要客户机上安装了 VMTools。这就是 onSendKey: 方法。在 guest 没有被锁屏的情况下,仍然可以通过模拟按键的方式打开终端,回车执行任意命令。

官方在 2019 年五月初推出的 11.0.3 修复了这个问题,在 HTTP 协议中加入了随机 token 的验证;而 WebSocket 则要求 Origin: 满足 file:// 域。

在 VMware 的安全公告 VMSA-2019-0005 当中, 除了这个严重级别的远程代码执行,还有 Pwn2Own 2019 上 Fluoroacetate 用到的几个 VMware Workstation 逃逸漏洞,同样影响 Fusion。

此外在逆向 VMTools 时,我重新发现了一个已经被公开讨论过的特性,可以在特殊的虚拟机配置环境下无需漏洞逃逸到宿主机。

图片

一旦勾选了这个“在 Mac 打开 Windows 的文件和链接”,便可使用 VMTool 内置的 VMwareHostOpen.exe 调用这一功能。这个选项显然极大削弱了 guest 和宿主之间的隔离性。经过一番搜索我发现 ZDI 在 2017 年已经在 DerbyCon 上公开讲过,只不过没有分析实现细节。

这个命令会转化成一条 RPCI 命令 ghi.guest.shell.action,参数为序列化的 xdr_GHIShellAction。它一共有两个成员,actionURI 永远是 x-vmware-action:///run,而 targetURI 则是希望打开的地址。

在这个函数里特别针对 file:/// 做了过滤,不做任何操作,有可能是为了安全考虑。但其他任意的 URL,例如 dict:// 是允许的。当 URL 的 sheme 是 x-vmware-share:// 时,会转换为宿主的地址,然后打开对应文件。

在客户机开启了任意一个可写的共享目录之后,攻击载荷可以写入一个可执行文件(例如 .command),内容是一个 shell 脚本。由于 HGFS 需要尽可能消除不同操作系统下的表现差异,在 mac 端默认便给足文件权限,包括可执行。这时候相当于宿主机双击打开文件,便会触发脚本命令。这便有了我们开头的动画。

$name = "calc.command";$writable = ls "\\vmware-host\Shared Folders" | Where-Object { $acl = Get-Acl $_.FullName; $acl.Access | Where-Object { $_.IdentityReference -eq 'Everyone' }} | Select-Object -first 1;
$output = Join-Path $writable.FullName -ChildPath $name;
$content = '#!/bin/sh
open -a Calculator
killall Terminal'
[IO.File]::WriteAllLines($output, $content);
& "C:\Program Files\VMware\VMware Tools\VMwareHostOpen.exe" "--url" "x-vmware-share://$($writable.Name)/$($name)";

VMware 官方认为这不是一个安全问题,毕竟需要两个条件:

1.允许打开 URL

2.开启至少一个可写的共享目录

然而我们再想一想,这两个条件都和虚拟机本身的配置有关。仍然有一种场景存在风险,那就是从网上下载一个虚拟机镜像然后双击启动——所有的配置自然都是攻击者可控的。

通过这个案例的分析可以看到,炫酷的 Web 技术虽然极大提升了开发效率,却把本不该出现的安全问题引入到桌面端产品中。VMware 一个看上去很小的功能却分了很多层次的调用,结构复杂却能保证架构的清晰。当然最大的教训还是,在确保分析完全之前不要随便低估一个漏洞的可利用性。


Paper 本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/1550/