漏洞利用链分析

我们的研究始于分析与SharePoint服务器攻击浪潮相关的POST请求转储。

漏洞利用POST请求片段

我们可以看到这个POST请求目标是“/_layouts/15/ToolPane.aspx”端点，并嵌入两个参数：“MSOtlPn_Uri”和“MSOtlPn_DWP”。查看ToolPane.aspx的代码，我们发现该文件本身不包含太多功能，其大部分代码位于Microsoft.SharePoint.dll中Microsoft.SharePoint.WebPartPages命名空间的ToolPane类中。查看该类揭示了处理利用中存在的两个参数的代码。然而，在正常情况下访问此端点是不可能的，除非绕过受攻击SharePoint服务器上的身份验证。这就是第一个Microsoft SharePoint服务器欺骗漏洞CVE-2025-49706发挥作用的地方。

CVE-2025-49706

此漏洞存在于Microsoft.SharePoint.dll中的PostAuthenticateRequestHandler方法中。SharePoint要求Internet Information Services（IIS）配置为集成模式。在此模式下，IIS和ASP.NET身份验证阶段是统一的。因此，IIS身份验证的结果直到PostAuthenticateRequest阶段才确定，此时ASP.NET和IIS身份验证方法都已完成。因此，PostAuthenticateRequestHandler方法使用一系列标志来跟踪潜在的身份验证违规。此方法中的逻辑错误使得如果HTTP请求的“Referrer”标头等于“/_layouts/SignOut.aspx”、“/_layouts/14/SignOut.aspx”或“/_layouts/15/SignOut.aspx”（使用不区分大小写的比较），则可以实现身份验证绕过。

易受攻击的代码

上面显示的代码处理注销请求，并在将注销页面指定为引用者时也会触发。当flag6设置为false且flag7设置为true时，可能抛出“未经授权的访问”异常的两个条件分支都被绕过。

利用程序绕过的未经授权访问检查

2025年7月8日，Microsoft发布了一个更新，通过引入额外的检查来检测使用“ToolPane.aspx”端点并将注销页面指定为引用者的情况，从而解决了此漏洞。

CVE-2025-49706修复

添加的检查使用不区分大小写的比较来验证请求的路径是否以“ToolPane.aspx”结尾。是否可以通过使用不同的端点来绕过此检查？我们的测试表明，此检查可以轻松绕过。

CVE-2025-53771

我们能够通过仅向利用POST请求添加一个字节来成功绕过漏洞CVE-2025-49706的补丁。绕过此补丁所需的全部工作是在请求的“ToolPane.aspx”路径末尾添加一个“/”（斜杠）。

CVE-2025-49706修复的绕过

2025年7月20日，Microsoft发布了一个更新，将此绕过修复为CVE-2025-53771。此修复将“ToolPane.aspx”检查替换为检查请求的路径是否在允许与指定为引用者的注销页面一起使用的路径列表中。

CVE-2025-53771修复

此允许列表包括以下路径：“/_layouts/15/SignOut.aspx”、“/_layouts/15/1033/initstrings.js”、“/_layouts/15/init.js”、“/_layouts/15/theming.js”、“/ScriptResource.axd”、“/_layouts/15/blank.js”、“/ScriptResource.axd”、“/WebResource.axd”、“/_layouts/15/1033/styles/corev15.css”、“/_layouts/15/1033/styles/error.css”、“/_layouts/15/images/favicon.ico”、“/_layouts/15/1033/strings.js”、“/_layouts/15/core.js”，并且可以包含管理员添加的其他路径。

在我们在SharePoint调试台上安装2025年7月8日更新测试CVE-2025-49706绕过时，我们注意到一些奇怪的行为。不仅CVE-2025-49706的绕过有效，而且整个利用链也有效！但是等等！攻击者不是使用了额外的Microsoft SharePoint远程代码执行漏洞CVE-2025-49704，该漏洞应该在同一个更新中修复吗？为了理解为什么整个利用链在我们的情况下有效，让我们看一下漏洞CVE-2025-49704以及它是如何修复的。

CVE-2025-49704

CVE-2025-49704是由于XML内容验证不当而存在的不可信数据反序列化漏洞。查看利用POST请求，我们可以看到它包含两个URL编码的参数：“MSOtlPn_Uri”和“MSOtlPn_DWP”。我们可以通过检查Microsoft.SharePoint.dll中GetPartPreviewAndPropertiesFromMarkup方法的代码来查看它们是如何处理的。快速分析显示，“MSOtlPn_Uri”是一个页面URL，可能指向CONTROLTEMPLATES文件夹中的任何文件，而参数“MSOtlPn_DWP”包含称为WebPart标记的内容。此标记包含特殊指令，可用于在服务器上执行安全控件，并且格式与XML非常相似。

攻击者使用的WebPart标记

虽然包含在“MSOtlPn_DWP”参数中的此“XML”本身不包含漏洞，但它允许攻击者实例化Microsoft.PerformancePoint.Scorecards.Client.dll中的ExcelDataSet控件，将CompressedDataTable属性设置为恶意负载，并使用DataTable属性getter触发其处理。

