利用DCOM OXID解析中继Kerberos认证

最近，针对我近10年前向微软报告的DCOM认证漏洞，出现了一些进一步利用的优秀研究。通过诱导DCOM认证，可以将其中继到网络服务（如Active Directory证书服务（ADCS）），以提升权限，并在某些情况下获得域管理员访问权限。这项新研究的重要区别在于，通过滥用安全配置更改或过度授予组访问权限，将DCOM认证滥用从本地访问（如许多Potato攻击）扩展到完全远程。

这篇短文直接基于Tianze Ding在Blackhat ASIA 2024演讲中的第36张幻灯片，其中提到了尝试从初始OXID解析器中继Kerberos认证。幻灯片指出，在OXID解析过程中无法中继Kerberos认证，因为无法控制用于认证的SPN（服务主体名称）。它总是设置为RPCSS/MachineNameFromStringBinding。虽然可以在标准OBJREF结构中控制字符串绑定，但RPCSS忽略安全绑定，因此无法像稍后的对象RPC调用那样指定SPN。

这一描述引起了我的兴趣，因为我认为这不正确。只需滥用我原始Kerberos中继博客文章中描述的一个“特性”。具体来说，Kerberos SSPI支持一种特殊的SPN格式，其中包括封送的目标信息。这是我在尝试查看是否可以从SMB协议中继Kerberos时发现的，SMB客户端会调用SecMakeSPNEx2 API，进而调用CredMarshalTargetInfo来构建一个附加在SPN末尾的封送字符串。如果Kerberos SSPI看到这种格式的SPN，它会计算封送数据的长度，从SPN中剥离该部分，并继续使用新的SPN字符串。

实际上，这意味着可以构建形式为CLASS/的SPN，Kerberos将使用CLASS/进行认证。这种行为的有趣之处在于，如果组件来自我们正在认证的服务器的hostname，那么最终可以将用于认证的SPN与用于通信的hostname解耦。这正是我们在这里得到的，MachineNameFromStringBinding来自不受信任的源，即我们指定的OBJREF。我们可以以这种特殊格式指定机器名称，这将允许OXID解析器与hostname为的服务器通信，但使用RPCSS/进行认证，后者可以是任何我们喜欢的内容。

这有一些重要的注意事项。首先，机器名称不能包含任何点，因此必须是内网地址。这是因为几乎不可能构建一个表示有效完全限定域名的有效TARGETINFO字符串。在许多情况下，这会排除使用此技巧，但由于我们处理的是域认证场景，并且Windows DNS服务器的默认设置是允许任何用户在域的DNS区域中创建任意主机，因此这不是问题。

由于DNS协议，此限制还将hostname的最大大小限制为63个字符。如果将完全空的CREDENTIAL_TARGET_INFORMATION结构传递给CredMarshalTargetInfo API，则会得到最小有效目标信息字符串，长度为44个字符。这仅剩下19个字符用于SERVER组件，但这也不应该是一个大问题。由于旧的NetBIOS协议，Windows组件名称通常限制为15个字符，并且默认情况下SPN以这些短名称形式注册。最后，在我们的情况下，虽然不会显式注册RPCSS SPN，但这是自动映射到HOST类的服务类之一，而HOST类将被注册。

要利用此漏洞，需要执行以下步骤：

1. 通过将目标SPN的hostname附加到最小字符串1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA来构建机器名称。例如，对于SPN RPCSS/ADCS，构建字符串ADCS1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA。
2. 将机器名称注册为域DNS服务器上的主机。将记录指向您控制的服务器，您可以在该服务器上替换TCP端口135上的监听服务。
3. 使用机器名称构建OBJREF，并通过首选方法（如滥用IStorage激活）诱导OXID解析。
4. 对诱导的Kerberos认证执行一些有用的操作。

根据这些信息，我自己进行了一些测试，Andrea也使用SilverPotato进行了检查，似乎有效。当然有限制，最大的限制是安全绑定被忽略，因此OXID解析器使用Negotiate。这意味着Kerberos认证将始终以至少启用完整性的方式进行协商，这使得认证在大多数情况下无用，尽管它可以用于ADCS的默认配置（我认为）。