0x00 前言
几个月之前,我在Check Point Endpoint Security VPN客户端中找到了一个DACL
权限覆盖漏洞。利用该漏洞,Windows系统上的任意用户可以设置任意文件的权限,使Authenticated Users
安全组具备该文件的Full Control
权限(这里唯一的限制在于SYSTEM
用户需要具备该文件的编辑权限,因此TrustedInstaller
所属的某些系统文件无法通过这种方式覆盖)。
在Windows系统上,这个VPN客户端主要包含两个组件:以SYSTEM
权限运行的一个Windows服务以及以当前用户身份运行的一个客户端。对于该漏洞,除了重启服务之外,我们并不需要与这个服务执行太多交互操作。然而我的确分析过用户客户端与服务之间的通信行为,发现该VPN使用的是比较有趣的一种自定义RPC协议,值得进一步研究。
虽然这个漏洞的确是我自己挖掘出来的,但已经有人先我一步向Check Point反馈了相关情况。Check Point于2019年4月16日修复了该漏洞。
0x01 漏洞描述
“Check Point Endpoint Security VPN”服务在启动时,会对C:\Windows\Internet Logs
目录下的所有文件执行权限重置操作。重置完成后,Authenticated Users
就具备这些文件的Full Control
权限,这意味着系统上的任意用户都可以具备这些文件的写入、读取以及修改权限。此外,该服务还将设置Internet Logs
目录的Full Control
权限。无论Internet Logs
目录下具体包含哪些内容,无论这些文件具体来源如何,该服务都会执行这种权限重置操作。
在Windows系统上,我们可以创建硬链接(hard links)。简而言之(具体情况会更加复杂),我们可以把硬链接看成另一个文件的副本,在副本上执行的任意操作都会影响到原始文件,反之亦然。这意味着如果我们能创建某个文件的硬链接,并且在硬链接上设置权限,那么这些权限也会反馈到原始文件上。系统有个内置的命令行工具(mklink
)能够创建硬链接,然而该工具要求创建硬链接的用户需要具备“原始”文件的写入权限。来自Google Project Zero的James Forshaw发现这实际上并不是必须满足的一个条件。mklink
使用的是Windows系统中的CreateHardlinkW
API,强制检查是否具备写入权限,如果具备相应权限,再去调用NtSetInformationFile
。然而如果我们直接使用NtSetInformationFile
,就可以绕过写入权限检查机制。James Forshaw在一篇文章中详细介绍了这种绕过方法,并且表示除非应用程序运行在沙箱环境中,否则这种方法可以行之有效。
这意味着如果我们从C:\Windows\Internet Logs
目录中创建硬链接,指向SYSTEM
具备编辑权限的任意文件,那么当权限重置操作完成后,系统上的任意用户就能覆盖该文件。通过这种方法,普通用户账户就可以实现权限提升。
0x02 Poc
首先,我们需要找到待覆盖的某个文件,并且可以通过该文件实现权限提升。我们可以通过计划任务梳理以SYSTEM
权限运行的任务,这是比较好的一个切入点。
Google Update计划任务是非常好的一个目标,该任务以SYSTEM
权限运行,运行时间能够预测(任意用户登录时),并且SYSTEM
权限能够修改并写入该任务对应的可执行文件。
接下来我们需要从C:\Windows\Internet Logs
中创建指向Google Update可执行文件的一个硬链接。这里我们可以使用FuzzySecurity提供的PowerShell-Suite
,其中包含一个非常方便的PowerShell脚本(Native-HardLink),通过该脚本我们能直接利用NtSetInformationFile
创建所需的硬链接。我们可以导入该脚本,然后创建指向Google Update程序的硬链接,如下所示:
现在我们可以看到两个目录中都出现了对应的可执行文件。
接下来,由于普通用户账户无法重启Check Point服务,我们可以重启目标主机,从而重启该服务。当系统启动时,可以看到GoogleUpdate.exe
的权限已经更新,现在我们可以以普通用户身份覆盖该程序。
为了演示方便,这里我们将这个程序替换成一个反弹shell。注销后再次登录,我们就能获取具备SYSTEM
访问权限的一个shell。
整个攻击操作可参考此处视频。