Sitecore CVE-2025-53690漏洞解析：ASP.NET ViewState反序列化攻击与WeepSteel后门-尧图网络科技

1. 事件概述与核心威胁解析

最近安全圈里一个关于Sitecore的零日漏洞利用事件，让不少使用这个老牌内容管理系统（CMS）的企业安全团队捏了把汗。简单来说，攻击者利用了一个编号为CVE-2025-53690的漏洞，这个漏洞的根源可以追溯到2017年甚至更早的Sitecore官方文档。攻击者通过这个漏洞，成功在受害服务器上部署了一个名为“WeepSteel”的侦察型后门恶意软件。这起事件之所以值得所有运维和安全人员高度关注，不仅仅是因为它涉及一个广泛使用的企业级CMS，更在于其攻击链条的完整性和隐蔽性，完美演绎了一次从初始入侵到持久化控制的经典渗透过程。

这个漏洞的本质，是一个ASP.NET ViewState反序列化漏洞。但有意思的是，它并非ASP.NET框架本身或Sitecore核心代码的缺陷，而是一个典型的“配置错误”导致的漏洞。问题的核心在于一份2017年前的Sitecore部署指南文档。这份文档里，为了方便开发者快速搭建演示或测试环境，提供了一个示例的ASP.NET机器密钥（Machine Key）。这个密钥本意是用于临时环境，但很多管理员在部署生产系统时，可能为了图省事，或者对安全风险认识不足，直接复用了这个公开的、众所周知的示例密钥。这就好比你家大门的锁，用的是一把在五金店橱窗里公开展示的、所有人都知道齿形的钥匙模具，其危险性不言而喻。

攻击者正是利用了这一点。由于他们知晓这个公开的机器密钥，便可以构造出能被服务器验证为“合法”的恶意ViewState数据。当这个恶意ViewState被发送到Sitecore服务器上一个特定的、未对ViewState进行严格验证的端点（/sitecore/blocked.aspx）时，服务器会对其进行反序列化并执行其中包含的恶意代码。整个过程实现了远程代码执行（RCE），并且默认以IIS应用程序池账户（通常是NETWORK SERVICE）的权限运行。这意味着攻击者无需知道任何用户名密码，就能直接让服务器执行他们的指令。

而攻击者投放的载荷WeepSteel，其设计也颇具心思。它不像一些勒索软件那样大张旗鼓地加密文件，也不像传统的木马那样频繁外联。WeepSteel的核心任务是“侦察”和“信息收集”。它会悄悄地收集受感染系统的详细信息，包括主机名、运行的进程列表、磁盘信息、网络配置（如ipconfig /all）、活跃的网络连接（netstat -ano）以及当前用户权限（whoami）。更狡猾的是，它将窃取到的这些数据，伪装成正常的ASP.NET ViewState响应数据包发送给攻击者。这种伪装使得其网络流量在表面上看与网站正常的ViewState交互无异，极大地增加了被传统网络防火墙或入侵检测系统（IDS）发现的难度。攻击者拿到这些信息后，就能清晰地描绘出目标网络的内部分布图，为后续的横向移动和权限提升打下坚实基础。

2. 漏洞深度剖析：CVE-2025-53690的技术原理

要真正理解这个漏洞的危害并有效防御，我们需要深入其技术细节。这不仅仅是一个补丁号，背后是一连串的安全实践教训。

2.1 ASP.NET ViewState与机器密钥（Machine Key）机制

对于不熟悉ASP.NET开发的朋友，我打个比方。ViewState可以看作是ASP.NET WebForms页面为了在无状态的HTTP协议中维持页面控件状态（比如文本框里输入的内容、下拉框选中的项）而采用的一种机制。服务器会把页面的状态信息序列化后，加密并编码成一个名为“__VIEWSTATE”的隐藏字段，随着网页发送给浏览器。当用户提交表单时，浏览器会把这个__VIEWSTATE字段再传回服务器。服务器需要用它来恢复页面状态。

为了保证这个过程中数据的完整性和机密性（防止被客户端篡改或窥探），ASP.NET引入了机器密钥（Machine Key）。机器密钥是一对用于加密和验证的密钥，包含validationKey和decryptionKey。服务器用它们来对ViewState进行签名（防篡改）和可选的加密（防窥探）。关键在于，这个密钥必须在整个Web场（Web Farm）或负载均衡的多台服务器之间保持一致，否则一台服务器生成的ViewState，另一台服务器就无法正确解析，会导致“视图状态验证失败”的错误。

2.2 漏洞产生的根本原因：静态密钥的滥用

