在探索“ SilverPotato”滥用的 DCOM 对象时,我偶然发现了“ShellWindows”DCOM 应用程序。此应用程序与“ShellBrowserWindows”一样,在攻击性安全社区中以通过管理员权限远程实例化这些对象来执行横向移动而闻名。
然而,我很好奇,想知道它们是否会被标准用户在本地滥用。
DCOM 应用程序“ShellWindows”的应用程序 ID 为 {9BA05972-F6A8-11CF-A442-00A0C90A8F39},配置为以“交互式”用户的身份运行:
该应用程序上设置的权限是默认权限,这意味着交互式用户至少可以在本地启动和激活 DCOM 应用程序:
让我们看一下 DCOM 应用程序是如何配置的,借助类型库,我们可以获得很多有用的信息:
该类由explorer.exe注册,激活器将使用此类。它公开了几种方法:
ShellExecute ()就是我们要找的,因为它允许执行外部命令或应用程序。
现在借助Oleview工具,我们来看看explorer.exe进程中的访问安全性有哪些:
看起来很有希望,经过身份验证的用户具有执行权限(!!!???)
简单回顾一下,我们有这个 DCOM 应用程序模拟交互式用户。它由 explorer 进程托管,该进程向经过身份验证的用户授予执行访问权限。
现在,如果我们可以执行跨会话激活,非特权用户是否可以代表在另一个会话中连接的另一个用户激活该对象并调用该方法来执行任意执行?ShellExecute()
让我们在 PowerShell 中快速完成这个操作😉
我们是用户 1,管理员已连接到会话 2。我们只需使用BindToMoniker()调用激活会话 2 中的 DCOM 对象并执行ShellExecute()方法即可。例如,从管理员那里取回一个反向 shell:
有效!🙂
$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39")
$p=$obj.item(0).document.application
$p.ShellExecute("c:tempreverse.bat", "", "c:windows", $null, 0)
现在到了有趣的部分:我在另一个没有管理员权限的用户身上尝试了这种方法……猜猜发生了什么?
拒绝访问!这确实很奇怪,但快速检查一下访问安全性就可以解释为什么我们被拒绝访问:
在这种情况下,explorer 进程上的 Authenticated Users 权限缺失。如果进程在 Medium 完整性级别下运行,这是用户(即使是管理员组成员,因为已启用 UAC)的标准行为,他们将缺乏该组的权限。
但是,真正的管理员在禁用 UAC 的情况下,所有进程都在高完整性级别(高 IL)下运行,在这种情况下,设置了这些权限!
这显然是一个错误。问题是,这个问题已经存在多久了?以前可能没人发现吗?也许是由于高 IL 的限制?
很难说…
explorer.exe 中还有其他注册类可能被滥用:
我玩了桌面壁纸,并能够更改管理员的桌面背景图像🙂
该案例(显然)已提交给 MSRC,并且该安全漏洞已于 2024 年 7 月补丁星期二修复,其中 CVE-2024-38100被标记为重要 LPE。
现在 explorer.exe 进程的正确设置也适用于高 IL。
你可能想知道为什么我把它称为“假”土豆。最初,我认为可以使用与 *Potato 家族相同的技术来利用它,但事实证明,在这种情况下它有所不同,而且要简单得多🙂
附注:此漏洞与 James Forshaw 在 2018 年报告的漏洞类似,该漏洞已在CVE- 2019-0566中修复
原文始发于微信公众号(Ots安全):“假”土豆 - Windows 文件资源管理器权限提升漏洞 CVE-2024-38100
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论