FortiClient本地提权0day漏洞分析

一、前言

我们在FortiClient中找到了3个漏洞，低权限用户可以组合利用这3个漏洞提升至 NT AUTHORITY/SYSTEM 权限。我们尝试与Fortinet沟通，共同解决这些问题，但对方在长达8个多月时间内没有回复我们，并且在没有通知任何人的情况下公布了一个比较糟糕的补丁。

注意：FortiClient <= 6.0.3.0155以及低于5.7的版本也会受漏洞影响，更低版本可能也存在漏洞。

二、漏洞描述

我们滥用了FortiClient的命名管道（named pipes）来强制更新，可以触发漏洞扫描操作，然后强制FortiClient更新并不在目标主机上的软件。结合目录遍历漏洞和命令执行漏洞后，我们就可以获得 NT AUTHORITY/SYSTEM 权限。

三、漏洞分析

命名管道写入漏洞

我们可以使用 ioninja 监控forticlient在命名管道中的通信数据。在我的测试系统中，该命名管道为 FC_{F18F86FD-7503-4564-80CF-B6B199519837} 。

我们尝试在所有用户可用的UI中各种点击，很快就看到了一个有趣的数据包。程序使用这种方法来告诉调度程序（scheduler）执行按需扫描。这里比较奇怪的是我们可以在数据包中指定具体路径及命令行参数。

逆向分析该协议后，我伪造了一个数据包：

我发现包头的 60 80 为命令的魔术字节（magic byte），并且十六进制 18 （第9个字节）代表 apptype 。在PoC中，我们滥用的正是 apptype ，将其指定为 0x18 （代表 FCVbltScan.exe ）。

FCDBLog.exe 这个进程会读取命名管道中的信息，然后更新 HKLM\SOFTWARE\Fortinet\FortiClient\FA_Scheduler\000020 注册表项。该进程只是简单读取相关信息，然后将其写入 param 键值中（如果我们修改 apptype /第9个字节，我们就可以在 FA_Scheduler 中写入其他服务信息）。

如上图所示，我们可以写入 -t 1 -p c:\users\lowpriv\Desktop\lasla\evil.tmp -u 字符串，触发目标开始安装在 evil.tmp 中发现的所有漏洞补丁。

完成如上步骤后， scheduler.exe （系统权限）进程就会读取相关键值，以系统权限启动服务。

因此这里的问题是我们可以指定自定义的XML文件（如 evil.tmp ），程序会从其中读取当前系统存在的漏洞信息。

路径遍历漏洞

注意，这里之所以涉及到 vcm2.exe ，是因为该程序由 FCVbltScan.exe 所启动。

第二个问题在于程序对 -p 参数所指定的文件的解析过程。该文件内容与FortiClient漏洞扫描器的处理结果有关。FortiClient会读取这个json文件，根据每个 Install 元素中 VID 键的值来判断系统需要安装哪些补丁（我们构造的json文件如下图所示）。

通常情况下，这个 VID 值为 20440 或者其他相关值，这是一个整数值字段。然后 vcm2.exe 会查找扫描目录中以 VID 为名称的 .json 文件。

然而我们发现，我们可以在 VID 中实现路径遍历，将其指向我们能够控制的某个路径。这意味着我们可以提供漏洞安装文件的配置信息。

如下图所示，我们将该字段指向 \users\IEUser\Desktop\lasla\vuln ，而 vcm2.exe 现在会搜索该目录中的 vuln.json 文件，获取安装信息。

因此我们现在可以精确控制哪些补丁需要安装到当前系统中。

LUA补丁脚本中的命令注入漏洞

以上漏洞引导我们发现第3个，也是最后一个漏洞：LUA中的命令注入漏洞。

evil.tmp 中的 vulnjson 实际上是安装文件的配置信息。我们对比了合法的文件，并做了相应修改。该文件用来指定哪些目标需要修补。

FortiClient的所有 lua 脚本都存放在名为 flat-db.dat 的一个文件中，这是一个 SQLITE 文件，因此数据库表中包含与脚本匹配的VID，用来指定待执行的脚本。

vcm2.exe 的功能是从FortiClient目录的 flat-db.dat 中读取相关LUA脚本，然后执行与我们指定的VID匹配的脚本。

vuln.json 文件内容如下：

然而这里我们可以将 DetectedProducts 字段中的某些参数传递给lua脚本。在 DetectedProducts 键中，我们指定了 Product 、 Product Path 以及 Detected Version 字段的值。我们使用LUA脚本来给Mozilla产品打上补丁，并且我们发现了如下几行代码：

如上所示， filepath = arg[2] 这个参数会一路传递给 GetLanguage 函数。

GetLanguage 函数如下所示：

在第50行我们看到脚本首先将我们提供的 setupPath 放入 cmd 参数中，然后在52行，脚本会直接执行相关命令，没有检查是我们是否使用了不被允许的字符。因此如果我们回头看 vuln.json 文件，可以看到我们的 Product Path 字段值为 c:\tes"&calc&"tingfire\firefox.exe ，这样就可以将 calc 命令注入 os.capture 中。

现在我们已经得到以 system 权限运行的 calc ，也可以将其替换为其他命令或者其他程序。

四、补丁说明

快速逆向分析补丁后，我发现厂商在 product 以及 detected_version 字段上做了 assert 处理。

此外，厂商还使用 os.rename 函数来确保目标文件的确存在，并且由于文件名不能包含特殊转移字符，因此一切看起来都还不错。

五、绕过补丁

稍等片刻，让我们回头看补丁的第227行。厂商难道只是判断 product 必须为字符串？这并不是命令执行的关键，因此当然无法正确防御这类攻击。由于字符串中我们可以使用所有字符，现在我们可以grep查找产品中使用 os.execute 的地方，充分发挥字符串的威力。

找到目标，如下所示：

修改版的 vuln.json 如下所示：

攻击结果非常完美，如下所示：

六、总结

作为厂商，当有人提交漏洞信息时请认真对待，让对方测试厂商发布的补丁。许多人热衷于黑掉软件，因此会花大量时间免费挖掘软件脆弱性，那么厂商为什么不利用这一点，让大牛们提升软件安全性呢？

七、时间线

• 02-04-2018 – 报告漏洞信息
• 07-04-2018 – 厂商确认我们提供的邮件准确，发送邮件后我们只需等待他们通知，会在漏洞披露过程中提醒我们，并且在官网上公开致谢
• 15-04-2018 – 厂商确认收到漏洞报告
• 25-04-2018 – 确认漏洞，分配了3个CVE编号：CVE-2018-9191、CVE-2018-9192以及CVE-2018-9193（现在这些编号已分配给其他漏洞，我们不清楚目前对应的CVE编号）
• 11-05-2018 -> 31-06-2018 – 日常咨询进展
• 11-05-2018 -> 31-06-2018 Regular ping for news
• 01-08-2018 – 厂商通知已分配到新的漏洞处理事宜
• 22-11-2018 – 告知Fortinet我们尚未收到任何解决方案更新信息，我们准备发表研究文章
• 19-12-2018 – 我们发现Fortinet尝试修复漏洞，然后逆向分析了补丁，通知对方我们已发表研究文章
• 21-12-2018 – 安排针对Windows平台6.0.5/6.2版的修复计划，目前正在编写完整版安全公告