随着攻击手段不断演变,微软不仅致力于响应漏洞,还积极预测并缓解整个威胁类别。文件系统重定向攻击一直是权限提升的持久载体。为此,我们在Windows 11中开发并部署了名为RedirectionGuard的新缓解措施。本文概述了RedirectionGuard如何通过阻止不安全连接点遍历来主动关闭主要攻击面,强化我们“设计即安全”原则的承诺,并减轻开发者和防御者的负担。
当具有特权的本地Windows服务访问包含重定向的文件路径而未察觉时,问题就会出现。例如,一个服务可能使用临时文件夹C:\MyService,在其中存储一些数据文件。完成后,该服务以SYSTEM级别权限删除C:\MyService中的所有内容。但如果非特权用户将MyService文件夹替换为指向C:\Windows\System32的连接点C:\MyService呢?现在,当服务清理其临时目录时,它会跟随连接点并删除C:\Windows\System32中的文件,损坏重要系统文件。
文件系统攻击和缓解措施并非新概念。一种先前常见的攻击方法涉及硬链接,恶意地将文件操作从一个目标文件重定向到同一卷上的另一个文件。然而,通过要求硬链接创建者对目标文件具有WRITE_ATTRIBUTES权限,这种技术已得到很大缓解。
对象管理器符号链接只能通过对象管理器路径直接访问,而大多数本地Windows服务不接受这种路径。否则,文件操作必须首先通过另一个重定向原语(如连接点)指向对象管理器。符号链接虽然强大,但需要管理员权限或开发者模式才能创建,因此标准用户无法使用。
连接点仍然是最大的现有漏洞。在沙箱之外,标准用户可以创建它们并目标系统上的任何文件夹。此外,它们可以与其他形式的重定向(如对象管理器符号链接)结合使用,以有效地重定向文件夹和文件。
原语 | 限制和缓解措施 |
---|---|
硬链接 | 只能目标文件;目标必须在同一卷上;创建者必须对目标具有WRITE_ATTRIBUTES访问权限 |
对象管理器符号链接 | 源必须在对象管理器命名空间中,但目标可以在文件系统或对象管理器命名空间中的任何位置;当创建者被沙箱化时,沙箱外的进程将无法跟随从沙箱内创建的任何链接 |
符号链接 | 创建者必须具有管理员权限或必须启用开发者模式 |
连接点 | 本身只能目标文件夹;创建者必须对源具有FILE_WRITE_DATA或FILE_WRITE_ATTRIBUTES访问权限;源目录必须为空;当创建者被沙箱化时,它们还必须对目标目录具有FILE_GENERIC_WRITE访问权限 |
鉴于硬链接缓解的成功,对连接点应用类似方法可能看起来很简单。毕竟,当沙箱化时,连接点的创建者已经需要对连接点的目标目录具有FILE_GENERIC_WRITE访问权限。那么,为什么不对从沙箱外创建的连接点也要求对目标目录具有FILE_GENERIC_WRITE访问权限呢?挑战在于连接点在Windows上的典型使用方式。虽然硬链接通常目标创建者已经具有完全访问权限的文件,但连接点用于更多样化的场景。广泛要求对目标目录具有FILE_GENERIC_WRITE会破坏太多有效场景。
为了创建可行的解决方案,有必要具体定义问题。在这种情况下,攻击场景如下:
由于这是基于文件系统的权限提升攻击,攻击者必须影响与文件系统交互并具有执行特权操作权限的程序,这些操作他们自己无法执行。这限制了受潜在缓解措施影响的程序数量,主要是以管理员或SYSTEM权限运行的Windows服务。在多用户机器上以其他用户身份运行的程序也可能有一定兴趣。
符合这些条件的程序可能容易受到其他不利用连接点的文件系统攻击类型的影响。例如:
2024年,MSRC发布了42个路径重定向漏洞的CVE。在这些案例中,只有10/42涉及攻击者完全控制文件路径、可以利用相对路径遍历或服务模拟被入侵用户的场景,使它们成为总体上的少数。其余32个案例依赖攻击者创建的连接点来利用服务。鉴于这种细分,将缓解措施范围限定在攻击者尚未通过其他方式任意控制文件操作目标的情况下是合理的。
总结威胁模型,缓解措施假设攻击者具有以下权限和访问权限:
上述攻击者在利用后的一般目标:
缓解措施无法防止不依赖连接点或访问远程路径的漏洞利用,因此对攻击场景施加以下限制:
为了缓解定义威胁模型内的文件重定向漏洞,RedirectionGuard(一种新的连接点缓解措施)必须在攻击者试图恶意重定向文件操作时阻止连接点遍历。然而,它还必须通过允许尽可能多的安全连接点遍历来最小化回归。
因此,只有在满足以下两个条件时,连接点遍历才会被阻止:
当连接点被创建或修改时,创建者/修改者的权限级别存储在文件的仅管理员备用数据流中。当进程启用Redirection Guard时,该进程将仅跟随“受信任”的连接点,这些连接点是以下之一:
这种设计缓解了定义威胁模型内的所有连接点文件重定向漏洞。回想一下先前服务删除某些攻击者控制的临时目录中所有文件的示例。以前,服务必须仔细检查文件路径上的所有文件夹是否有任何形式的重定向。这些检查必须在每个文件操作周围执行,花费大量开发时间,减慢程序速度并增加代码大小。攻击者重定向文件操作的唯一方式是通过连接点,因此启用缓解措施后,攻击者创建的任何连接点都将被标记为不受信任并导致文件操作失败。通过简单地添加几行代码启用缓解措施,开发者可以保护其程序中的所有文件操作免受路径重定向错误的影响。
如前所述,许多进程不会从启用此缓解措施中受益,因为它们要么不以提升的权限运行,要么不以可 exploitable 的方式与文件系统交互。为避免潜在的兼容性问题,缓解措施是选择加入的。重点是在具有文件系统重定向漏洞历史的组件中首先启用缓解措施。用户配置文件服务、AppX部署服务和安装程序服务(路径重定向CVE的三大来源)已在Windows Insider版本中启用了缓解措施。
为程序启用缓解措施的最简单方法是通过代码使用SetProcessMitigationPolicy API。它可以在审计模式下启用以在事件日志中记录违规,或在强制执行模式下启用以阻止连接点遍历。以下是程序可能如何执行此操作的示例:
ULONG
SetProcessMitigationMode(
_In_ MODE_OPTION Option
)
{
ULONG Error = ERROR_SUCCESS;
PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY ReparsePointPolicy = {0};
if (Option == MODE_OPTION::Enforce) {
ReparsePointPolicy.EnforceRedirectionTrust = 1;
} else if (Option == MODE_OPTION::Audit) {
ReparsePointPolicy.AuditRedirectionTrust = 1;
}
if (!SetProcessMitigationPolicy(
ProcessRedirectionTrustPolicy,
&ReparsePointPolicy,
sizeof(PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY))) {
Error = GetLastError();
LogError(Error, "Failed to set image mitigation policy options");
}
return Error;
}
出于测试和研究目的,可以使用James Forshaw的NtObjectManager PowerShell模块查看进程是否启用了缓解措施。例如,要检查PID为1496的运行进程启用的所有缓解措施,请使用命令:
Get-NtProcessMitigations -ProcessId 1496
此命令可以在没有任何进程ID的情况下运行,以列出所有当前运行进程的缓解措施。
RedirectionGuard与通用路径重定向漏洞一起是我们的Windows Insider Preview赏金计划的一部分。RedirectionGuard绕过是在威胁模型范围内仍然可以在启用缓解措施的情况下被利用的路径重定向漏洞。如果您认为找到了路径重定向漏洞或RedirectionGuard绕过,请编写带有概念验证的报告并通过我们的MSRC研究员门户提交。
RedirectionGuard是许多Windows服务依赖的缓解措施,用于防止路径重定向漏洞。随着每个新版本的发布,更多服务正在启用它,关闭了曾经是Windows MSRC案例第二常见来源的攻击向量。
特别感谢Georgios Baltas对缓解措施开发的先前贡献,以及James Forshaw在开发过程中提供的反馈和NtObjectManager PowerShell模块。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。