处理 DCOM 加固 - 第一部分

引言

本文结合了软件开发人员和系统管理员的背景撰写。处理这类问题时，充分了解情况非常重要。过去几年中已有大量相关文章，但我认为，如果您发现自己突然在 DevOps 中遇到此问题，一个快速的概述将是有益的。

在这第一篇短文中，我将解释该问题以及您可以用来处理该问题的非侵入性方法。在后续的文章中，我将介绍当本文中的方法均无效且出于各种原因无法获得供应商支持时，需要使用的侵入性方法。这些方法将需要编码。我曾考虑将所有内容放在一篇长文中，但该问题的内容远远不止一篇独立的文章。我不想将所有内容混为一谈。同时，我也不想每次都重复这些信息。

因此，第一部分是现成解决方案的概述。

背景

COM 是一种对象模型技术。本质上，客户端应用程序可以以面向对象的方式使用对象，这些对象可以在客户端应用程序本身中执行代码，也可以在同一计算机上运行的服务器应用程序中执行代码。如果代码在客户端外部运行（或代码在不同的线程设置中运行），则该对象会被代理。这意味着方法调用被序列化并发送到服务器。在那里，它会被解包、处理，然后以相同的方式将结果发送回来。传输仅使用 Windows 消息队列（编辑：我指的是 Win32 消息基础结构，而不是 MSMQ，那是另一种技术），该队列始终在 Windows 本身的安全层控制之下。

DCOM 是一种基于 RPC 的远程处理技术。它扩展了 COM 以在...

为完整起见，我应指出 DCOM 中的 D 表示分布式。COM 代表“组件对象模型”，指的是处理同一台计算机上的对象。当组件位于不同计算机上时，它就成为 DCOM。随着时间的推移，这种区别已经消失，您会发现“DCOM”被用作通用术语。这是有道理的，因为任何组件都可以本地或远程使用，而客户端并不总是知道或关心这一点。从技术角度来看，单独讨论 COM 和 DCOM 会更准确。

DCOM 加固的整个问题**仅**在客户端和服务器运行在不同计算机上时才会出现。如果它们在同一台计算机上。

但是，如果它们在不同计算机上运行，网络就会介入。如今，任何协议都默认使用安全性。一个客户端会在内部网络甚至互联网上发送不安全、可读、匿名的方法调用，这种想法简直是疯了。但您必须记住，DCOM 在 90 年代初非常流行。正如 Raymond Chen 在他的博客文章中所提到的：每当您看到 DCOM 并考虑修复明显问题时，您都需要记住，它必须在内存为 4MB 的 80386 上运行。而且互联网当时还没有像今天这样充满恶意软件的地狱。

那是一个更简单的时代，尽管实现了身份验证，但大多数可用选项都没有意义。通信中有 6 个可用的身份验证级别，可供使用。

身份验证级别	描述
RPC_C_AUTHN_LEVEL_DEFAULT	默认安全身份验证。
RPC_C_AUTHN_LEVEL_NONE	无身份验证。
RPC_C_AUTHN_LEVEL_CONNECT	仅在客户端与服务器建立连接时进行身份验证。
RPC_C_AUTHN_LEVEL_CALL	每次服务器接收 RPC 时进行身份验证。
RPC_C_AUTHN_LEVEL_PKT	每次服务器接收来自客户端的数据时进行身份验证。
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY	身份验证，确保数据包中的数据未被修改。
RPC_C_AUTHN_LEVEL_PKT_PRIVACY	包括所有先前的身份验证级别，并加密每个 RPC 调用的值。

RPC_C_AUTHN_LEVEL_DEFAULT 表示将使用通过 DCOMCnfg 配置的系统默认设置。使用此设置的应用程序也是最容易修复的，而无需修改应用程序本身。

RPC_C_AUTHN_LEVEL_NONE 仅用于在匿名环境（例如互联网或工作组环境）中使用 DCOM。回顾今天，这和石棉天花板一样没有意义。

RPC_C_AUTHN_LEVEL_CONNECT 曾经是默认设置，无论是在 DCOMCnfg 中还是在程序员甚至费心调用 CoInitializeSecurity 的应用程序中。许多服务器都建议明确使用“连接”级别安全性。这是有道理的，因为从用户/管理员的角度来看，软件实现了访问控制，并且软件将根据用户帐户工作（或不工作）。当然，实际传输仍然不安全，没有任何数据包隐私或恶意软件对策的开销。但在应用程序级别，访问管理是完全正常工作的。

在我看来，RPC_C_AUTHN_LEVEL_CALL 和 RPC_C_AUTHN_LEVEL_PKT 没有意义。它们并没有真正改变整体安全影响。与 RPC_C_AUTHN_LEVEL_CONNECT 相比，仍然没有增加隐私。仍然无法避免篡改数据包。同时，与 RPC_C_AUTHN_LEVEL_CONNECT 相比，也没有增加安全性，因为任何能够一次性攻破身份验证的攻击者都可以再次做到。在我多年的软件开发生涯中，我从未遇到过这两个身份验证级别。

