利用 SteelSeries 的子应用程序机制进行权限升级
执行摘要
Akamai 安全研究人员 Tomer Peled 在 SteelSeries 的应用程序中发现了两个漏洞。
SteelSeries 是一家生产计算机外设的硬件公司，在全球拥有超 900 万的客户。
这两个漏洞的 CVE 编号分别为 CVE-2023-31461 和 CVE-2023-31462。SteelSeries 已于 2023 年 5 月迅速对这些漏洞采取了修补措施。
利用这些漏洞，攻击者能够以高于最初所获权限的权限执行代码，甚至能够以管理员权限来执行代码。要利用这些漏洞，攻击者需要向侦听 IPC 服务器发送两个本地数据包。然后，该服务器将以升级后的权限执行攻击者的攻击载荷。
这些漏洞的根本原因在于服务的 IPC 侦听器中的权限处理不安全，且缺乏对路径遍历的保护。
本着负责任的态度，Akamai 安全情报组 (SIG) 向 SteelSeries 支持和工程团队披露了这些漏洞，并将漏洞提交给 MITRE，以分配 CVE 编号。
SIG 在我们监控的几个数据中心内发现了存在漏洞的服务，并向客户通报了风险以及抵御措施。
- 我们提供了一个概念验证 (PoC) 漏洞以及一个 osquery ，用于检测存在易受攻击服务的机器。
简介
SteelSeries 是一家专门生产键盘、鼠标、耳机等计算机外设的硬件公司。为方便用户定制这些设备，SteelSeries 为用户提供了 SteelSeries GG 应用程序，用户可从该公司的网站上下载该应用程序。
该应用程序由 SteelSeries GG 主模块和多个子应用程序组成，是 SteelSeries 用于增强用户体验的一种机制。
通过研究， 我们发现通过两种方法注册我们自己的子应用程序，并指定通过其运行的代码，可能会导致以更高权限执行代码。在本博文中，我们将提供漏洞的技术细节以及漏洞利用 PoC。
技术细节
SteelSeries GG 默认以中等级别的完整性执行，且通常在管理员上下文中执行。因此，在某些情况下可能会在完整度较高的上下文中执行。这一细节，再加上 SteelSeries GG 实际上是一个侦听进程（图 1），使得它成为漏洞研究的优质目标。
图 1：进程处理程序和 netstat 显示侦听 SteelSeries GG 应用程序
子应用程序机制和进程间通信 API
子应用程序机制用于管理 SteelSeries 的可选功能并增强用户体验。Sonar 便是此类子应用程序的一个例子，根据 SteelSeries 的定义，“Sonar 是一套先进的游戏音频软件工具。借助这套工具，任何人都能单独调整游戏音量、团队聊天音量和麦克风音量。”子应用程序在后台运行，并通过进程间通信 (IPC) API 与应用程序的主模块通信。
SteelSeries GG IPC API 公开了用户可请求的几类操作，包括配置更改、管理操作、用户个人资料编辑等。更有趣的是：此 API 提供了一个用于管理子应用程序的接口，包括对子应用程序进行创建和删除以及启用和禁用等。
API 路由功能（即如何处理每个 API 请求）是利用 gorilla/mux 开源库实现的。在了解这一点之后，我们就能更轻松地探究攻击面。路由功能本身非常庞大，但它本质上只是针对每个可用 API 选项的 if 语句集合（图 2）。
图 2：在 SteelSeries GG 中实现 HTTP 路由
任何人只要启动与侦听服务器（“SteelSeriesGG.exe”）的连接便可使用这些 API 调用，且无需进行身份验证。
我选择重点阐述子应用程序事件处理程序，因为它们的潜在影响最大。在 IDA 中重新组织反汇编的代码后，我们发现子应用程序的路由处理程序具有如图 3 所示的原型。
图 3：gorilla/mux 代码中的处理程序函数原型
利用子应用程序机制
我们可以进行的其中一个 API 调用是创建新的子应用程序。此过程是通过向 /subApps 路由发送 POST 请求而完成的，请求的 JSON 有效负载包含多个参数，其中有四个参数我们很感兴趣：“name”、“executableName”、“isEnabled”和“shouldAutoStart”。
利用这些字段，我们能够以非特权用户身份实际创建一个新的子应用程序，将其指向非特权位置的可执行文件，还可以在每次启动应用程序时对该子应用程序加以调度。
SteelSeries GG 按如下格式构建子应用程序可执行文件的完整路径：
<StellSeriesGG install location>\Apps\<name>\<executableName>.exe
由于“name”和“executableName”字段以此种方式相串联，因此我们认为可以尝试进行路径遍历攻击。如图 4 所示，SteelSeries GG 对路径遍历并无招架之力，可以接受在路径前加“../../../../”。
图 4：创建新的子应用程序时接受路径遍历
创建子应用程序时，其相关信息会存储在 SteelSeries GG 的数据库中。是否有可能存在其他方法来通过该数据库控制子应用程序？事实上，该数据库所在位置并不安全。这意味着，即使不访问子应用程序 API，我们也可以直接将子应用程序添加到数据库中。但是，攻击者必须找到一个漏洞才能滥用这一设计缺陷，这一设计缺陷本身无法被利用，因此不会造成直接风险。
您可能会认为在受控位置创建子应用程序意味着我们已经实现了权限升级（一旦我们从该路径执行二进制文件），但尝试之后，我们发现还存在另一限制，即证书验证。SteelSeries 当然会确保子应用程序可执行文件经过签名和核准。要运行我们自己的攻击载荷，就必须绕过验证过程。
该验证函数会调用 WinVerifyTrust 函数，然后调用一系列 WinAPI 函数，以将证书中的某些字段与应用程序中的硬编码字符串进行比较。
绕过此验证有点棘手，但仍可通过两种方法实现：
DLL 劫持
TOCTOU（检查时间到使用时间）
DLL 劫持媒介
利用 DLL 劫持技术时，我们可以依赖于以下事实：SteelSeries 信任几个现有二进制文件；其中一个是 SteelSeriesEngine.exe，该文件会加载 SSEDEVICE.dll库。我们将编译自己的同名库，以加载我们的库，而非初始的 SSEDEVICE DLL。我们自己 DLL 的导出函数将调用原版 DLL 的函数。
但是，加载我们的 DLL 时调用的函数将用于实现我们的恶意逻辑（图 5）。此技术在 itm4n 的 DLL 代理 博文中有进一步的说明。
图 5：SSEDEVICE 的 DLL 劫持
图 6 中的动画展示了从发送初始数据包到以升级后权限运行攻击者的攻击载荷（在我们的案例中是打开 cmd 实例）的过程。
图 6：从发送初始数据包到以升级后权限运行攻击者的攻击载荷的过程
TOCTOU 媒介
在该情况下，我们利用了证书验证与实际执行二进制文件之间的时间差（图 7）。换言之，我们试图利用 James Forshaw 的 BaitAndSwitch 工具快速将合法文件替换为恶意文件，从而赢得争用条件。我们希望在证书验证后立即替换此文件。这样，验证会在合法文件上进行，但随后则执行未经验证的恶意文件。
从设计上说，争用条件并不保证一定有效。为稳住这一漏洞，我们可以尝试为替换赢得更多时间，以扩大我们的机会窗口。
图 7：TOCTOU 媒介图示
回想一下，证书验证依赖于两个测试：对 WinVerifyTrust 的调用，以及证书中的几个字段和应用程序中的硬编码字符串之间的对比检查。我们可以在自己的可执行文件中植入包含这些精确值的证书。借助这一增强，攻击者能够赢得争用条件，即便两个测试间发生切换也是如此，因为我们的恶意二进制文件满足第二个测试的所有标准。
图 8 中的动画展示了从等待 BaitAndSwitch 验证流程开始到执行攻击者二进制文件（在本例中为 cmd.exe）的过程。
图 8：从等待 BaitAndSwitch 验证流程开始到执行攻击者二进制文件的过程
检测和抵御
为帮助检测网络中易受攻击的资产，我们提供了一个 osquery 来查找 SteelSeries GG 的实例及其当前的安装版本：
SELECT name,version from programs where name LIKE '%SteelSeries%' |
Akamai Guardicore Segmentation 客户可以通过 Insight 使用此查询，以查找需要修补的应用程序。
SteelSeries 会使用每个新补丁更新其应用程序。这可能会降低您的设备受这些漏洞影响的几率，但我们建议防御者将 SteelSeries 升级到 39 以上的版本。
结论
SteelSeries 是一家大型公司，在全球拥有超 900 万客户的庞大用户群。其产品中的任何漏洞本身都会产生较大的影响。如果我们考虑到利用这些漏洞的难易程度及其对机器的影响（即可能以管理员身份执行二进制文件），后果就会更加严重。
其影响范围不仅限于用户的计算机，整个企业也可能会受到影响。员工的笔记本电脑如果连接到易受攻击的设备或运行易受攻击的应用程序，而这些笔记本电脑随后可能会接入企业网络，这样就将风险“导入”了整个组织。因此，企业必须考虑实施自带设备 (BYOD) 政策，并就此类设备的使用风险对员工开展培训。
我们已经扫描了 Akamai 客户的网络，试图搜索存在漏洞的应用程序实例，并通知了相关客户。
在我们为了保护客户和社区而采取的后续举措中，我们将继续分析修补程序和其他系统中存在的漏洞。要了解 Akamai 最新的安全研究， 请关注我们的微信公众号。
披露时间表
2023 年 4 月 27 日——向 MITRE 提交 CVE 请求
2023 年 5 月 1 日——向 SteelSeries 客户支持团队发送电子邮件
2023 年 5 月 2 日——MITRE 分配 CVE 编号
2023 年 5 月 3 日至 2023 年 6 月 4 日——与 SteelSeries 工程设计团队对话
2023 年 5 月 31 日——发布补丁
2023 年 7 月 17 日——SteelSeries 审阅博文草稿
2023 年 7 月 18 日——发布博文
