Check Point ZoneAlarm反病毒软件本地提权漏洞分析

一、概要

Illumant最近在Check Point ZoneAlarm反病毒软件中发现了一个严重漏洞，攻击者可以利用该漏洞，在反病毒软件启用的情况下，将低权限用户提升至 SYSTEM 权限。该漏洞之所以存在，是因为ZoneAlarm在进程间通信上采用了并不安全的具体实现，使得低权限用户可以使用存在漏洞的.NET服务，劫持不安全的通信，从而注入并执行代码。受影响的.NET服务以 SYSTEM 权限运行，因此被注入的代码会以 SYSTEM 权限运行，绕过权限限制，使攻击者可以获取系统的完全访问权限。

本文从技术角度介绍了该漏洞的发现过程，也介绍了如何在本地环境中利用漏洞以 SYSTEM 权限执行未经授权的代码。

漏洞利用过程可参考 此处 视频。

大家可以访问我们的 GitHub页面 获取漏洞利用代码。

二、背景介绍

Fabius Watson（ @FabiusArtrel ）最近在Ekoparty 2018上发表过一次开创性 演讲 ，主要介绍了如何滥用WCF端点。同样在2018年，Watson也提交并公布了一些CVE。这些权限提升和远程代码执行漏洞都与基于.NET WCF服务的商业产品有关，部分漏洞列表如下：

• CVE-2018-13101 – KioskSimpleService本地权限提升漏洞
• CVE-2018-10169 – Proton VPN本地权限提升漏洞
• CVE-2018-10170 – NordVPN本地权限提升漏洞
• CVE-2018-10190 – Private Internet Access本地权限提升漏洞

Watson对基于.NET的WCF漏洞的研究也给我们提供了研究思路。

此外，我们在漏洞开发过程中也使用了关于代码签名漏洞方面的技术（特别是关于 代码签名证书克隆及防御 方面的技术），这些技术由来自SpecterOps的Matt Graeber （ @mattifestation ）公布。

三、枚举.NET服务

Fabius Watson提供的一个 python 脚本可以帮助我们识别可能存在漏洞的目标服务。该 工具 可以枚举满足如下条件的所有服务：

• 以 SYSTEM （ NT AUTHORITY\SYSTEM ）权限运行
• 服务对应的程序为.NET应用

该脚本中使用了WMIC查询语句来识别以 SYSTEM 运行的所有服务，然后使用 pefile 模块来检查服务程序的导入表中是否存在 mscoree.dll （所有.NET应用都会用到这个库）。该工具的运行结果如下所示：

枚举完成后，接下来就是使用.NET反编译工具来检查这些服务。这里我们使用的是 dnSpy 。虽然系统上运行着许多.NET服务，但不一定都用到了WCF。所有的WCF服务都依赖于 System.ServiceModel ，因此我们可以在dnSpy中检测是否存在相关引用。我们发现ZoneAlarm服务中只有一个引用了这个库： SBACipollaSrvHost.exe 。

四、寻找漏洞点

找到了以 SYSTEM 权限运行的WCF服务后，我们需要检查该服务是否对外暴露了我们可以利用的方法。有时候某些方法会以待运行的命令作为输入，这些方法利用起来非常方便。在其他情况下，利用方式可能没那么直接。当然，目标服务也可能不会公开任何方法，无法用于代码执行。

在源代码审核过程中，我研究了 OnCommandReceived 方法。跟踪该方法触发的一系列调用后，我发现整条调用链中存在一个名为 ExecuteInstaller 的方法，可以用来执行安装程序：

根据这个方法的名称以及实际用途，我们判断该方法很可能是我们寻找的目标，因此继续下一步研究。

五、与目标服务交互

阅读 SBACipolla 类代码后，我们可以看到代码创建了两个命名管道服务端点： Cipolla 以及 CipollaRoot 。WCF服务可以使用各种传输协议，如果使用的是HTTP或者TCP协议，则我们有可能远程利用该服务。在本文中，该服务使用的是命名管道，因此我们的目标是实现本地权限提升：

还有名为 AddSecureWcfBehavior 的一个自定义方法会调用这些服务端点，这表明开发者可能会尝试锁定这些服务。实际上，当某个客户端尝试连接到命名管道服务器时，代码首先会检查该连接是否来自于Check Point签名的进程，如下图所示：

