TL; DR
· 一些供应商因在其产品中包括或遗留了可能被攻击者用来进行横向移动、规避杀软查杀、绕过和持久性的注册表而臭名昭着。
· 可以枚举 CLSID 子项(LocalServer32 和 InprocServer32)来发现遗留的没有用的二进制引用。
· 有趣的是,可以使用以下命令调用(' 调用 ')CLSID:
rundll32.exe -sta {CLSID}
· 防御性建议:删除后清除一些软件配置项(例如 unregister),监视可疑事件(例如 rundll32.exe 的使用情况),并实施强大的应用程序白名单(AWL)策略规则。
背景
以前,我在博客中介绍了一种DCOM 横向移动的技术,该技术利用了 Windows 2008/2012 主机上的注册表类标识符(CLSID)子键值中引用的不存在的丢失文件。在看到该技术的影响后,COM(组件对象模型)和键值路径劫持的整个概念对我来说变得更加迷人。因此,我决定重新研究 CSLID,LocalServer32 和 InprocServer32,希望能发现更有趣的东西。
在这篇文章中,我们将讨论:
· CLSID,LocalServer32 和 InprocServer32 的用途
· 枚举 LocalServer32 和 InprocServer32 键以及缺少键引用的略微改进的方法
· DCOM 横向运动方法
· Rundll32 和 CLSID 滥用
· 几个防御性建议
让我们进一步深入 ……
CLSID,LocalServer32 和 InprocServer32 上的快速入门
大多数 COM 类都在操作系统中注册,并由表示注册表中的类标识符(CLSID)的 GUID 标识(通常在 HKCR CLSID 或 HKCU Software Classes CLSID 下)。在 COM 类的实现背后是在 CLSID 下的注册表项中引用的 " 服务器 "(某些二进制文件)。LocalServer32 键表示可执行(exe)文件的路径,InprocServer32 键表示动态链接库(DLL)文件的路径。
在注册表中,CLSID 结构看起来像下图这样:
LocalServer32
InprocServer32 的
* 参考:CyberReason 的 Philip Tsukerman(@PhilipTsukerman)滥用 DCOM 技术的新横向移动技术
枚举 LocalServer32 / InprocServer32 键值并查找废弃的二进制引用
在 Windows 操作系统中,有许多 COM 类,并且在 LocalServer32 / InprocServer32 的数据字段中废弃的二进制路径的引用的数量是由以下几个因素造成的:
· 操作系统版本,家族和功能
· 第三方软件(安装后 / 卸载后)
· (之前的)DLL / COM 注册
要找到这些废弃的引用路径,请考虑以下几个常规的步骤:
· 枚举所有 LocalServer32 和 InprocServer32 的值找到引用二进制文件的路径
· 格式化二进制文件的路径并删除参数和开关(如果适用)
· 验证二进制文件的路径是否存在并找到相应的废弃文件
让我们使用以下 PowerShell 代码段枚举所有 LocalServer32 键值:
$inproc = gwmi Win32_COMSetting | ?{ $_.LocalServer32 -ne $null } $inproc | ForEach {$_.LocalServer32} > values.txt
在这种情况下(在 Win2k12 R2 机器上),我们将输出内容重定向到文件(values.txt)中,这样可以方便的编辑命令参数和开关。
格式化文件后,我们可以使用以下代码段找到可能缺失的值:
$paths = gc .values.txt foreach ( $p in $paths ) {$p;cmd /c dir $p > $null}
在我们的测试用例中,我们可以看到以下结果有一些与上一篇文章中看起来很熟悉的内容:
InprocServer32
你可能会发现更多具有 InprocServer32 键的 Registry CLSID 类。从 System32 目录,我们可以运行以下代码片段而不必担心格式化后的枚举结果(由很多输出):
$inproc = gwmi Win32_COMSetting | ?{ $_.InprocServer32 -ne $null } $paths = $inproc | ForEach {$_.InprocServer32} foreach ( $p in $paths ) {$p;cmd /c dir $p > $null}
* 注意:在运行上述代码时你可能需要喝一杯咖啡,因为这可能需要几分钟时间。另外,请考虑将此输出重定向到文件以便于后续的分析。
在我的一个 Win10 虚拟机上,这个缺失的引用看起来很有趣:
除了 Windows 本身的一些文件之外,我们还可以看到一些(可信的)供应商软件也留下了一些缺失的文件路径也就不足为奇了。这些废弃的注册表元素不一定表示在非特权用户上下文中存在漏洞(例如,由于目录结构上的 ACL),但这些文件可能为攻击者利用其他方式(例如 COM Hijacks)" 入侵 " 并影响注册表结构创造机会。
重新审视 DCOM 横向运动技术
在 Windows 2008 和 Windows 2012 的基准安装中,C947D50F-378E-4FF6-8835-FCB50305244D 的 COM CLSID 结构具有指向%SystemRoot%system32mobsync.exe 的 LocalServer32 子项。
遵循上面的枚举方法,枚举文件路径,并且在文件位置显然不存在引用的二进制文件。由于这个 COM 对象可以远程实例化(当没有锁定时),因此很明显可以滥用于 DCOM 横向移动。
更多信息可以在这篇博文中找到 – 又一种横向运动技术——滥用 DCOM。
滥用注册表 COM CSLID 与 Rundll32
如果你在 Twitter 上关注了我,你可能已经了解这种技术 :- ) 。但是,这个博客是一个更好的记录它的地方。在枚举 Windows 10 计算机上的 LocalServer32 键时,我遇到了这个非常有趣的 CLSID 和 LocalServer32 键值:
%SystemRoot%system32rundll32.exe /sta {fcc2867c-69ea-4d85-8058-7c214e611c97}
-sta(/ sta)开关是指 " 单线程单元 ",它是COM 线程体系结构的一部分。除了有关 COM 的微软官方文档之外,我在 rundll32.exe 中找不到有关 -sta 开关的更多信息。有趣的是,powershell.exe有一个 -sta 开关,用一个单线程单元启动 powershell(在默认情况下,是在版本 2 之后)。当使用相应的 CLSID(或 ProgID,如果可用)调用时,rundll32.exe 中的此开关通过 LocalServer32 或 InprocServer32 加载(' 调用 ')引用二进制文件。我对这块的技术背景的理解仍然不够,但它对于滥用 COM 有一些有趣的含义。
规避 DLL 加载
正如在枚举部分中所提到的,我发现 VMware Workstation 中的注册表工件是从机器卸载软件后遗留下来的。有趣的是,以下 CLSID 和目录结构仍然存在:
文件夹结构也没有软件二进制文件和相关的依赖项。以下 ACL 条目对此文件夹有效:
幸运的是,没有特权的用户不具有写入此目录的能力。但是,我们仍然可以通过将名为 'vmnetbridge.dll' 的恶意 DLL 复制到目录中来影响 InprocServer32 的加载来证明特权用户可以尝试 " 攻击 ":
让我们使用以下命令加载我们的 DLL 有效载荷与相应的 CLSID:
rundll32.exe -sta {3d09c1ca-2bcc-40b7-b9bb-3f3ec143a87b}
当然,此示例在特权上下文中加载,但如果普通用户可以影响 " 已废弃 " 注册表 CLSID 的路径元素,则含义可能会变得非常有趣。
通常,这也可以通过 Run key 或 Scheduled Task 实现可行的持久性机制。
利用 AWL 绕过传统的 COM 劫持
使用合法的 CLSID 引用和注册的程序 ID(ProgID),我们可以在非特权用户的上下文中简单的劫持已注册的 COM 结构。在这个例子中,让我们加载调用远程 COM 脚本的 Casey Smith(@subTee)"scripting.dictionary"COM Hijack reg 文件。这为我们设置了 " squiblydoo" 的 AppLocker 绕过规则(使用默认规则):
很明显,此劫持方式很有效,因为 HKCU 中的 CLSID 值优先于 HKLM 中的 CLSID 值(* 感谢@KyleHanslovan提醒!)。
现在,让我们运行以下 rundll32.exe 命令来调用有影响力的 COM CLSID 并执行 Jscript 代码:
rundll32.exe -sta {00000001-0000-0000-0000-0000FEEDACDC}
更新:
在与 @PhilipTsukerman 讨论有关引导和加载 COM 类的其他方法之后,有一点值得注意,如果有相应的键值,ProgID 可以调用该命令。在这种情况下,"scripting.dictionary" 会被劫持,所以下面的命令也有效:
rundll32.exe -sta "scripting.dictionary"
防御需要考虑的因素
1. 供应商应在卸载实用程序软件时删除(例如取消注册)COM 注册表配置项(和磁盘文件)。此外,供应商不应创建一个指向不存在的二进制文件的 CLSID 二进制路径注册表键值。
2. 网络防御者应该监视一些可疑的主机活动,尤其是对于 rundll32.exe 的使用。 请注意,'sta' 开关可以使用后缀(例如 'stagggg' 或 'stagggggggggggggggggg')与 CLSID 一起成功调用。
3. 企业组织应实施强大的应用程序白名单(AWL)策略并且需要比默认规则更未严格。
结论
感谢你抽出宝贵时间阅读这篇文章!我希望对于相关主题的后续内容能有更有深度的探讨!
| 留言与评论(共有 0 条评论) |