关于获取 FortiOS shell 权限以及如何通过 License 授权验证。
处理判断逻辑
本博客某历史文章中提到过一篇参考资料,不过这篇资料是针对旧版本 FortiOS 的,Fortinet 曾在 2019 年 11 月 14 日发布了一个影响 FortiOS 的 CVE,在这个漏洞的描述中,官方认为 VM 应用缺少对文件系统的检查,可能导致攻击者向系统中注入恶意程序。为此在启动流程中添加了文件系统校验,按照参考资料的步骤修改系统文件之后可能会导致无法启动或者无限重启。
对于这个问题,我们首先想到的是定位检查逻辑,看看能否根据算法打包出正确的文件或者直接将检查逻辑 patch 掉。先看一下系统启动时的输出信息:
考虑文件系统的校验可能是在内核或者用户态实现,我们首先在文件系统中尝试搜索 System is starting 字符串
在二进制文件 bin/init 中找到了匹配,逆向该文件看看这个字符串是何时打印的:
1 | t_printf("\nSystem is starting...\n", v11, v8, v12, v5, v6, requested_time.tv_sec);// 打印字符串 |
我们看到在 init 程序的 main 函数中第 82 行位置打印了此字符串,而向下分析发现有几处判断,其中比较明显的位置引用了 /bin/fips_self_test 字符串。do_halt 函数的内容:
1 | unsigned __int64 do_halt() |
这里会输出信息 The system is halted,表示系统已停止运行。
第一个判断函数内部执行了 ioctl 和 socket 等函数,向内核发送或接收某些信息
1 | int __fastcall sub_2907930(int a1, __int64 a2) |
第二个函数 fork 出一个子进程,主要处理逻辑:
1 | _BOOL8 sub_447D40() |
函数开头通过异或运算处理了一个字符串,解密之后得到结果 /.fgtsum
在根目录能找到这个文件,那么显然此函数就是利用该文件实现了某些系统校验。
第三个函数(sub_2745D50)似乎和 FIPS 模式相关,FIPS 简单来说是美国政府针对计算机系统定义的一种标准化信息处理方式,旨在提升信息的安全性。第四个函数(sub_44F1F0)同样 fork 出了子进程,相关逻辑
1 | _BOOL8 __fastcall sub_2780BD0(unsigned int a1) |
此函数实现对 rootfs.gz 的判断。
到这里可以大体推断文件系统的校验是在用户态程序 /bin/init 中实现的。相关逻辑并不复杂,我们可以深入研究以便于打包一份合适的 rootfs.gz 通过校验,或者采用更简单的方法即 patch 掉校验逻辑。
经过验证,只需要 patch fgtsum 和 rootfs 两个检验即可,将对应跳转指令取反,保存并替换原始文件。
1 | if ( sub_44F240() ) |
或者,我们使用更简单的补丁,直接将 do_halt 函数的第一条指令改为 ret,这样就算无法通过验证,也不会执行重启操作。
植入后门并启动
后续的操作和参考文章提到的类似,先用 msf 生成一个后门程序,替换 /bin/smartctl 文件,然后将 patch 的 init 程序替换 /bin/init,同时在系统中放置一个 busybox 并将 /bin/sh 指向 busybox 方便后续使用。
根据前面的文章我们知道系统启动时会首先执行 /sbin/init,这个程序的逻辑很简单:
1 | __int64 __fastcall main(__int64 a1, char **a2, char **a3) |
它负责解压各个压缩包并唤起 /bin/init 继续执行,没有其他操作。方便起见我们跳过重新打包 xxx.tar.xz 的步骤,在系统启动过程中调试内核并修改内核参数,让它直接去执行 /bin/init 程序。
打包命令
1 | find . | cpio -H newc -o > ../rootfs.raw |
将新的 rootfs.gz 替换到磁盘中,挂载到原先系统上,并添加调试桥。
启动时用 gdb 附加,并定位到执行用户空间程序位置:
此时执行的目标程序为 /sbin/init
我们将其修改成 /bin/init,然后继续执行,系统将正常启动,执行命令 diagnose hardware smartctl
即可触发后门程序。由于设备存在防火墙,端口不能随便访问,我们将其自带的 sshd 服务 kill 掉并替换成 telnetd 后门
1 | killall sshd && busybox telnetd -l /bin/sh -b 0.0.0.0 -p 22 |
这样就可以获取一个完整的 root 权限:
另外,也可以使用我编写的一个简单工具,使用方法请参考说明文档。
License 授权分析
第一次启动系统时,需要导入一个合适的 License 才能使用各项功能,在前面的文章中我们提到可以注册 FortiCloud 账户并使用评估版本 License,不过这样操作比较复杂,而且每有一个新版本就要重新注册一个账户,有没有一种方法可以绕过或者破解 License 验证呢?本部分将会介绍一种构造 License 的方法。
首先定位校验 License 的逻辑,通过查询 FortiGate 手册,得知存在一个叫做 vm-print-license
的调试命令,使用方法为 diagnose debug vm-print-license
,在未激活状态下执行会看到以下输出,提示我们当前处于试用状态。
系统大部分业务逻辑都在 /bin/init 中,我们直接在 /bin/init 程序中搜索 License
、vm-print-license
等字符串,在结果中找到比较有趣的几条数据:
看起来像 License 文件的定位符,交叉引用最终可定位到以下代码
1 | unsigned __int64 maybe_check_license() |
该函数尝试读取 /data/etc/vm.lic 文件,并使用 sub_29200D0 对其解析。由于已经获取到了 shell 权限,我们可以看到未激活时这个文件的内容:
1 | -----BEGIN FGT VM LICENSE----- |
这进一步印证了我们的猜想,即这部分代码逻辑和 License 有较大关系。
外层函数 maybe_check_license 的逻辑比较简单,首先从 /data/etc/vm.lic 中读取授权信息,接着调用 init_lic_struct 函数初始化一个全局变量结构体 lic_struct,然后使用 sub_29200D0 函数解析授权文件
1 | __int64 __fastcall sub_29200D0(char *lic_file_content, __int64 lic_length, lic_struct *lic_struct) |
我重命名了一些变量并添加了一部分注释,这个函数逻辑稍稍复杂,简要描述如下:
首先检查授权文件是否包含定位符,根据定位符确定主要内容的起止位置,对内容进行 Base64 解码,然后从解码的数据中读取头部结构。从内存中解压一个 RSA 公钥,先尝试使用这个公钥解密余下请求,如果解密失败,再尝试使用 AES-128-CBC 解密内容,使用的 key 和 iv 是从 Base64 解码的数据头部获得的。
之后对解密的数据进行判断,首先是 magic 部分需要等于 0x13A38693,之后跟随数个 Block 结构,Block 结构类似 TLV,由数据长度、数据名、数据值组成,每个 Block 对应 License 中的一个信息字段。
解析好各个结构之后将这些信息填充到 lic_struct 结构体中,并在后续功能继续使用。
根据以上代码逻辑,我们可以整理出 Licnese 的大致组成,以 Python 来表示
1 | class License: |
程序中还存在一个关键结构体,定义了 Block 基本信息
1 | struct lic_block |
至此我们已经得知了 License 的结构和组成成分,接下来需要分析 block 中各项都起什么作用,以及 lic_struct 结构体是如何参与 License 验证的。不过这里有比较简单的方法,Block 具有比较清晰的名称,根据名称可大致猜测其作用,例如 SERIALNO 应该表示设备序列号,CREATEDATE 表示 license 导入日期,EXPIRY 表示过期时间等。
通过调试并结合代码分析,Block 中其关键作用的应该是 SERIALNO、CREATEDATE、USGFACTORY、LENCFACTORY、CARRIERFACTORY、EXPIRY 几个字段,其余字段可以省略。
根据分析结果,编写出对应的注册程序,你可以在 Github 上获取。
导入生成的 License 文件后再次执行 vm-print-license
得到 License 合法的结果,而且后台功能也可以正常使用了。
本部分介绍了 FortiGate License 授权验证逻辑,分析了 License 组成结构和各字段大致含义,并编写了一个注册程序可以生成合适的 License。
- 本文作者: CataLpa
- 本文链接: https://wzt.ac.cn/2023/03/02/fortios_padding/
-
版权声明:
本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。