刚刚修复的Windows 0day和Chrome 0day 已被组合用于 WizardOpium 攻击（详解）

 聚焦源代码安全，网罗国内外最新资讯！

编译：奇安信代码卫士团队

微软在刚刚发布的12月“补丁星期二”*修复36个漏洞，其中含一个已遭利用的 Windows 0day (CVE-2019-1458)。卡巴斯基实验室指出，该漏洞和一个 Chrome 0day  (CVE-2019-13720) 同时被用于Operation  WizardOpium 攻击活动中。

微软将该漏洞称为“Win32k提权漏洞”，指出它可导致攻击者在内核模式中执行命令，也就是说它具有对操作系统的完整访问权限。微软表示：

“当Win32k 组件未能正确处理内存中的对象时，Windows 中就存在提权漏洞。成功利用该漏洞的攻击者可以在内核模式中运行任意代码。攻击能够安装程序；查看、修改或删除数据；或以完整的用户权限创建新账户。要利用这个漏洞，攻击者首先必须登录系统，之后运行可利用该漏洞的特殊构造的应用程序并控制受影响系统。发布的更新通过更正了 Win32k 处理内存对象的方式解决了这个漏洞问题。”

卡巴斯基实验室发布相关报告，奇安信代码卫士翻译如下：

2019年10月，卡巴斯基实验室成功地检测到被用于 Operation WizardOpium 攻击活动中的一个 Chrome 0day (CVE-2019-13720)。我们在调查活动中发现这些攻击活动中还使用了另外一个 0day。谷歌 Chrome 的 exploit 内嵌了一个 0day 提权 (EoP) exploit (CVE-2019-1458)，用于获取受感染机器上更高的权限并逃逸 Chrome 进程沙箱。这个 exploit 和由 0day 多产开发员“Volodya”开发的exploit 非常相似。

该 EoPexploit 由两个阶段组成，一个小型 PE 加载器和实际的 exploit。通过易受攻击的 JS 代码在浏览器的渲染器进程中实现读/写原语之后，PEexploit 损坏了内存中的某些指针，目的是将代码执行重定向至 PE 加载器。这样做是为了绕过沙箱限制，因为该 PE exploit 无法只使用原生 WinAPI 函数就启动新进程。

PE 加载器通过实际 exploit 定位内嵌的 DLL 文件并重复和原生 Windows PE 加载器一样的进程：解析 PE 标头、处理导入/导出等。之后，代码执行被重定向至 DLL 的入口点即 DllEntryPoint 函数。该 PE 代码随后创建一个新进程作为 exploit 本身的入口点，而主线程等待其停止。

（攻击中利用的 EoP）

封装该 EoPexploit 的 PE 文件的标头如下：

Wed Jul 10 00:50:48 2019 这个编译时间戳和其它二进制不同，表明它已被使用了一段时间。

我们对 EoPexploit 的详细分析表明，它所使用的漏洞属于 win32k.sys 驱动，而 EoP exploit 就是这个 0day exploit，原因是它适用于最新（修复的）Windows 7 版本甚至适用于一些 Windows 10 的新版本（新的 Windows 10 版本并不受影响，因为它们实现了阻止对可利用代码的正常使用的措施）。

该漏洞本身和windows 切换功能有关（例如使用 Alt-Tab 键组合触发的功能）。这也是为何这个 exploit 的代码使用了一些 WinAPI 调用 (GetKeyState/SetKeyState) 来模拟关键的按键操作。

起初，该exploit 试图通过使用ntdll.dll 的 RtlGetVersion 调用来查找操作系统版本，而 RtlGetVersion 用于查找内存中设置虚假内核 GDI 对象所需的十几个偏移量。同时，它试图通过使用多种广为人知的技术泄露一些内核指针，从而泄露一些内核内存地址 (gSharedInfo、PEB 的 GdiSharedHandleTable) 。之后，它试图通过 CreateAcceleratorTable/DestroyAcceleratorTable 的很多调用创建一个特殊的内存布局，其中堆中存在多个漏洞。之后执行 CreateBitmap 的一堆调用，而它们的地址通过句柄表数组遭泄露。

（触发可利用的代码路径）