RPC_C_AUTHN_LEVEL_PKT_INTEGRITY 是第一个有意义的安全级别，因为它确保每个数据包都防篡改。仍然没有隐私，但至少客户端和服务器可以信任它们的交互。RPC_C_AUTHN_LEVEL_PKT_PRIVACY 的安全性同样高，并额外增加了确保客户端和服务器之间隐私的功能。

DCOM 加固意味着只接受 RPC_C_AUTHN_LEVEL_PKT_INTEGRITY 和 RPC_C_AUTHN_LEVEL_PKT_PRIVACY。较低设置的请求将失败。

最后一点，我应该指出，在处理 DCOM 时，“服务器”和“客户端”的概念相当灵活。客户端应用程序可能希望在服务器应用程序中激活 DCOM 对象，但在许多情况下，服务器应用程序会因此尝试在客户端应用程序中激活 DCOM 对象以处理回调。从 DCOM 的角度来看，可以存在双向的客户端-服务器关系。

服务器加固

在服务器端，加固意味着拒绝不满足最低级别的连接。这是当时的事件时间线。

更新版本	行为更改
2021年6月8日	阶段 1 发布 - 加固更改默认禁用，但可以通过注册表项启用。
2022年6月14日	阶段 2 发布 - 加固更改默认启用，但可以通过注册表项禁用。
2023年3月14日	阶段 3 发布 - 加固更改默认启用，无法禁用。此时，您必须解决环境中加固更改与应用程序之间的兼容性问题。

在可以启用或禁用此设置的阶段，可以使用注册表更改来启用或禁用加固，注册表项为 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat，其中名为 "RequireIntegrityActivationAuthenticationLevel" 的 DWORD 值为 0 表示禁用，1 表示启用。如果未定义此值，则默认为启用。

当服务器拒绝连接时，可以在系统事件日志中看到 EventID 10036、10037 或 10038。

这一部分更改相对简单，因为从服务器级别的角度来看，一切都变得更严格了。服务器本身不必太在意，因为它们不必处理这个问题。它们要么被激活，要么不被激活。当它们被激活时，一切照旧，因为远程处理由 Windows 处理。真正的挑战在于客户端。

客户端级别缓解

有几种可能的解决方法。

供应商

在企业环境中，第一步应该是联系软件供应商，让他们提供支持。但这并非总是可能。许多供应商在其应用程序仍在使用时就已倒闭。尤其是在商业领域，应用程序的生命周期可以长达数十年。在这种情况下，您仍然需要应对。

更改默认设置

如果应用程序在没有直接通过 CoInitializeSecurity 或间接通过 CoCreateInstanceEx 指定安全级别的情况下使用 DCOM，系统将尝试使用为该特定 DCOM 对象指定的身份验证级别。如果未为特定对象指定身份验证级别，则将使用 DCOMCnfg 中配置的系统默认值。

但是，这假设客户端应用程序本身没有在任何地方初始化安全设置。如果它初始化了，那么这将覆盖所有这些配置值。在这种情况下，您只有两个选择：联系供应商请求更新应用程序，或依赖下一节中介绍的自动提升。

客户端侧自动提升

这是迄今为止最方便的方法，而且非常简单。就像 Microsoft 实施了拒绝服务器级别激活请求过低的更改一样，他们在 Windows 中实施了客户端级别的更改，如果所有非匿名客户端的请求身份验证级别过低，则会自动将其提升到最低支持级别。

这里的“非匿名”很重要，因为 DCOM 以前允许匿名远程处理。如果客户端请求被提升到安全的身份验证级别，则无法透明地完成，因为无法进行任何形式的身份验证。匿名 DCOM 现在已成为过去，将无法正常工作。

如果您使用匿名 DCOM 并希望依赖自动提升，唯一的选择是消除匿名性，方法是将客户端和服务器加入同一域和/或将它们配置为使用已知的用户帐户。

除此之外，如果您使用的是 Windows 8.1 或 Server 2012 R2 或更高版本的客户端，此修复程序是万无一失的。只需安装最新的累积更新（2023 年 2 月或更高版本），即可完成。

面向旧系统的客户端侧自动提升

Windows 7 和 Windows 2008R2 有安全汇总可用。但是，存在一个难题。这些系统不仅已经停止支持，而且也已经过了扩展支持期。这意味着除非有非常非常非常充分的理由来支持一个已有 15 年的操作系统，否则 Microsoft 不会修复任何问题。而且，它期望您已购买了扩展支持许可证，以使其值得他们付出努力。没有安装支持许可证，这些更新将无法安装。

如果您处于这种情况并想购买此类许可证，您就倒霉了，因为我找到的各种文章表明 Microsoft 已于 2023 年 1 月停止销售它们。事实上，我发现无论我在 WSUS 中批准什么，客户端每天都会报告，但说它们没有任何已过生命周期结束的更新。