Sitecore作为一款企业级CMS，常常需要部署在多台服务器上以实现高可用和负载均衡。因此，在配置文件中设置一个静态的、统一的机器密钥是标准操作。问题就出在这个“静态密钥”的来源上。

2017年之前的Sitecore官方安装和配置指南中，为了方便用户快速启动，直接给出了一个示例的<machineKey>配置节。这个配置节里的validationKey和decryptionKey是明文写死的、固定的字符串。例如，可能长这样：

<system.web> <machineKey validationKey="A7B8C9...（很长一串固定字符）" decryptionKey="D0E1F2...（另一串固定字符）" validation="SHA1" decryption="AES" /> </system.web>

这份文档的本意是：“看，配置项在这里，你需要生成自己的密钥替换掉这些示例值”。但现实情况是，大量管理员和开发者直接复制粘贴了整个配置块到生产环境的web.config文件中，而没有替换其中的密钥值。更糟糕的是，这份包含示例密钥的文档在互联网上被广泛传播和引用。

于是，一个可怕的局面形成了：全球成千上万套Sitecore生产系统，使用着同一个或少数几个众所周知的“示例密钥”。对于攻击者而言，这不再是需要暴力破解或利用复杂漏洞去获取的密钥，而是直接写在“公开说明书”里的通用密码。

2.3 漏洞利用链：从已知密钥到远程代码执行

拥有了有效的机器密钥，攻击者就可以伪造任意合法的ViewState。他们的攻击链非常清晰：

目标定位：攻击者通过扫描互联网，寻找运行旧版本Sitecore（主要是9.0及之前版本）的服务器。/sitecore/blocked.aspx这个端点通常存在且可访问。
载荷构造：攻击者使用已知的示例机器密钥，构造一个特殊的ViewState。这个ViewState内部经过序列化，包含的不再是普通的控件状态数据，而是一段恶意的.NET代码，例如能够下载并执行WeepSteel后门的指令。
漏洞触发：攻击者向目标服务器的/sitecore/blocked.aspx页面发送一个HTTP POST请求，并将恶意构造的ViewState作为参数提交。由于该端点没有对ViewState的源头或内容进行额外的、严格的身份验证，服务器会照常处理。
反序列化与执行：服务器使用web.config中配置的（也就是那个公开的示例）机器密钥，对收到的ViewState进行解密和验证。因为密钥匹配，验证通过。接着，服务器开始反序列化ViewState数据。在这个过程中，内嵌的恶意.NET代码被还原并执行，从而在服务器上实现了远程代码执行（RCE）。

注意：这里有一个非常重要的概念需要厘清。很多人一听到“反序列化漏洞”就认为是BinaryFormatter这类高风险序列化器的锅。但在CVE-2025-53690中，根本原因不是反序列化器本身的不安全，而是验证环节被绕过。因为攻击者拥有了合法的密钥，他们构造的恶意ViewState在服务器看来是“签名有效、来源可信”的。服务器信任了这个数据包，然后才执行了其中的代码。所以，这是一个“因信任验证机制被破坏而导致的代码执行”漏洞，核心在于密钥管理失控。

3. WeepSteel恶意软件：隐匿的侦察先锋

攻击者费尽心机利用零日漏洞，首要部署的却不是直接搞破坏的勒索软件或挖矿木马，而是WeepSteel这样一个侦察后门，这本身就说明了其攻击策略的成熟和耐心。我们来拆解一下WeepSteel的工作原理和特点。

3.1 功能模块与信息收集

根据安全厂商Mandiant的分析报告，WeepSteel是一个功能专注的侦察工具，其主要模块包括：

系统信息收集：获取计算机名称、操作系统版本、系统架构（x86/x64）、当前时区、环境变量等。这是了解目标基础属性的第一步。
进程枚举：列出系统所有正在运行的进程，包括进程ID、名称、内存占用、启动时间等。攻击者借此寻找安全软件（如杀毒进程、EDR代理）、运维管理工具（如RDP客户端、SSH客户端）、数据库服务等，以评估环境安全强度和寻找后续攻击跳板。
磁盘信息枚举：遍历所有逻辑驱动器，获取盘符、类型（固定磁盘、可移动磁盘、网络驱动器）、总空间和可用空间。这有助于判断服务器角色（是Web服务器还是文件服务器）以及是否有有价值的大容量存储。
网络配置窃取：执行类似ipconfig /all的命令，获取详细的网络适配器信息，包括IP地址、子网掩码、默认网关、DNS服务器、MAC地址以及是否启用了DHCP。这是绘制内网拓扑的核心数据。
网络连接探查：执行类似netstat -ano的命令，获取所有活跃的TCP/UDP连接监听端口和已建立的连接，并关联到对应的进程ID。攻击者可以借此发现服务器开放了哪些服务（如数据库端口、远程管理端口），以及它正在与内网哪些其他机器通信，从而发现潜在的攻击路径。

