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 validationKeyA7B8C9...很长一串固定字符 decryptionKeyD0E1F2...另一串固定字符 validationSHA1 decryptionAES / /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 CloudSitecore Content HubSitecore CDPSitecore PersonalizeSitecore 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 validationKeyYOUR_NEW_GENERATED_VALIDATION_KEY_HERE decryptionKeyYOUR_NEW_GENERATED_DECRYPTION_KEY_HERE validationHMACSHA256 !-- 建议使用更安全的算法 -- decryptionAES / /system.web第三步加密web.config关键步骤仅仅替换密钥还不够。如果攻击者已经通过其他方式如文件上传漏洞能够读取你的web.config文件他们依然能看到新的密钥。因此必须对web.config中包含机器密钥的部分进行加密。使用aspnet_regiis工具这是.NET Framework自带的工具。以管理员身份打开命令提示符。导航到.NET Framework对应版本的目录例如C:\Windows\Microsoft.NET\Framework64\v4.0.30319\。执行以下命令假设你的网站物理路径是D:\WebSites\MySitecoreSiteaspnet_regiis -pef “system.web/machineKey” “D:\WebSites\MySitecoreSite” -prov “DataProtectionConfigurationProvider”这个命令会使用Windows数据保护APIDPAPI加密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环境进行渗透测试和安全代码审计主动发现配置错误和潜在漏洞。