随后，通过窗口句柄创建一些弹出窗口并调用未记录的 syscall NtUserMessageCall。另外，它使用任务切换窗口 (#32771) 的类创建一个特殊窗口，它对于触发驱动中的可利用的代码路径而言起着重要作用。在这一步，该 exploit 试图模拟 Alt 键，之后使用 SetBitmapBits的一个调用构造一个 GDI 对象。该对象中包含一个可控制的指针值，在 exploit 向 syscall (NtUserMessageCall) 再次发出未记录调用后，该指针值可被用于内核驱动的代码 (win32k!DrawSwitchWndHilite) 中。这就是它如何获得任意内核读/写原语的过程。

（实现造成任意读/写所需原语）

该原语随后被用于在目标系统上提升权限，方法是使用现有系统驱动进程的令牌值来覆写当前进程 EPROCESS 结构中的一个令牌。

（覆写EPROCESS 令牌结构）

幕后黑手

卡巴斯基在关于Chrome 0day 和该 Windows 0day 的分析文章中并未指出 Operation WizardOpium 组织的身份。不过它在 Chrome 0day 分析文章中表示，“无法和任何已知的威胁行动者之间建立确切的关联”，“和 Lazarus 攻击活动中存在某些非常薄弱的代码相似之处，尽管这种迹象也可能是一种伪旗旗标”，实际上“目标网站的资料和早期的 DarkHotel 攻击之间存在更多的一致之处。”

其它漏洞分析

思科Talos 团队分析了微软发布的其中两个“严重”级别漏洞和三个“重要”级别漏洞，如下：

CVE-2019-1468 是存在于 Windows 字体库中的一个远程代码执行漏洞，是因为该库不正确地处理一些内嵌字体造成的。攻击者可通过使用网页中特殊构造的恶意内嵌字体，之后诱骗用户访问该网页的方式利用该漏洞。或者用户可以在机器上打开特殊构造的字体文件。

CVE-2019-1471 是存在于 Hyper-V 管理程序中的一个远程代码执行漏洞。Hyper-V 有时候未能正确验证guest 操作系统上认证用户的输入。攻击者可通过在 guest OS 上运行特殊构造的应用程序的方式利用该漏洞，从而导致 Hyper-V 主机 OS 在主机操作系统上执行任意代码。

除了上述已遭利用的 0dayCVE-2019-1458 外，思科还分析了其它两个“重要”级别的漏洞。

CVE-2019-1469 是存在于 Windows 中的信息泄露漏洞，当win32k 组件未能提供内核信息时就会触发该漏洞。攻击者能够利用该漏洞获取未初始化的内存和内核内存执行其它攻击。

CVE-2019-1485 是存在于 VBscript 引擎中的一个远程代码执行漏洞。攻击者可利用该漏洞损坏受影响系统的内存，从而在当前用户的上下文中执行任意代码。要触发该漏洞，用户必须在 IE web 浏览器中访问恶意的尤其是特殊构造的网站。攻击者也可在使用IE 渲染引擎的应用程序或微软 Office 文档中嵌入被标记为“初始化安全”的一个 ActiveX 控制，之后诱骗用户打开该文件。

微软修复的其它漏洞还包括：

• CVE-2019-1332

• CVE-2019-1400

• CVE-2019-1453

• CVE-2019-1461

• CVE-2019-1462

• CVE-2019-1463

• CVE-2019-1464

• CVE-2019-1465

• CVE-2019-1466

• CVE-2019-1467

• CVE-2019-1470

• CVE-2019-1472

• CVE-2019-1474

• CVE-2019-1476

• CVE-2019-1477

• CVE-2019-1478

• CVE-2019-1480

• CVE-2019-1481

• CVE-2019-1483

• CVE-2019-1484

推荐阅读

谷歌不修用户泪流：已遭利用且影响所有安卓版本的严重 0day 漏洞 StrandHogg 详情遭曝光

两年了火狐仍未修复某 0day，不料又一个新0day出现仨月了

微软补丁星期二修复74个漏洞，含已遭利用的 0day 和神秘漏洞

原文链接

https://securelist.com/windows-0-day-exploit-cve-2019-1458-used-in-operation-wizardopium/95432/

https://blog.talosintelligence.com/2019/12/microsoft-patch-tuesday-dec-2019.html

题图：Pixabay License

本文由奇安信代码卫士编译，不代表奇安信观点，转载请注明“转自奇安信代码卫士 www.codesafe.cn”

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。