3.2 通信伪装与数据外泄

WeepSteel最狡猾的设计在于其通信方式。它并非创建一个新的、明显的网络连接（如反向Shell），而是将其窃取的数据，伪装成ASP.NET ViewState的合法响应。

数据封装：收集到的系统信息被格式化后，嵌入到一个伪造的ASP.NET ViewState数据结构中。
签名加密：使用与目标服务器相同的（也就是攻击者已知的）机器密钥，对这个包含窃取数据的ViewState进行签名和加密，使其看起来像一个完全合法的服务器响应。
混杂于正常流量：恶意软件将处理好的数据，通过HTTP响应体发送给攻击者控制的服务器。在网络流量分析工具中，这个数据包看起来就像一个普通的网页请求后返回的ViewState更新，极难通过简单的流量特征进行识别。

这种“隐身于协议”的手法，使得WeepSteel能够有效绕过许多基于已知恶意域名、IP或异常端口通信的检测规则。除非安全设备能够深度解密并分析ViewState的内容，否则很难发现异常。

3.3 在攻击链中的角色

WeepSteel扮演的是“侦察兵”和“情报员”的角色。它的成功部署，意味着攻击者已经在内网获得了一个立足点。通过WeepSteel回传的信息，攻击者能够：

评估价值：判断这台服务器是开发机、测试机还是核心生产服务器。
规划路径：根据网络配置和连接信息，规划下一步横向移动的方向（例如，攻击同一网段中IP相邻的数据库服务器）。
规避检测：识别出系统内安装的安全软件，为后续部署更高级的持久化工具（如Earthworm、Dwagent）选择绕过方法。
权限提升准备：通过进程列表，寻找可能以高权限（如SYSTEM、Administrator）运行的服务或进程，为后续的令牌窃取或漏洞利用做准备。

可以说，WeepSteel为后续更大规模的入侵铺平了道路。攻击者不急于求成，而是先摸清环境，这种策略往往能造成更深远、更严重的危害。

4. 完整的攻击链条复现与后续手段分析

理解了漏洞和初始载荷，我们再来梳理攻击者完成一次完整入侵可能采取的后续步骤。这有助于我们建立全局的防御视角。

4.1 第一阶段：初始入侵与侦察（WeepSteel）

如前所述，攻击始于利用CVE-2025-53690部署WeepSteel。此时攻击者获得的是IIS应用程序池账户（如NETWORK SERVICE）的权限。这个权限通常受限，但足以在Web目录写入文件、执行命令进行侦察。

4.2 第二阶段：工具投递与横向移动

在通过WeepSteel摸清环境后，攻击者会投递更多工具以扩大战果。根据报告，主要观察到以下工具：

Earthworm (EW)：这是一个功能强大的网络穿透工具，常用于在受限制的网络环境中建立隧道。攻击者可能用它来将内网其他无法直接访问的服务的端口，代理到公网攻击服务器上，从而绕过边界防火墙的限制，直接访问内网资产。
Dwagent：一个开源的远程访问工具（RAT），功能类似于TeamViewer或AnyDesk的简化版，但完全受攻击者控制。部署Dwagent意味着攻击者获得了一个图形化或命令行的稳定远程控制通道，比单纯的Web Shell更持久、功能更全。
7-Zip：一个合法的压缩工具。攻击者使用它来压缩窃取到的数据（如配置文件、数据库备份、文档等），减小体积以便于外传。

4.3 第三阶段：权限提升与持久化

为了获得更高权限和确保长期控制，攻击者会进行以下操作：

创建本地管理员账户：利用已获得的权限，通过net user命令创建新的本地管理员账户，如报告中提到的asp$和sawadmin。他们通常会禁用这些账户的密码过期策略（net user [username] /expires:never），并为其添加远程桌面（RDP）用户组权限（net localgroup “Remote Desktop Users” [username] /add），以便直接通过图形界面登录。
凭据转储：尝试转储本地存储的密码哈希。常见的方法是使用reg save命令导出SAM和SYSTEM注册表配置单元，然后使用Mimikatz等工具在本地或转移到攻击者机器上提取哈希。获得管理员哈希后，可能进行“哈希传递”攻击，横向移动到其他使用相同本地密码的机器。
令牌模拟：报告中提到了尝试使用GoTokenTheft进行令牌模拟。这是一种窃取高权限进程（如以SYSTEM运行的Windows服务）的安全令牌，然后利用该令牌创建新进程，从而获得SYSTEM权限的技术。
服务持久化：将Dwagent等后门程序注册为Windows系统服务，并设置为开机自动启动。这样即使服务器重启，攻击者的控制通道也会自动恢复。他们通常会给服务起一个具有迷惑性的名称，以规避简单的检查。

