在2022年7月之前的Windows上,一个用于实现任意读写的内核漏洞-网络攻防学习社区-安全圈子-FancyPig's blog

在2022年7月之前的Windows上,一个用于实现任意读写的内核漏洞

项目地址

https://github.com/realoriginal/angryorchard

目录

概括

ANGRYORCHARD 是利用 NtUserHardErrorControl 调用在 Microsoft Windows 7 到 11 上实现任意 R/W 的概念证明。该错误本身适用于 Windows 7 到 11 的所有版本,并且在没有第三方的情况下,在较新版本的 Windows 上不再容易访问由于James Forshaw描述的 KnownDLLs 错误和itm4n在 2022 年 7 月开发的 PoC的服务而导致的派对问题。该错误本身位于 CSRSS 中,因此任何获取 CSRSS 访问权限的方法都将允许攻击者利用受影响的问题。

概念验证设计为 ReflectiveDLL,必须注入特权 SYSTEM 进程才能正常运行。执行后,漏洞将根据版本将漏洞直接注入 CSRSS,或者提升到 PPL 以注入漏洞代码(如果可以的话)。一旦代码被注入,漏洞利用将调用NtUserHardErrorControl 将初始漏洞利用阶段线程的 KTHREAD.PreviousMode 递减为 0

分析

该错误本身存在于 win32k 系统调用 NtUserHardErrorControl 中,它处理传递给它的任意句柄的方式。据观察,当调用 NtUserHardErrorControl 且控制代码设置为HardErrorDetachNoQueue时,函数NtUserHardErrorControl,xxxHardErrorControlxxxRestoreCsrssThreadDesktop将不会在调用之前对句柄执行任何验证CloseProtectedHandle(后来的 ObfDereferenceObject )

e7ecc3be44123202

 

演示 HardErrorDetachNoQueue 到 xxxRestoreCsrssThreadDesktop 的控制流

db546b2a3d123223

 

演示在 CSRSS 中导致实际“错误”的原因

幸运的是,无论如何对我来说,实现提升相对微不足道。我观察到,当执行从用户模式到内核模式的转换时,线程的 PreviousMode 被认为是调用者是否来自内核模式的有效指示符。因此,通过传递 KTHREAD 对象的 PreviousMode 字段的地址,并考虑到 OBJECT_HEADER 中将被递减的相应成员的偏移量,我能够成功地强制将当前线程(最初设置为UserMode)的 PreviousMode 递减为KernelMode

有了这个新特权,我可以像内核调用者一样轻松地使用可用的系统调用,而无需进行所有验证检查,而这些验证检查以前会阻止我与内核内存(例如虚拟内存,甚至\Device\PhysicalMemory对象的物理内存)进行交互. 有了这个,我们甚至可以注入一个未签名的 rootkit,而不管配置的 HVCI/VBS ;)。

请登录后发表评论

    没有回复内容