我应该补充一点，我并没有期望以下方法能够奏效。我本以为修补程序只会在符合条件的系统上安装。如果修补程序确实安装了，我愿意以我没有做错任何事情为基础继续进行。

如果您知道需要哪些更新，并且需要按照特定顺序安装，则可以从目录中手动下载实际更新。在我的情况下，我需要 4 个。

1. windows6.1-kb4474419-v3-x64_b5614c6cea5cb4e198717789633dca16308ef79c
2. windows6.1-kb5006749-x64_4934673a816c4c0e5d6c380e0a61428da8aab4ac
3. windows6.1-kb5028264-x64_1142dafe4d79f24f014a975a6012d2bdfea9197d
4. windows6.1-kb5023769-x64_3e40559476ec20b845d0031d316321e99539e140

第一个更新为 Windows 添加了 SHA-2 签名支持，因为最近的更新不再使用旧的签名技术进行签名，所以这是必需的。如果尚未安装此更新，则在继续安装下一个更新之前需要重新启动。更新 2 和 3 是更新服务堆所必需的，服务堆是负责管理 Windows 更新的软件。出于某种原因，我必须同时安装这两个。更新 4 是包含自动提升修补程序的累积更新。

这就是支持许可证又一次困扰我们的地方。手动安装 msu 文件可以正常工作。但是，一旦服务器重新启动，累积修补程序就会被回滚，并且在“控制面板\程序”和“功能\已安装的更新”中只能看到 1 个较旧的累积更新。其余的都已回滚。我怀疑这是因为没有扩展支持许可证。但是，我仍然不明白为什么它一开始会安装。但我认为，如果我无需采取特殊措施就能安装它，那么这是预期的。

您在已安装更新列表中找不到 kb5023769。奇怪的是：重启后短短几分钟内，我的应用程序就工作了。我在等待重启完成时无意中查看诊断窗口时发现了这一点。这让我相信更新已正确安装，直到所有内容最终确定后，Windows Installer 才意识到“呃，等一下，我不认为我应该这样做，在有人发现之前让我们回滚……”。这反过来又让我想到：假设我们可以阻止这种情况发生……

经过一些实验，我发现以下方法。绕过此问题的解决方法是

1. 安装列表中第 4 个更新。
2. 当出现要求重新启动的对话框时，只需关闭对话框而不重新启动。
3. 打开“控制面板” -> “程序”和“功能” -> “已安装的更新”，并验证 kb5023769 是否已安装。这可能需要几秒钟。
4. 打开**管理工具** -> **服务**
5. 禁用“**Windows 模块安装程序服务**”。
6. 禁用“**Windows 更新服务**”。
7. 重新启动计算机。

已安装的更新将不再被删除，因为 TrustedInstaller.exe 无法再启动和管理修补程序。

请注意以下事项：

• 禁用 TrustedInstaller 需要永久性。如果 TrustedInstaller.exe 能够启动，它将再次删除修补程序。如果存在启用 Windows 模块安装程序服务的组策略，则需要有覆盖的 GPO 来确保其保持禁用状态。
• 在禁用 TrustedInstaller.exe 的期间，无法使用控制面板查看已安装的更新。
• 此策略只能用于 1 个修补程序。kb5023769（或其他修补程序）需要重新启动。在重新启动之前，无法安装更多修补程序。但是，必须在下次启动时禁用 TrustedInstaller，以防止它删除 kb5023769。这意味着以后将无法再安装任何更新。由于我们处理的是一个已有 15 年历史、已过扩展支持期且正在生产环境中逐步淘汰的操作系统，这应该不是问题，但需要提及。
• 如果您需要这种级别的技巧才能使事情正常运转，那么您真的应该将其视为上天的指示，表明您需要尽快将您的业务应用程序迁移到现代平台。

关注点

我已经有一段时间没有在这里写文章了。我不写文章是为了内容数量。当我遇到一些能引起我好奇心并让我想要深入研究细节的事情时，我才会写。DCOM 的探索是技术和考古学的有趣交叉。本文只是浅尝辄止，但概述了问题和解决方案。

老实说，我犹豫是否要包含这个解决方法，因为我不确定这是预期的行为。另一方面，可以合理地假设在这种情况下，任何人都在进行迁移，并且只处理这个问题是因为 a) 他们无法阻止服务器加固的推出，b) 并且不负责支持决策。我想，如果您夹在中间，生产系统宕机，而董事会步步紧逼，那么您应该得到您能得到的所有帮助。

不过我很好奇。如果以上信息对您有帮助，我将非常感谢您的反馈以及它如何应用于您的情况。

在下一篇文章（或多篇文章）中，我将探讨在供应商支持不可用、修补程序因任何原因（主要原因是处理旧系统）都不是解决方案，并且您需要采取更激烈的措施时，可能采取的方法。

历史

• 2023 年 10 月 19 日：第一个版本