4.4 攻击链总结

整个攻击链呈现出高度的专业化和流程化：利用公开漏洞获取初始访问 → 部署轻量侦察后门摸清环境 → 投递专业工具建立隧道和控制 → 提权并建立持久化据点。这是一套标准的APT（高级持续性威胁）攻击手法，目标明确，步步为营。

5. 影响范围与紧急缓解措施

5.1 受影响版本与产品

根据Sitecore官方公告，受CVE-2025-53690影响的版本和产品包括：

Sitecore Experience Manager (XM)
Sitecore Experience Platform (XP)
Sitecore Experience Commerce (XC)
Sitecore Managed Cloud以上产品的9.0及更早版本，如果在部署时使用了2017年前文档中的示例机器密钥，则受到影响。

不受影响的产品包括：

Sitecore XM Cloud
Sitecore Content Hub
Sitecore CDP
Sitecore Personalize
Sitecore OrderCloud
以及Search, Send, Discover等较新的云服务或独立产品。

核心判断标准：不在于你具体用的是哪个版本，而在于你的生产环境web.config文件中，<machineKey>的validationKey和decryptionKey是否是静态的、且来源于公开的示例。即使是10.x版本，如果错误配置了静态密钥，理论上也存在类似风险。

5.2 紧急缓解与修复步骤

如果你正在管理或维护Sitecore环境，请立即采取以下行动：

第一步：立即检查与确认

定位所有Sitecore实例的web.config文件（通常位于网站根目录）。
检查<system.web>节下的<machineKey>配置。
关键：核对validationKey和decryptionKey的值。如果它们是类似A7B8C9...这样看起来像示例的、固定的长字符串，而不是通过自动生成或安全流程设置的随机值，那么你的系统就处于风险之中。

第二步：生成并替换新的唯一机器密钥绝对不要只是简单修改示例密钥的几个字符。必须为每个环境（开发、测试、生产）以及Web场中的每一台服务器（如果使用静态密钥）生成全新的、强随机的密钥。

推荐方法（自动化）：使用ASP.NET提供的工具或PowerShell命令在线生成。例如，在服务器上打开IIS管理器，选择服务器节点，在“功能视图”中找到“机器密钥”图标，可以生成新的密钥对。或者使用以下PowerShell命令（需要管理员权限）：
```
# 生成一个128字节（256字符）的验证密钥和一个64字节（128字符）的解密密钥（AES-256） $validationKey = [System.Web.Security.Membership]::GeneratePassword(64, 0) + [System.Web.Security.Membership]::GeneratePassword(64, 0) # 拼接两个64字符的字符串得到128字符 $decryptionKey = [System.Web.Security.Membership]::GeneratePassword(64, 0) Write-Host “validationKey: $validationKey” Write-Host “decryptionKey: $decryptionKey”
```
注意：GeneratePassword方法生成的字符串包含特殊字符，需确保其在XML配置文件中正确转义，或使用其他纯字母数字的生成方法。更稳妥的方式是使用IIS管理器生成。

手动更新：将生成的密钥对，更新到所有受影响服务器的web.config文件的<machineKey>节中。

<system.web> <machineKey validationKey="YOUR_NEW_GENERATED_VALIDATION_KEY_HERE" decryptionKey="YOUR_NEW_GENERATED_DECRYPTION_KEY_HERE" validation="HMACSHA256" <!-- 建议使用更安全的算法 --> decryption="AES" /> </system.web>

第三步：加密web.config（关键步骤）仅仅替换密钥还不够。如果攻击者已经通过其他方式（如文件上传漏洞）能够读取你的web.config文件，他们依然能看到新的密钥。因此，必须对web.config中包含机器密钥的部分进行加密。

