0×01 前言
CVE-2015-5090是存在于Adobe Reader/Acrobat Pro中的一个bug,并且早在几个月前就已经被发现并提交至ZDI了。本文主要是讲这个bug的细节,并分享几种不同攻击方法。
AdobeARMService是Adobe的更新程序,是在Adobe Reader/Acrobat Pro安装程序上安装的系统服务。这个服务在注册表中创建了启动服务的控制管理,从而允许服务处理外部的控制请求。请求调度程序处理当前传进来的服务请求代码并合理分配请求;这些更新的程序或者armsvc有八个相关的函数允许从没有特权的触发,更多关于服务控制的信息可以 看这里
0×02 漏洞说明
Bug开始的服务代码为0x000000AB,或者是SHAREDMEMOTY_CREATE(故意拼错)。一旦服务接受了这个控制请求,这个请求将会进入函数CreateSharedMemory,这个函数将会创建一个权限较低且可预知名字的内存共享文件。安全描述如下:
这个共享的内存句柄为Global/{E8F34725-3471-4506-B28B-47145817B1AE}_,在C驱动的一系列数字和硬编码的字符串thsnYaViMRAeBoda之后。很简单就能够动态生成。一旦我们触发这个共享内存对象产生,任何系统中的进程都可以对它进行读/写。这个意味着什么?
0×03 利用方式一
当这个触发的时候,另外一个服务控制代码0x000000B4,或者是ELEVATE_ARM,从这个共享内存文件中读取信息。ELEVATE_ARM实际上是解析SM中的数据,随后通过ShellExecuteExW函数将结果作为命令行参数传递给AdobeARMHelper.exe。这就允许我们通过启动armsvc来传递一些受限的任意数据标志进入AdobeARMHelper.exe程序。之所以说是受限的任意数据是由于存在解析逻辑,大概就是一些类似wcsstr函数扫描出来的一些不重要的数据,并将其拷贝出来。
AdobeARMHelper.exe是一个比较简单的程序,本质上来说就是更新服务功能引导程序,包括优先权设置、PDF使用者名字,以及注册的变化。如果这个程序接收到/svc或者/ArmService的标志,随即调用ProcessRequestFromArmService函数,这个函数将会检查/ArmUpdate标志。
如果存在这个标志,将会进入ProcessARMUpdateRequest函数,这是一个庞大的自我更新机制并且未装failsafes,而这个函数真正有用的功能也就是它的自动更新机制。命令行传递一个标志,将会在指定的文件夹下找到第一个文件,校验它的数字签名,然后将它复制到C:/Program Files (x86)/Common Files/Adobe/ARM/1.0下。
作为一个例子,我们将如下信息写进共享内存中:
FOLDER:"C:/Windows/Temp/AdobeTEST/" /ArmUpdate
Armsvc将上述解析结果传入这里:
FOLDER:"C:/Windows/Temp/AdobeTEST/" /Svc /USER:/ArmUpdate /SESSIONID:0
AdobeARMHelper.exe随即尝试将目录C:/Windows/Temp/AdobeTEST/第一个被Adobe标记的文件拷贝到AdobeARM 和AdobeARMHelper所在的目录下。这道程序不会试图验证文件名及其扩展名,因此我们可以将一个Adobe标记的任意二进制程序命名为AdobeARM.exe,随后强制armsvc重写AdobeARM.exe的可执行程序。这样我们再触发ELEVATE_ARM服务,让它执行我们自己拷贝过去的具有任何命令行的标志的二进制程序。
这个是关键点,就像ZDI所演示的通过JavaScript bypass sandbox那样。通过使用Adobe Reader的二进制程序来重写AdobeARM.exe,他们可以强制加载一个恶意的PDF文件,接着利用Adobe Reader中的JavaScript API和sandbox逃逸手段向本地目录中释放一个DLL文件。这是基于逻辑bug的一个很棒的例子。
0×04 方式二
我们找到第二种方法利用这个漏洞,这种方法不是通过释放PDF文件,而是通过其他更有意思的方法。adl.exe,或者叫做Adobe AIR调试启动器,这是Reader的一个打包工具,用来运行或者调试AIR应用程序的。它是一个Adobe标记的二进制程序,允许我们指定远程运行时目录,这个目录可以用来加载恶意的DLL文件。类似这样:/adl.exe -run c:/windows/temp/airtmp
启动后,将会尝试加载C:/Windows/Temp/airtmp/Adobe AIR/Versions/1.0/Adobe AIR.dll。相当简单,然而不幸的是,AdobeARMHelper.exe的数字证书检查相当特殊且讨厌。adl.exe是这样标记的:
Thumbprint Subject ---------- ------- A2D24C4708488FE490310CEF7AC667A71921D635 CN=Adobe Systems Incorporated, OU=Universal Client, OU=Digital ID Class 3 ...
而AcroRdr32.exe是这样的:
Thumbprint Subject ---------- ------- 45548B92B80CB79A7C628B83D9DBA37B9C86971D CN="Adobe Systems, Incorporated", OU=Acrobat DC, O="Adobe Systems, Incorpo...
这看起来像是Adobe自己把自己的名字给拼错了,这个校验很明显是在AdobeARMHelper代码中,在这里比较签名证书的名字:
这个相当讨厌。深入Abode的二进制程序后发现CN的引号和逗号在Reader/Acrobat内部是被最先使用的,因此这部分的研究不再深入了。
0×05 方式三
当二进制程序被捕捉到了之后,我们想到第三种方法利用这个漏洞,不需要一个单独的二进制程序。这里使用Forshaw的NTLM reflection(https://code.google.com/p/google-security-research/issues/detail?id=222) POC,之后就像ZDI的folks所做的那样强制AdobeARM打开一个PDF文件,但是传入一个UNC的路径而不是一个本地攻击者控制的系统。使用这个来作为上述哈希值的一个折衷,但是使用Forshaw的方法,我们可以通过Adobe更新程序提升权限而不是Windows防护。这将允许我们直接有特权访问一个本地的WebDAV服务甚至一个代理服务器的NTLM会话。
0×06 方式四
最后,在不需要单独的二进制程序或者Windows的特定载体情况下,我们又找到了另外一种方法利用这个bug。Adobe提供的企业版工具包(ETK)里包含了各种各样的工具用于管理和调度Adobe Reader。Acrobat Pro DC实际上就是使用ETK其中一个叫做引导部署的工具来更新和打补丁。这个工具,setup.exe只需根据msiexec.exe简单包装下就可以用来执行MSI文件。这里(https://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/bootstrapper.html)可以看到Adobe相关文档的说明:
The Acrobat-Reader bootstrapper is provided as part of the Reader bundle on the CD and the web download. It is also provided for some releases on the FTP download site. It provides a streamlined way to chain installs without the need for administrative install points. The bootstrapper provides the following benefits (...)
在一个安装了Acrobat Pro测试系统上找到这个软件的备份,在目录C:/ProgramData/Adobe/Set up/{AC76BA86-7AD7-1033-7B44-AC0F074E4100}。该应用程序解析之后开始执行MSI文件。幸好setup.exe允许我们指定可供选择的ini文件,也不需要关联一些命令行标志,并且是有我们提供的Adobe数字签名。
得到正确的ini文件也很简单,只需要几行代码:
[Startup] RequireMSI=3.0 [Product] msi=C:/Windows/Temp/alsdkjfk/asdf.msi
这里的关键入口点现在是msi了,指向setup.exe启动恶意的MSI并执行。
正确的UpgradeCode是要被设置成MSI的,这个可以通过微软的Orca工具来设置,如下:
不用担心这个值是什么,我们只需要setup.exe来查询这个值并且和当前值进行比较。当这些值都存在时,触发重写操作,之后再通过/sAll /ini “C:/path/to/ini”触发,按上述提到的那样,抛出一个命令行,下面是这个特权提升漏洞GIF演示:
很明显,你并不想启动一个交互服务,我把这个代码附到这篇文章的最下方了。要使用这个方法,你只需生成你自己的MSI之后将它放到资源文件夹中,命名为asdf.msi再编译之。Setup.exe、asdf.ini和asdf.msi作为资源编译成二进制文件,之后放到硬编码的系统文件夹(在%temp%中),这里可以按照个人喜好调整。
0×06 新版本问题
最近的Adobe版本11.0.14中的armsvc版本1.824.16.6751,还没有修复这个已经爆出来的内存共享bug,相反他们移除了7Z的更新机制取而代之的是强制MSI的更新。适当校验可以保证存在问题的二进制文件是一个真正的MSI文件并且是Adobe标记的。这是通过先检查指定文件的数字签名,则确保它是一个MSI完成:
之后使用一套win32函数msi!Msi*反复轮询MSI的产品信息,最终使用MsiReinstallProductW 或者 MsiInstallProduct安装MSI。
最后附上 POC ,测试环境:Adobe Reader 11.0.10 ,armsvc 版本1.801.10.4720。
0×07 参考文献
One: https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Hariri-Spelman-Gorenc-Abusing-Adobe-Readers-JavaScript-APIs.pdf
Two: http://community.hpe.com/t5/Security-Research/Adobe-s-CVE-2015-5090-Updating-the-Updater-to-become-the-bossman/ba-p/6765412#.VafBNxNVikp
Three: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5090
*原文地址: fusionx , FB小编老王隔壁的白帽子编译,转载请注明来自FreeBuf黑客与极客(FreeBuf.COM)