卡巴斯基 杀毒软件 四川经销商 科汇科技 分享 ToolShell：微软SharePoint中五个漏洞的故事
ToolShell：微软SharePoint中五个漏洞的故事
2025年7月19日至20日，多家安全公司和国家计算机应急响应团队（CERTs）发布了关于本地SharePoint服务器遭主动利用的警报。报告显示，已观测到的攻击无需身份验证，攻击者可借此获得受感染服务器的完全控制权，且这些攻击是通过两个漏洞（CVE-2025-49704和CVE-2025-53771）组成的漏洞链实施的，这两个漏洞被公开命名为“ToolShell”。此外，在同一时间段，微软发布了针对CVE-2025-53770和CVE-2025-53771漏洞的紧急安全补丁，旨在解决此前针对CVE-2025-49704和CVE-2025-49706漏洞所发布修复程序存在的安全绕过问题。此次新的“正式”更新的发布，引发了人们对于攻击者究竟在利用哪些漏洞以及他们是否在使用零日漏洞的困惑。
卡巴斯基的产品主动检测并拦截了与这些攻击相关的恶意活动，这使我们能够收集有关该攻击活动的时间范围和传播情况的统计数据。我们的统计显示，大规模利用始于2025年7月18日，攻击者针对的是全球多个国家的服务器，涉及埃及、约旦、俄罗斯、越南和赞比亚。多个行业的机构均受到了影响，包括政府、金融、制造业、林业和农业领域。
在分析所有与这些攻击相关的工件（包括我们的产品检测到的以及外部研究人员提供的公开信息）时，我们发现了一个POST请求的数据包，据称其中包含这些攻击中使用的恶意载荷。经过我们自己的分析，我们证实该数据包确实包含了我们的技术检测到的恶意载荷，并且向受影响的SharePoint安装发送这一个请求，就足以在那里执行恶意载荷。
我们对该漏洞利用程序的分析表明，它确实依赖于CVE-2025-49704和CVE-2025-49706所修复的漏洞，但只需更改请求中的一个字节，我们就能绕过这些修复措施。
在本文中，我们提供了关于CVE-2025-49704、CVE-2025-49706、CVE-2025-53770、CVE-2025-53771以及一个相关漏洞的详细信息。由于漏洞利用代码已在网上公开，且使用非常简单，风险极大，因此我们建议所有组织安装必要的更新。
漏洞利用
我们的研究始于对与这一波SharePoint服务器攻击相关的POST请求数据包的分析。
漏洞利用的POST请求片段
我们可以看到，这个POST请求的目标是“/_layouts/15/ToolPane.aspx”端点，并嵌入了两个参数：“MSOtlPn_Uri”和“MSOtlPn_DWP”。查看ToolPane.aspx的代码可知，该文件本身并没有包含太多功能，其大部分代码位于Microsoft.SharePoint.dll中Microsoft.SharePoint.WebPartPages命名空间的ToolPane类中。对这个类进行分析后，能够发现与漏洞利用中存在的这两个参数相关的处理代码。然而，在正常情况下，如果不绕过受攻击的SharePoint服务器上的身份验证，就无法访问这个端点。这正是第一个Microsoft SharePoint Server欺骗漏洞（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”，则会导致身份验证绕过。
PostAuthenticateRequestHandler 方法中存在易受攻击的代码（Microsoft.SharePoint.dll 版本 16.0.10417.20018）
上图中显示的代码用于处理登出请求，当登出页面被指定为引荐来源时，该代码也会被触发。当flag6设为false且flag7设为true时，两个可能抛出“未授权访问”异常的条件分支都会被跳过。
该漏洞绕过了未授权访问检查
2025年7月8日，微软发布了一项更新以解决该漏洞，具体措施是增加额外检查，用于检测“ToolPane.aspx”端点在以退出页面作为引用来源时的使用情况。
CVE-2025-49706 修复（Microsoft.SharePoint.dll 版本 16.0.10417.20027）
新增的检查使用不区分大小写的比较来验证请求的路径是否以“ToolPane.aspx”结尾。是否有可能通过使用不同的端点等来绕过此检查？我们的测试表明，此检查很容易被绕过。
CVE-2025-53771
我们仅通过在漏洞利用的POST请求中添加一个字节，就成功绕过了针对CVE-2025-49706漏洞的补丁。绕过该补丁所需做的全部操作，就是在请求的“ToolPane.aspx”路径末尾添加一个“/”。
Bypass for CVE-2025-49706 fix
2025年7月20日，微软发布了一项更新，将此绕过漏洞定为CVE-2025-53771并修复。该修复不再检查“ToolPane.aspx”，而是改为检查请求的路径是否在允许与指定为引用页的登出页面一起使用的路径列表中。
CVE-2025-53771 fix (Microsoft.SharePoint.dll version 16.0.10417.20037)
此允许列表包含以下路径：“/_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的绕过方法可行，整个漏洞利用链竟然也能正常运作！但这就奇怪了——攻击者还利用了另一个微软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属性的获取器触发对该负载的处理。
处理ExcelDataSet的CompressedDataTable属性内容的方法代码，位于DataTable属性的getter中
查看Microsoft.PerformancePoint.Scorecards.Client.dll中ExcelDataSet的DataTable属性的getter代码，我们发现了GetObjectFromCompressedBase64String方法，该方法负责对CompressedDataTable属性内容进行反序列化。以Base64字符串形式提供的数据会被解码、解压缩，然后传递给Microsoft.SharePoint.dll中的BinarySerialization.Deserialize方法。
包含利用CVE-2025-49704（已反序列化）的XML内容的数据集
攻击者利用这种方法提供一个恶意数据集，其反序列化内容如上图所示。该数据集包含一个XML，其中有一个危险类型的元素：“System.Collections.Generic.List`1[[System.Data.Services.Internal.ExpandedWrapper`2[...], 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.SharePoint.Upgrade命名空间中添加新的AddExcelDataSetToSafeControls类来进行缓解。这个类包含修改web.config文件的新代码，并将Microsoft.PerformancePoint.Scorecards.ExcelDataSet控件标记为不安全。
由于SharePoint在安装更新后不会自动执行这段代码，因此要实现安全防护效果，唯一的方法是使用SharePoint产品配置向导工具手动运行配置升级。值得注意的是，CVE-2025-49704的安全指南并未提及这一步骤的必要性，这意味着至少有部分SharePoint管理员可能会跳过它。与此同时，所有安装了该更新但未手动执行配置升级的用户，仍然处于易受攻击的状态。
CVE-2025-53770
2025年7月20日，微软发布了一项更新，其中包含针对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攻击公开披露前就已被证明能有效抵御此类攻击。
卡巴斯基Next及其行为检测组件能主动防御针对这些漏洞的利用行为。此外，它还能够检测到漏洞利用行为以及后续的恶意活动。
卡巴斯基产品通过以下判定结果来识别这些攻击中所使用的漏洞利用程序和恶意软件：
- UDS:DangerousObject.Multi.Generic
- PDM:Exploit.Win32.Generic
- PDM:Trojan.Win32.Generic
- HEUR:Trojan.MSIL.Agent.gen
- ASP.Agent.*
- PowerShell.Agent.*
卡巴斯基网络安全解决方案：
巴斯基端点检测和响应专家以及卡巴斯基管理检测和响应，企业版杀毒软件卡巴斯基客户端授权点扩容，卡巴斯基系统升级项目，巴斯基维护服务，卡巴斯基杀毒软件升级，卡巴斯基防病毒软件licence维护，卡巴斯基杀毒软件升级采购，卡巴斯基杀毒软件续费，卡巴斯基防病毒软件licence，卡巴斯基杀毒软件，卡巴斯基杀毒软件服务采购项目 ， 卡巴斯基安全软件采购项目，巴斯基杀毒软件维保项目，卡巴斯基反病毒软件授权服务项目，卡巴斯基防病毒软件技术服务升级项目，卡巴斯基杀毒软件采购项目，卡巴斯基杀毒软件续费，卡巴斯基反病毒软件许可服务，卡巴斯基网络版杀毒软件项目，卡巴斯基网络版杀毒软件，卡巴斯基防病毒系统工控防病毒模块，卡巴斯基杀毒软件延期维保项目， 卡巴斯基企业版价格， 卡巴斯基企业版特点， 卡巴斯基企业版一年多少钱，卡巴斯基企业版和普通版区别， 卡巴斯基企业版安装教程，卡巴斯基企业版安卓版， 卡巴斯基企业版破解， 卡巴斯基企业版KEY，卡巴斯基企业版英文名
Kaspersky Endpoint Security（KES）
Symantec Endpoint Security Complete（SESC）
服务区域：
四川卡巴斯基 成都卡巴斯基 西藏卡巴斯基 重庆卡巴斯基贵州卡巴斯基 贵阳卡巴斯基 云南卡巴斯基 昆明卡巴斯基
四川synology: 德阳卡巴斯基 绵阳卡巴斯基，攀枝花卡巴斯基，西昌卡巴斯基，雅安卡巴斯基，内江卡巴斯基，资阳卡巴斯基，南充卡巴斯基，眉山卡巴斯基，乐山卡巴斯基，自贡卡巴斯基 泸州卡巴斯基 广元卡巴斯基 遂宁卡巴斯基 宜宾卡巴斯基 广安卡巴斯基 达州卡巴斯基 雅安卡巴斯基 巴中卡巴斯基 资阳卡巴斯基 攀枝花卡巴斯基 凉山彝族自治州卡巴斯基 甘孜藏族自治州卡巴斯基 阿坝藏族羌族自治州卡巴斯基，
卡巴斯基 续费，