使用aspnet_regiis工具：这是.NET Framework自带的工具。
1. 以管理员身份打开命令提示符。
2. 导航到.NET Framework对应版本的目录，例如：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\。
3. 执行以下命令（假设你的网站物理路径是D:\WebSites\MySitecoreSite）：
```
aspnet_regiis -pef “system.web/machineKey” “D:\WebSites\MySitecoreSite” -prov “DataProtectionConfigurationProvider”
```
这个命令会使用Windows数据保护API（DPAPI）加密machineKey节，加密后的内容在web.config中会变成类似<EncryptedData>...</EncryptedData>的密文，只有当前服务器上的当前用户才能解密。这对于单服务器环境是有效的。
对于Web场（多服务器）：如果有多台服务器负载均衡，所有服务器需要能解密同一个加密的web.config。这时需要使用基于RSA密钥容器的加密方式，并在一台服务器上导出密钥容器，然后导入到其他所有服务器。这个过程更复杂，建议参考微软官方文档“How to: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA”。

第四步：全面安全检查与入侵排查完成密钥修复后，应立即假设系统可能已被入侵，并进行全面排查：

日志审计：仔细检查IIS日志、Windows安全日志、应用程序日志，寻找在漏洞公开前后（2025年9月左右）对/sitecore/blocked.aspx端点的异常访问记录，特别是POST请求。
文件系统检查：在Web目录、临时目录（%TEMP%,C:\Windows\Temp）、以及系统根目录下，查找可疑的可执行文件、脚本文件（.ps1, .vbs, .js）、或近期创建的异常文件（如以.aspx为后缀的Web Shell）。注意查找报告中提到的工具名，如earthworm.exe,dwagent.exe,7z.exe（非官方路径的）。
进程与服务检查：使用tasklist或Process Explorer查看有无异常进程。检查Windows服务列表（services.msc），寻找名称可疑或描述异常的新服务。
账户检查：检查本地用户和组（lusrmgr.msc），确认是否有新增的陌生账户，特别是asp$,sawadmin等。检查这些账户是否被加入了管理员组或远程桌面用户组。
网络连接检查：使用netstat -ano查看是否有异常的外联IP和端口。
考虑专业援助：如果发现任何入侵迹象，建议立即隔离受影响系统，并联系专业的安全事件响应团队进行深度分析和清理。攻击者可能已部署了更隐蔽的后门。

6. 长期安全加固建议与最佳实践

修复一个具体的漏洞是“治标”，建立良好的安全运维习惯才是“治本”。针对此次事件，我们可以总结出以下几点长期建议：

严格遵循安全部署指南：永远不要在生产环境中使用示例配置、默认密码或公开的密钥。任何来自文档的示例配置，尤其是涉及密码、密钥、令牌的，都必须替换为自行生成的强随机值。
实施最小权限原则：运行Sitecore的IIS应用程序池账户，应配置为仅具有访问其所需目录和资源的必要权限，避免使用高权限账户（如LocalSystem）。定期审查账户权限。
定期更新与补丁管理：尽管CVE-2025-53690不是通过补丁修复的代码漏洞，但保持Sitecore及其底层框架（.NET, Windows）更新到最新版本，是防范其他已知漏洞的基本要求。建立规范的补丁测试和部署流程。
强化密钥与证书管理：
- 将机器密钥、数据库连接字符串、API密钥等敏感信息，从配置文件中移出，使用安全的密钥管理系统（如Azure Key Vault, AWS Secrets Manager）或受保护的环境变量来存储。
- 对于必须放在配置文件中的密钥，务必使用对应平台提供的加密工具（如ASP.NET的aspnet_regiis）进行加密。
- 建立密钥轮换策略：像轮换密码一样，定期（如每半年或一年）轮换机器密钥。轮换前需确保所有服务器同步更新，并做好用户会话中断的准备（因为ViewState会失效）。
部署纵深防御体系：
- Web应用防火墙（WAF）：在Sitecore服务器前部署WAF，可以配置规则拦截对/sitecore/blocked.aspx等敏感路径的异常访问，或检测ViewState参数中的恶意模式。
- 入侵检测/防御系统（IDS/IPS）：在网络层监控异常流量模式。
- 端点检测与响应（EDR）：在服务器上安装EDR软件，能够检测WeepSteel等恶意软件执行的侦察命令（如whoami,netstat）以及后续的提权、持久化行为。
加强日志记录与监控：启用并集中收集所有服务器和应用的详细日志。配置安全信息和事件管理（SIEM）系统，建立针对异常行为的告警规则，例如：非工作时间对管理端点的访问、短时间内大量执行系统命令、创建新的本地管理员账户等。
定期安全评估：定期对Sitecore环境进行渗透测试和安全代码审计，主动发现配置错误和潜在漏洞。