首先服务器会确定客户端的PID，然后使用该信息获取程序的完整路径，最后，服务端会检查：A）应用是否使用有效证书进行签名，以及B）证书的CN字段是否以“Check Point Software Technologies.”开头。如果不满足这些条件，服务端就会断开该连接。

六、绕过代码签名

我们最初的目标就是将DLL注入到经过Check Point签名的合法进程来满足这些检查条件，以便与目标服务通信。这种方法只有当特定的反病毒功能被禁用后才行之有效。在默认状态下，我们很难将DLL注入大部分进程中，因此这不是一个首选方案。

来自SpecterOps的Matt Graeber发表过一篇 文章 ，其中介绍了一个PowerShell cmdlet，能帮助低权限用户使用自签名证书来签名代码，也能让操作系统信任该证书。这样一来，我们就有可能签名利用代码，使其能与WCF服务通信，无需注入其他进程。我们可以通过如下步骤，使用伪造的证书来签名利用代码，绕过检查机制：

$cert = New-SelfSignedCertificate -certstorelocation cert:\CurrentUser\my -dnsname checkpoint.com -Subject “CN=Check Point Software Technologies Ltd.” -Type CodeSigningCert

Export-Certificate -Type CERT -FilePath c:\tmp\MSKernel32Root_Cloned.cer -Cert $cert

Import-Certificate -FilePath c:\tmp\MSKernel32Root_Cloned.cer -CertStoreLocation Cert:\CurrentUser\Root\

Set-AuthenticodeSignature -Certificate $cert -FilePath c:\tmp\exploit.exe

七、开发利用代码

SBAStub.dll （具体路径为 C:\Program Files (x86)\CheckPoint\Endpoint Security\TPCommon\Cipolla ）中定义了一个 SBAStub 对象，该对象负责处理连接到WCF服务所需的所有管道，还包含名为 SendCommand 的一个方法，我们很自然就能猜测到该方法与目标服务中的 OnCommandReceived 方法有关。 OnCommandReceived 方法接受名为 CommandXML 的一个字符串作为参数，该字符串会原封不动传递给 ExecuteInstaller 。接下来我们看一下 ExecuteInstaller 中的代码，分析该方法对参数的处理过程：

代码204-211行会反序列化处理 CommandXML ，将其转换成一个 RunInstallerPackageCommand 对象，这是服务程序中自定义的一个类，该类包含3个字段：string类型的 InstallerPackagePath 、string类型的 InstallerPackageArguments 以及另一个自定义类（ SBAMessageInfo ） MessageInfo 。该类中最有趣的字段为 InstallerPackagePath ，因为该字段可以用来在目标服务的上下文中启动进程。

在224行，我们可以看到代码会验证 InstallerPackagePath 所指向的程序是否由Check Point签名。

代码213-232行会将参数载入一个 Process 对象中，然后在235行启动该对象。

因此我们有可能以 SYSTEM 权限启动由Check Point签名的任何应用。

利用代码如下所示：

首先我们初始化 SBAMessageInfo 及 RunInstallerPackageCommand 对象，最重要的是要在 InstallerPackagePath 字段中设置需要目标服务运行的程序。接下来，我们使用 XmlSerializer 来序列化 RunInstallerPackageCommand 。最后，我们创建一个 SBAStub ，使用 SendCommand 方法将新序列化的对象发送给目标服务。只要 InstallerPackagePath 所指定的文件经过签名，并且包含的CN为 Check Point Software Technologies, ，目标服务就会帮我们启动该程序。

为了演示利用过程，我们创建了一个简单的示例程序，可以在系统中添加一个新的本地管理员账户，我们使用内置的Windows PowerShell cmdlets对该程序进行签名。随后，目标服务会按照我们的要求运行该程序，实现权限提升。

八、厂商回应

在开发出利用代码后，我们第一时间将漏洞反馈至Check Point。与其他厂商相比，他们的披露机制要方便得多。Check Point在官网上专门为反馈安全问题开放了一个表单，在提交漏洞后厂商很快就与我们取得联系，并且也在问题处理更新过程中与我们协同合作。

厂商修复问题代码后，邀请我们验证修复补丁是否有效。他们的修复方法非常简单，直接让攻击者无法通过WCF来利用 ExecuteInstaller 方法，然后也提高了未授权客户端与目标服务交互的难度，这样处理比简单地避免WCF对外暴露敏感功能来说要更为安全。