处理ExcelDataSet的CompressedDataTable属性内容的方法代码

查看Microsoft.PerformancePoint.Scorecards.Client.dll中ExcelDataSet的DataTable属性getter的代码，我们找到了负责反序列化CompressedDataTable属性内容的GetObjectFromCompressedBase64String方法。作为Base64字符串提供的数据被解码、解压缩，并传递给Microsoft.SharePoint.dll中的BinarySerialization.Deserialize方法。

利用CVE-2025-49704的数据集与XML内容（反序列化后）

攻击者使用此方法提供恶意数据集，其反序列化内容如上图所示。它包含一个XML，其中包含危险类型的元素“System.Collections.Generic.List1[[System.Data.Services.Internal.ExpandedWrapper2[…], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]”，这允许攻击者借助众所周知的ExpandedWrapper技术在基于.NET框架的应用程序中利用不安全的XML反序列化执行任意方法。实际上，这应该是不可能的，因为Microsoft.SharePoint.dll中的BinarySerialization.Deserialize使用特殊的XmlValidator，通过检查提供的XML中所有元素的类型并确保它们在允许类型列表上来防止此技术。然而，利用程序通过将ExpandedWrapper对象放入列表中来绕过此检查。

现在，为了找出为什么利用程序在我们安装2025年7月8日更新的SharePoint调试台上有效，让我们看看此漏洞是如何修复的。在此补丁中，Microsoft并没有真正修复漏洞，而是通过向Microsoft.SharePoint.Upgrade命名空间添加新的AddExcelDataSetToSafeControls类来缓解它。此类包含修改web.config文件并将Microsoft.PerformancePoint.Scorecards.ExcelDataSet控件标记为不安全的新代码。因为SharePoint在安装更新后不会自行执行此代码，实现安全效果的唯一方法是使用SharePoint产品配置向导工具手动运行配置升级。值得注意的是，CVE-2025-49704的安全指南没有提到需要此步骤，这意味着至少一些SharePoint管理员可能会跳过它。同时，任何安装此更新但未手动执行配置升级的人仍然容易受到攻击。

CVE-2025-53770

2025年7月20日，Microsoft发布了一个更新，对CVE-2025-49704漏洞进行了适当修复。此补丁引入了更新的XmlValidator，现在可以正确验证XML中的元素类型，防止利用此漏洞，而无需配置升级，更重要的是，解决了根本原因，并防止通过Microsoft.PerformancePoint.Scorecards.ExcelDataSet以外的控件利用相同的漏洞。

更新后的XmlValidator中的新类型验证器代码

CVE-2020-1147

熟悉以前SharePoint利用程序的读者可能会觉得漏洞CVE-2025-49704/CVE-2025-53770和攻击者使用的利用程序看起来非常熟悉，并且与较旧的.NET Framework、SharePoint Server和Visual Studio远程代码执行漏洞CVE-2020-1147非常相似。事实上，如果我们比较CVE-2020-1147的利用程序和CVE-2025-49704/CVE-2025-53770的利用程序，我们可以看到它们几乎相同。唯一的区别是在CVE-2025-49704/CVE-2025-53770的利用程序中，危险的ExpandedWrapper对象被放置在列表中。这使得CVE-2025-53770成为CVE-2020-1147的更新修复。

利用CVE-2020-1147的数据集与XML内容

结论

尽管ToolShell漏洞的补丁现在可供部署，但我们评估认为，攻击者将在很长一段时间内继续使用此利用链。我们一直在观察与其他著名漏洞（如ProxyLogon、PrintNightmare或EternalBlue）相同的情况。虽然它们已经已知多年，但许多威胁行为者仍然继续在攻击中利用它们来破坏未打补丁的系统。我们预计ToolShell漏洞将遵循同样的命运，因为它们可以以极低的努力被利用，并允许完全控制易受攻击的服务器。

为了更好地防范像ToolShell这样的威胁，我们作为社区应该从行业先前与关键漏洞相关的事件中吸取教训。具体来说，如今应用安全补丁的速度是打击此类漏洞时最重要的因素。由于这些危险漏洞的公共利用程序在漏洞公告后很快出现，因此尽快安装补丁至关重要，因为即使几个小时的差距也可能产生关键差异。

同时，保护企业网络免受零日利用程序的攻击也很重要，这些利用程序可以在没有可用公共补丁的情况下被利用。在这方面，为机器配备可靠的安全解决方案至关重要，这些解决方案在ToolShell攻击公开披露之前已被证明有效。

具有行为检测组件的Kaspersky Next主动保护免受这些漏洞的利用。此外，它能够检测利用和随后的恶意活动。

Kaspersky产品使用以下判决检测这些攻击中使用的利用程序和恶意软件：

• UDS:DangerousObject.Multi.Generic
• PDM:Exploit.Win32.Generic
• PDM:Trojan.Win32.Generic
• HEUR:Trojan.MSIL.Agent.gen
• ASP.Agent.*
• PowerShell.Agent.*