This part of the series is focused on the vulnerability itself, which includes its patch. I was particularly interested in examining the patch for this bug, since my proposed fix seemed to trigger crashes in Microsoft Teams. It’s important to mention that at this point I have yet to examine how a real application uses the MSKSSRV driver in practice. Not having this context introduces blind spots into the understanding of why a system is designed the way it is. A complete patch for this bug would require some base code restructuring and could reveal more details about how the IPC system is intended to function. I was also hoping to glean some insight into secure coding practices from Microsoft developers.
本系列的这一部分重点关注漏洞本身,包括其补丁。我对检查此错误的补丁特别感兴趣,因为我提出的修复似乎会触发 Microsoft Teams 崩溃。值得一提的是,目前我还没有研究实际应用程序如何在实践中使用 MSKSSRV 驱动程序。如果没有这种背景,就会在理解系统为何如此设计的过程中出现盲点。针对此错误的完整补丁需要进行一些基本代码重组,并且可能会揭示有关 IPC 系统如何运行的更多细节。我还希望从 Microsoft 开发人员那里收集一些有关安全编码实践的见解。
To my disappointment, the logic error that caused the vulnerability, which was patched in the June 2024 Security updates, was not addressed directly. Instead, an access token check was added before the vulnerable code paths. See the code below for the initialize context IOCTL, handled by the function FSRendezvousServer::InitializeContext
:
令我失望的是,导致该漏洞的逻辑错误在 2024 年 6 月的安全更新中得到了修复,但并未直接得到解决。相反,在易受攻击的代码路径之前添加了访问令牌检查。请参阅下面的代码了解初始化上下文 IOCTL,由函数FSRendezvousServer::InitializeContext
:
Code Block 9: IOCTL function begins with a feature flag check and checks if calling process is a frame server
代码块 9:IOCTL 函数以功能标志检查开始,检查调用进程是否是帧服务器
The function above begins by checking if a feature is enabled. This is likely the feature flag corresponding to the patch. If the feature is enabled, KsIsCurrentProcessFrameServer
must return TRUE, otherwise NTSTATUS
value STATUS_ACCESS_DENIED
is returned.
上面的函数首先检查某个功能是否已启用。这可能是与补丁相对应的功能标志。如果启用该功能, KsIsCurrentProcessFrameServer
必须返回 TRUE,否则返回NTSTATUS
值STATUS_ACCESS_DENIED
。
Let’s take a look at KsIsCurrentProcessFrameServer
:
让我们看一下KsIsCurrentProcessFrameServer
:
Code Block 10: KsIsCurrentProcessFrameServer performing a SID check on the calling thread’s access token
代码块 10:KsIsCurrentProcessFrameServer 对调用线程的访问令牌执行 SID 检查
This function checks the calling thread’s token against two specific security identifiers (SIDs). The SIDs correspond to a token in group NT SERVICE\FrameServer
. If either of the SIDs are enabled in the calling thread’s access token, then the vulnerable function code can execute.
此函数根据两个特定的安全标识符 (SID) 检查调用线程的令牌。 SID 对应于组NT SERVICE\FrameServer
中的令牌。如果在调用线程的访问令牌中启用了其中一个 SID,则可以执行易受攻击的函数代码。
After seeing this, I suspected there likely was an Administrator to Kernel bug still present. Ultimately, the memory corruption problems were not addressed at all. I confirmed this by making a slight modification to my original exploit: An administrator user can start the FrameServer
service, open a handle to the service and create the exploit process using the handle. I was able to obtain a full kernel R/W primitive on a fully patched system.
看到这个之后,我怀疑可能仍然存在管理员到内核的错误。最终,内存损坏问题根本没有得到解决。我通过对原始漏洞进行轻微修改来确认这一点:管理员用户可以启动FrameServer
服务,打开该服务的句柄并使用该句柄创建漏洞利用进程。我能够在完全修补的系统上获得完整的内核 R/W 原语。
While Microsoft does not consider Administrator to Kernel to be a security boundary, similar bugs have been used by threat actors to gain a kernel R/W primitive and use it for EDR blinding and rootkit operations. If you’re interested in what kind of things can be done with this primitive, check out my BlackHat talk alongside FuzzySec.
虽然 Microsoft 不认为管理员到内核是安全边界,但威胁行为者已使用类似的错误来获取内核 R/W 原语并将其用于 EDR 致盲和 rootkit 操作。如果您对这个原语可以完成哪些事情感兴趣,请查看我的BlackHat 演讲以及 FuzzySec。
Conclusion and Next Steps
结论和后续步骤
This post focused on the vulnerability research part of my Pwn2Own endeavor, which consisted of finding a 0-day kernel vulnerability that can be exploited for privilege escalation. This post outlines the journey: getting inspired by other research, failing to find a bug, picking a new angle, finding something suspicious, and then finally pinpointing where the vulnerability lives. Now that a bug has been identified and there’s a use-after-free primitive, the rest should be straightforward, right? Microsoft seems to think so, they rated this bug “Exploitation More Likely” with attack complexity “low”. Are they right? I’ll cover that, the exploitation strategy, and unveil the meaning of the series title, in the next part!
这篇文章重点介绍了我的 Pwn2Own 工作中的漏洞研究部分,其中包括寻找可用于提权的 0day 内核漏洞。这篇文章概述了整个旅程:受到其他研究的启发,未能找到错误,选择新的角度,发现可疑的东西,然后最终查明漏洞所在的位置。现在已经发现了一个错误并且有一个释放后使用原语,其余的应该很简单,对吧?微软似乎也是这么认为的,他们将这个漏洞评为“利用可能性更大”,攻击复杂性“低”。他们是对的吗?我将在下一部分中介绍这一点,即利用策略,并揭示该系列标题的含义!
References 参考
- https://securityintelligence.com/x-force/critically-close-to-zero-day-exploiting-microsoft-kernel-streaming-service
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30089
- https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2023/CVE-2023-36802.html
- https://whereisk0shl.top/post/isolate-me-from-sandbox-explore-elevation-of-privilege-of-cng-key-isolation
- https://www.osr.com/nt-insider/2017-issue2/handling-cleanup-close-cancel-wdf-driver/
- https://www.csoonline.com/article/1311082/north-koreas-lazarus-deploys-rootkit-via-applocker-zero-day-flaw.html
Acknowledgements 致谢
Andréa Piazza, for the amazing diagrams
Andréa Piazza ,令人惊叹的图表
Emma Kirkpatrick, for patiently explaining the Windows security model to me
Emma Kirkpatrick ,耐心地向我解释 Windows 安全模型
原文始发于securityintelligence:Racing Round and Round: The Little Bug That Could