1. 项目概述一次针对IIS Web Deploy的深度漏洞狩猎最近安全圈里关于IIS Web Deploy的一个新漏洞讨论得挺热编号是CVE-2025-53772。乍一看又是IIS又是反序列化还是远程代码执行这几个关键词凑一块儿对于做企业内网渗透或者红队评估的朋友来说吸引力是拉满了。我花了些时间把公开的零散信息、补丁比对以及自己的测试环境搭建过程梳理了一遍形成这篇分析。这个漏洞的本质是攻击者能够通过精心构造的序列化数据在目标服务器的IIS Web Deploy服务处理过程中触发反序列化最终实现在服务器上执行任意代码。听起来很耳熟对不对没错这又是一起经典的“不安全的反序列化”导致的惨案只不过这次发生在微软的官方部署工具上。IIS Web Deploy也叫MSDeploy对于.NET开发者或者运维来说应该不陌生。它是个非常强大的工具能同步网站、应用、证书甚至整个服务器配置通常用于自动化部署和迁移。正因为它权限高、功能强一旦出问题危害也极大。这个漏洞影响的是Web Deploy的远程服务接口。在实际场景中很多企业为了自动化CI/CD流水线会开启Web Deploy的远程发布功能这就给漏洞利用提供了入口。攻击者不需要任何身份认证只要网络能通发送一个恶意的请求包就可能直接拿下服务器。对于防守方尤其是那些使用了Web Deploy来自动化部署ASP.NET应用到IIS服务器的团队现在就得立刻行动起来检查自己的环境了。2. 漏洞原理与攻击面深度拆解2.1 反序列化漏洞的通用“套路”与本次特殊性要理解CVE-2025-53772我们得先重温一下反序列化漏洞的通用原理。简单来说序列化是把一个内存中的对象转换成可以存储或传输的字节流的过程比如把一个User对象包含姓名、年龄等属性变成一串XML或者二进制数据。反序列化则是逆过程把这串数据重新“组装”回内存中的对象。漏洞就出在这个“组装”过程中。如果程序在反序列化时盲目地根据数据流中的信息去创建对象、调用其方法而攻击者恰好可以控制这个数据流那么他就可以让程序反序列化出一个恶意的、精心设计的对象。这个恶意对象在构造或者被反序列化完成时会自动执行一些危险操作比如调用Process.Start(“cmd.exe”)来执行系统命令。在.NET世界里这类漏洞常与BinaryFormatter、SoapFormatter、NetDataContractSerializer等序列化器有关尤其是BinaryFormatter它功能强大但极不安全因为它反序列化时会完全信任数据并尝试调用对象的特殊方法如反序列化回调方法。微软官方早已不推荐使用BinaryFormatter处理不受信任的数据。这次CVE-2025-53772的根源很可能就是Web Deploy服务的某个组件在处理来自网络的某些数据时不恰当地使用了这类不安全的序列化器并且没有对输入进行充分的验证和过滤。2.2 IIS Web Deploy 服务架构与脆弱点分析IIS Web Deploy服务MsDepSvc默认运行在8172端口HTTP和8173端口HTTPS。它提供了一套基于SOAP或WMSvc的API供远程客户端如Visual Studio、Azure DevOps调用以执行部署操作。整个通信和数据交换过程涉及复杂的对象传递这就为序列化/反序列化操作提供了土壤。通过对补丁KB5043051等进行逆向比对和公开线索分析漏洞点很可能位于处理特定类型部署请求的代码路径中。例如当处理涉及“同步”、“备份”或“归档”等需要传递复杂配置对象的操作时服务端接收客户端发送的序列化后的任务描述对象。攻击者可以伪装成一个合法的客户端但发送一个被“污染”的序列化数据包。这个数据包里包裹的不是正常的任务描述而是一个经过特殊构造的Object其内部链Gadget Chain在反序列化时会被自动触发最终导致代码执行。注意这里的“Gadget Chain”指的是存在于目标系统.NET框架或应用程序集中的一系列类这些类像拼图一样当它们以特定顺序被反序列化时就能组合成完成恶意操作的代码路径。寻找和利用这类链是反序列化漏洞利用的核心技术。2.3 漏洞影响范围与实战场景推演这个漏洞的CVSS评分很可能在9.0以上高危或严重级别因为它具备远程、无需认证、代码执行三大特征。影响版本主要涵盖安装了Web Deploy 3.5或3.6的Windows Server系统特别是搭配IIS 7.5及以上版本的环境。很多云服务器、企业内部的应用发布服务器都可能中招。在实战攻击场景中攻击者的路径非常清晰信息收集通过端口扫描8172/8173或网络空间搜索引擎如Shodan、Fofa寻找暴露在公网或内网的Web Deploy服务。搜索关键词可以是port:8172或title:”Web Deployment Agent Service”。漏洞探测发送一个无害的、但能触发反序列化异常的数据包通过返回的错误信息或延时判断服务是否存在以及是否未打补丁。利用链构造根据目标服务器的.NET Framework版本和可能安装的第三方程序集选取或定制合适的反序列化利用链Gadget Chain。经典的如TypeConfuseDelegate、TextFormattingRunProperties或者针对Microsoft.VisualStudio.Text.UI.Wpf等程序集中特定类的链都可能被使用。载荷投递与执行将利用链与最终的恶意代码如反弹Shell的PowerShell命令、加载C#内存马的程序集进行封装生成最终的序列化Payload通过Web Deploy的服务接口发送出去。权限维持成功执行代码后通常获得的是NT AUTHORITY\SYSTEM或IIS AppPool\DefaultAppPool等高权限攻击者会进一步植入后门、横向移动或窃取数据。对于防守方最直接的威胁就是你的自动化发布通道可能成了攻击者直达核心业务服务器的“高速公路”。3. 漏洞复现环境搭建与关键步骤解析警告以下所有操作请在完全隔离的虚拟机或实验室环境中进行严禁对任何非授权系统进行测试。本文仅用于安全研究与学习。3.1 靶机环境配置为了复现和分析这个漏洞我们需要搭建一个未打补丁的、开启了Web Deploy远程管理服务的Windows Server环境。操作系统与IIS安装我选择使用Windows Server 2019 Datacenter版本安装在VMware虚拟机中。通过服务器管理器添加“Web服务器(IIS)”角色。在角色服务中务必勾选“管理服务”这个服务是Web Deploy远程管理的基础。同时为了模拟真实环境可以一并安装ASP.NET 4.8等相关功能。安装有漏洞版本的Web Deploy前往微软官方下载中心寻找Web Deploy 3.6的特定历史版本。根据漏洞时间推断需要寻找2025年特定月份之前发布的版本。一个可行的方法是下载较旧的Web Platform Installer通过它来安装指定版本的Web Deploy。更直接的方式是从已安装补丁的系统中通过对比文件版本号来确定漏洞版本。例如有漏洞的Microsoft.Web.Deployment.dll版本号可能低于9.0.xx.0具体需参考微软安全公告。我们可以从其他渠道获取该版本的独立安装包。执行安装选择“完整安装”确保安装了远程服务组件。配置Web Deploy远程服务安装完成后打开IIS管理器在服务器节点下会出现“管理服务”图标。双击打开需要勾选“启用远程连接”。这里有一个关键配置点“身份验证”类型。为了复现最严重的无需认证场景我们需要将其设置为“仅限Windows凭据”吗不恰恰相反。如果设置为“仅限Windows凭据”则攻击者至少需要提供一个有效的Windows账号密码尽管可能权限很低。而漏洞的可怕之处在于“无需认证”这意味着服务可能错误地允许了某些不需要认证的通信路径或者其默认安装时存在一个允许匿名访问的端点。根据历史类似漏洞如CVE-2020-0609的经验问题可能出在MsDepSvc.asmx这个WCF服务端点上它可能错误地配置了安全策略。在我们的复现环境中为了简化可以先允许“Windows凭据和IIS管理器凭据”并创建一个IIS管理器用户但在构造攻击Payload时我们会尝试绕过这个认证。启动“管理服务”。此时MsDepSvc服务应该已经运行并监听8172端口。可以通过netstat -ano | findstr :8172命令确认。3.2 攻击机环境与工具链准备攻击机我使用Kali Linux主要准备以下工具和脚本反序列化利用框架ysoserial.net这是.NET反序列化利用的“瑞士军刀”内置了多种针对不同场景的Gadget Chain。我们需要下载并编译其最新版本。它可以帮助我们快速生成针对BinaryFormatter、NetDataContractSerializer等格式的Payload。自定义利用脚本由于ysoserial.net生成的Payload是通用的针对特定服务接口可能需要额外的封装。我们需要用Python或C#编写一个脚本将ysoserial生成的二进制Payload按照Web Deploy服务通信协议可能是基于SOAP的特定XML结构也可能是二进制的MSDEPLOY协议进行包装。网络探测与调试工具Nmap用于端口扫描和服务识别。Wireshark/Tcpdump抓包分析Web Deploy客户端与服务端的正常通信流程这是理解协议格式、定位漏洞触发点的关键。dnSpy/ILSpy.NET反编译工具用于分析有漏洞版本的Microsoft.Web.Deployment.dll等程序集寻找潜在的序列化点和不安全的反序列化调用例如查找BinaryFormatter.Deserialize、SoapFormatter.Deserialize等方法的调用。3.3 漏洞触发点定位与Payload构造这是整个复现过程中最核心、最技术性的部分。协议分析与端点定位首先在靶机上配置一个简单的网站然后使用合法的Visual Studio或msdeploy.exe命令行工具进行一次真实的远程发布操作。同时用Wireshark抓包。分析抓到的数据包。Web Deploy通信可能走两种方式一是通过IIS管理服务的WCF接口/MsDepSvc/MsDepSvc.asmx二是直接的MSDEPLOY协议。我们需要关注HTTP POST请求的Body部分看其内容是SOAP XML还是某种二进制结构。重点关注那些包含base64Binary元素可能内嵌了序列化对象的SOAP消息或者Content-Type为application/msdeploy等特殊类型的请求。寻找反序列化入口用dnSpy打开Microsoft.Web.Deployment.dll搜索Deserialize方法。重点关注BinaryFormatter.Deserialize(Stream)这样的调用。查看调用栈看是哪个类、哪个方法在处理来自网络的请求数据。一个常见的模式是某个用于传输配置或状态的类比如DeploymentObject、SyncParameters被标记为[Serializable]并且通过网络接收后直接被反序列化。我们需要找到这个类的类型以及接收它的网络端点。构造并封装Payload假设我们找到了漏洞点它使用BinaryFormatter反序列化一个来自SyncParameters类型的数据流。使用ysoserial.net生成一个基础的命令执行Payload。例如针对ObjectDataProviderGadget适用于WPF相关程序集ysoserial.exe -f BinaryFormatter -g TypeConfuseDelegate -c cmd /c calc.exe -o base64这会输出一个Base64编码的二进制Payload。我们的自定义脚本需要做的是模拟一个正常的Web Deploy请求但在存放SyncParameters数据的位置替换成我们生成的恶意Base64字符串。请求的SOAP Action或URL路径必须与漏洞端点匹配。这里有一个关键技巧可能需要处理Web Deploy的请求签名或简单的校验。观察正常请求的Header可能需要添加特定的Headers如MSDeploy.Version、MSDeploy.RequestId等。这些信息可以从正常通信的抓包中获得。发送攻击请求使用Python的requests库或curl发送构造好的恶意HTTP请求到靶机的https://target:8172/MsDepSvc/MsDepSvc.asmx或其他确定的端点。如果漏洞存在且Payload构造正确靶机上将会弹出计算器calc.exe这证明了远程代码执行成功。实操心得在真实漏洞研究中从找到反序列化调用点到成功利用中间往往有很长的路。可能会遇到类型检查、程序集加载限制等问题。这时需要深入分析寻找在目标服务器上必然存在的、可用的Gadget Chain。有时需要混合使用多个链或者利用Web Deploy服务自身加载的程序集中的类来构造利用链这需要对.NET框架和Web Deploy的内部实现有较深的理解。4. 漏洞修复方案与深度防御建议4.1 官方补丁与紧急缓解措施微软已经针对此漏洞发布了安全更新。最根本的解决方案是立即安装对应系统的安全补丁。可以通过Windows Update自动更新或手动下载并安装KB编号对应的独立补丁包。如果因业务原因无法立即重启服务器安装补丁必须采取以下紧急缓解措施网络层面隔离立即在防火墙主机防火墙及网络边界防火墙上设置规则禁止任何非授权IP对服务器8172和8173端口的访问。原则上只允许可信的构建服务器如Azure DevOps Agent、Jenkins Slave或管理员终端的IP地址访问此服务。如果Web Deploy服务仅用于本地管理强烈建议直接禁用其远程访问功能。服务层面加固打开IIS管理器进入“管理服务”取消勾选“启用远程连接”。这是最直接有效的一键关闭远程访问的方法。部署操作可以改为通过文件共享或使用本地msdeploy.exe调用等方式进行。如果必须开启远程连接将身份验证强制为“仅限Windows凭据”并确保用于连接的Windows账户遵循最小权限原则不要使用域管理员等高权限账户。同时启用并强制使用HTTPS8173端口以防止流量被窃听。4.2 代码与配置层面的深度安全加固打补丁只是堵上了已知的漏洞从长远来看需要从架构和配置上提升安全性。弃用不安全的序列化器对于自身开发中使用到序列化的功能全面审计并弃用BinaryFormatter、SoapFormatter、NetDataContractSerializer等危险组件。微软官方明确建议对于处理来自不受信任源的数据应使用安全的替代品如System.Text.Json.JsonSerializer(用于JSON)System.Xml.Serialization.XmlSerializer(用于XML但有局限性)Protobuf-net(Google Protocol Buffers的.NET实现)如果因历史原因无法移除必须确保反序列化操作在完全受信任的上下文中进行并对输入数据进行严格的白名单验证。实施最小权限原则运行Web Deploy服务MsDepSvc的账户不应是SYSTEM或高权限管理员。可以创建一个专用的服务账户仅授予其部署目标目录所需的读写权限、必要的IIS配置权限通过IIS管理器中的“功能委派”进行精细控制别无其他。在IIS中为Web Deploy发布使用的IIS管理器用户也仅授予其部署特定站点或应用程序的权限。加强日志审计与入侵检测启用IIS的详细日志记录并确保日志中包含请求的Body对于排查此类攻击可能需要调整日志设置注意性能影响。在服务器和网络层面部署SIEM或IDS/IPS设置规则检测对8172/8173端口的异常访问特别是包含可疑二进制数据或已知反序列化Gadget特征字符串如ObjectDataProvider、TypeConfuseDelegate等类名的请求。定期审查Web Deploy的操作日志位于%SystemDrive%\inetpub\logs\wmsvc目录下查看是否有来自未知源或异常时间的部署请求。4.3 安全开发生命周期(SDLC)融入对于开发团队此次漏洞是一个警示需要在软件开发生命周期的各个环节加入安全考量威胁建模在设计涉及远程服务、数据反序列化的功能时进行威胁建模明确信任边界。将“来自网络的数据”视为不可信数据是黄金法则。代码审计与依赖检查定期使用静态应用程序安全测试SAST工具扫描代码查找不安全的反序列化API调用。同时使用软件成分分析SCA工具管理第三方依赖及时更新有已知漏洞的组件。安全测试在渗透测试和红队演练中将反序列化漏洞作为一项常规测试项。可以部署像ysoserial.net这样的工具作为内部安全测试的参考但需严格控制使用范围。5. 从CVE-2025-53772看反序列化漏洞的防御体系CVE-2025-53772不是一个孤立的案例它是近年来层出不穷的.NET反序列化漏洞中的一个典型。从经典的BinaryFormatter漏洞到针对JSON.NET、XML Serializer的各类绕过反序列化问题一直是.NET应用安全的顽疾。防御这类漏洞需要建立一个纵深防御体系。第一层输入验证与过滤网络边界这是最外层的防御。在请求到达Web Deploy服务或任何应用服务之前可以通过Web应用防火墙WAF部署自定义规则拦截请求内容中明显包含序列化对象特征如特定头部、二进制内容特征、已知的Gadget类名字符串的请求。虽然攻击者可能通过编码、加密等方式绕过但这能挡住大部分自动化扫描和低复杂度攻击。第二层安全配置与服务加固主机与中间件层正如前面缓解措施所述严格配置服务本身。关闭不必要的远程访问使用强身份认证和加密传输遵循最小权限原则运行服务。定期更新操作系统、.NET Framework和所有中间件如IIS到最新版本。第三层代码层防御应用层这是最根本的防御。对于必须使用反序列化的场景使用安全序列化格式优先选择JSON、XML配合安全配置或Protobuf等现代、安全的序列化协议。类型限制如果无法避免使用BinaryFormatter必须使用SerializationBinder进行严格的白名单控制。自定义一个Binder在BindToType方法中只允许反序列化已知的、安全的少数几个类型拒绝任何其他类型。public sealed class SafeBinder : SerializationBinder { public override Type BindToType(string assemblyName, string typeName) { // 只允许反序列化我们明确允许的类型 if (assemblyName MySafeAssembly typeName MySafeNamespace.MySafeClass) { return typeof(MySafeClass); } // 其他所有类型都抛出异常 throw new SerializationException($Type {typeName} from assembly {assemblyName} is not allowed to be deserialized.); } } // 使用前 var formatter new BinaryFormatter { Binder new SafeBinder() }; var obj formatter.Deserialize(stream);数据签名与验证对序列化后的数据进行数字签名。在反序列化前先验证签名确保数据在传输过程中未被篡改并且来源可信。但这要求有完善的密钥管理机制。第四层运行时保护与检测启用.NET安全机制确保应用程序运行在适当的安全策略下。应用控制/白名单使用Windows Defender Application Control (WDAC)或第三方解决方案限制服务器上只能运行经过批准的可执行文件、脚本和库这可以阻止攻击者通过漏洞下载并执行恶意程序。端点检测与响应EDR部署EDR解决方案监控进程创建、网络连接、文件系统修改等异常行为。当Web Deploy工作进程w3wp.exe突然去创建cmd.exe或powershell.exe并连接外部网络时EDR应能产生高优先级告警。CVE-2025-53772再次印证了一个道理功能强大的工具往往伴随着更高的安全风险。作为运维和开发者我们不能只关注功能的实现必须将安全作为基础设施的一部分来建设和维护。每一次漏洞的披露和修复不仅是打上一个补丁更应成为我们审视自身系统安全状况、加固防御体系的一次契机。从网络隔离、权限收紧到代码审计、依赖管理再到威胁检测与响应每一个环节的疏忽都可能成为攻击者突破的缺口。在这个漏洞的具体应对上立即打补丁或关闭远程访问是当务之急而从长远计建立起对反序列化等常见漏洞模式的常态化防御思维才能在日益复杂的威胁环境中站稳脚跟。
IIS Web Deploy反序列化漏洞CVE-2025-53772深度分析与防御实战
1. 项目概述一次针对IIS Web Deploy的深度漏洞狩猎最近安全圈里关于IIS Web Deploy的一个新漏洞讨论得挺热编号是CVE-2025-53772。乍一看又是IIS又是反序列化还是远程代码执行这几个关键词凑一块儿对于做企业内网渗透或者红队评估的朋友来说吸引力是拉满了。我花了些时间把公开的零散信息、补丁比对以及自己的测试环境搭建过程梳理了一遍形成这篇分析。这个漏洞的本质是攻击者能够通过精心构造的序列化数据在目标服务器的IIS Web Deploy服务处理过程中触发反序列化最终实现在服务器上执行任意代码。听起来很耳熟对不对没错这又是一起经典的“不安全的反序列化”导致的惨案只不过这次发生在微软的官方部署工具上。IIS Web Deploy也叫MSDeploy对于.NET开发者或者运维来说应该不陌生。它是个非常强大的工具能同步网站、应用、证书甚至整个服务器配置通常用于自动化部署和迁移。正因为它权限高、功能强一旦出问题危害也极大。这个漏洞影响的是Web Deploy的远程服务接口。在实际场景中很多企业为了自动化CI/CD流水线会开启Web Deploy的远程发布功能这就给漏洞利用提供了入口。攻击者不需要任何身份认证只要网络能通发送一个恶意的请求包就可能直接拿下服务器。对于防守方尤其是那些使用了Web Deploy来自动化部署ASP.NET应用到IIS服务器的团队现在就得立刻行动起来检查自己的环境了。2. 漏洞原理与攻击面深度拆解2.1 反序列化漏洞的通用“套路”与本次特殊性要理解CVE-2025-53772我们得先重温一下反序列化漏洞的通用原理。简单来说序列化是把一个内存中的对象转换成可以存储或传输的字节流的过程比如把一个User对象包含姓名、年龄等属性变成一串XML或者二进制数据。反序列化则是逆过程把这串数据重新“组装”回内存中的对象。漏洞就出在这个“组装”过程中。如果程序在反序列化时盲目地根据数据流中的信息去创建对象、调用其方法而攻击者恰好可以控制这个数据流那么他就可以让程序反序列化出一个恶意的、精心设计的对象。这个恶意对象在构造或者被反序列化完成时会自动执行一些危险操作比如调用Process.Start(“cmd.exe”)来执行系统命令。在.NET世界里这类漏洞常与BinaryFormatter、SoapFormatter、NetDataContractSerializer等序列化器有关尤其是BinaryFormatter它功能强大但极不安全因为它反序列化时会完全信任数据并尝试调用对象的特殊方法如反序列化回调方法。微软官方早已不推荐使用BinaryFormatter处理不受信任的数据。这次CVE-2025-53772的根源很可能就是Web Deploy服务的某个组件在处理来自网络的某些数据时不恰当地使用了这类不安全的序列化器并且没有对输入进行充分的验证和过滤。2.2 IIS Web Deploy 服务架构与脆弱点分析IIS Web Deploy服务MsDepSvc默认运行在8172端口HTTP和8173端口HTTPS。它提供了一套基于SOAP或WMSvc的API供远程客户端如Visual Studio、Azure DevOps调用以执行部署操作。整个通信和数据交换过程涉及复杂的对象传递这就为序列化/反序列化操作提供了土壤。通过对补丁KB5043051等进行逆向比对和公开线索分析漏洞点很可能位于处理特定类型部署请求的代码路径中。例如当处理涉及“同步”、“备份”或“归档”等需要传递复杂配置对象的操作时服务端接收客户端发送的序列化后的任务描述对象。攻击者可以伪装成一个合法的客户端但发送一个被“污染”的序列化数据包。这个数据包里包裹的不是正常的任务描述而是一个经过特殊构造的Object其内部链Gadget Chain在反序列化时会被自动触发最终导致代码执行。注意这里的“Gadget Chain”指的是存在于目标系统.NET框架或应用程序集中的一系列类这些类像拼图一样当它们以特定顺序被反序列化时就能组合成完成恶意操作的代码路径。寻找和利用这类链是反序列化漏洞利用的核心技术。2.3 漏洞影响范围与实战场景推演这个漏洞的CVSS评分很可能在9.0以上高危或严重级别因为它具备远程、无需认证、代码执行三大特征。影响版本主要涵盖安装了Web Deploy 3.5或3.6的Windows Server系统特别是搭配IIS 7.5及以上版本的环境。很多云服务器、企业内部的应用发布服务器都可能中招。在实战攻击场景中攻击者的路径非常清晰信息收集通过端口扫描8172/8173或网络空间搜索引擎如Shodan、Fofa寻找暴露在公网或内网的Web Deploy服务。搜索关键词可以是port:8172或title:”Web Deployment Agent Service”。漏洞探测发送一个无害的、但能触发反序列化异常的数据包通过返回的错误信息或延时判断服务是否存在以及是否未打补丁。利用链构造根据目标服务器的.NET Framework版本和可能安装的第三方程序集选取或定制合适的反序列化利用链Gadget Chain。经典的如TypeConfuseDelegate、TextFormattingRunProperties或者针对Microsoft.VisualStudio.Text.UI.Wpf等程序集中特定类的链都可能被使用。载荷投递与执行将利用链与最终的恶意代码如反弹Shell的PowerShell命令、加载C#内存马的程序集进行封装生成最终的序列化Payload通过Web Deploy的服务接口发送出去。权限维持成功执行代码后通常获得的是NT AUTHORITY\SYSTEM或IIS AppPool\DefaultAppPool等高权限攻击者会进一步植入后门、横向移动或窃取数据。对于防守方最直接的威胁就是你的自动化发布通道可能成了攻击者直达核心业务服务器的“高速公路”。3. 漏洞复现环境搭建与关键步骤解析警告以下所有操作请在完全隔离的虚拟机或实验室环境中进行严禁对任何非授权系统进行测试。本文仅用于安全研究与学习。3.1 靶机环境配置为了复现和分析这个漏洞我们需要搭建一个未打补丁的、开启了Web Deploy远程管理服务的Windows Server环境。操作系统与IIS安装我选择使用Windows Server 2019 Datacenter版本安装在VMware虚拟机中。通过服务器管理器添加“Web服务器(IIS)”角色。在角色服务中务必勾选“管理服务”这个服务是Web Deploy远程管理的基础。同时为了模拟真实环境可以一并安装ASP.NET 4.8等相关功能。安装有漏洞版本的Web Deploy前往微软官方下载中心寻找Web Deploy 3.6的特定历史版本。根据漏洞时间推断需要寻找2025年特定月份之前发布的版本。一个可行的方法是下载较旧的Web Platform Installer通过它来安装指定版本的Web Deploy。更直接的方式是从已安装补丁的系统中通过对比文件版本号来确定漏洞版本。例如有漏洞的Microsoft.Web.Deployment.dll版本号可能低于9.0.xx.0具体需参考微软安全公告。我们可以从其他渠道获取该版本的独立安装包。执行安装选择“完整安装”确保安装了远程服务组件。配置Web Deploy远程服务安装完成后打开IIS管理器在服务器节点下会出现“管理服务”图标。双击打开需要勾选“启用远程连接”。这里有一个关键配置点“身份验证”类型。为了复现最严重的无需认证场景我们需要将其设置为“仅限Windows凭据”吗不恰恰相反。如果设置为“仅限Windows凭据”则攻击者至少需要提供一个有效的Windows账号密码尽管可能权限很低。而漏洞的可怕之处在于“无需认证”这意味着服务可能错误地允许了某些不需要认证的通信路径或者其默认安装时存在一个允许匿名访问的端点。根据历史类似漏洞如CVE-2020-0609的经验问题可能出在MsDepSvc.asmx这个WCF服务端点上它可能错误地配置了安全策略。在我们的复现环境中为了简化可以先允许“Windows凭据和IIS管理器凭据”并创建一个IIS管理器用户但在构造攻击Payload时我们会尝试绕过这个认证。启动“管理服务”。此时MsDepSvc服务应该已经运行并监听8172端口。可以通过netstat -ano | findstr :8172命令确认。3.2 攻击机环境与工具链准备攻击机我使用Kali Linux主要准备以下工具和脚本反序列化利用框架ysoserial.net这是.NET反序列化利用的“瑞士军刀”内置了多种针对不同场景的Gadget Chain。我们需要下载并编译其最新版本。它可以帮助我们快速生成针对BinaryFormatter、NetDataContractSerializer等格式的Payload。自定义利用脚本由于ysoserial.net生成的Payload是通用的针对特定服务接口可能需要额外的封装。我们需要用Python或C#编写一个脚本将ysoserial生成的二进制Payload按照Web Deploy服务通信协议可能是基于SOAP的特定XML结构也可能是二进制的MSDEPLOY协议进行包装。网络探测与调试工具Nmap用于端口扫描和服务识别。Wireshark/Tcpdump抓包分析Web Deploy客户端与服务端的正常通信流程这是理解协议格式、定位漏洞触发点的关键。dnSpy/ILSpy.NET反编译工具用于分析有漏洞版本的Microsoft.Web.Deployment.dll等程序集寻找潜在的序列化点和不安全的反序列化调用例如查找BinaryFormatter.Deserialize、SoapFormatter.Deserialize等方法的调用。3.3 漏洞触发点定位与Payload构造这是整个复现过程中最核心、最技术性的部分。协议分析与端点定位首先在靶机上配置一个简单的网站然后使用合法的Visual Studio或msdeploy.exe命令行工具进行一次真实的远程发布操作。同时用Wireshark抓包。分析抓到的数据包。Web Deploy通信可能走两种方式一是通过IIS管理服务的WCF接口/MsDepSvc/MsDepSvc.asmx二是直接的MSDEPLOY协议。我们需要关注HTTP POST请求的Body部分看其内容是SOAP XML还是某种二进制结构。重点关注那些包含base64Binary元素可能内嵌了序列化对象的SOAP消息或者Content-Type为application/msdeploy等特殊类型的请求。寻找反序列化入口用dnSpy打开Microsoft.Web.Deployment.dll搜索Deserialize方法。重点关注BinaryFormatter.Deserialize(Stream)这样的调用。查看调用栈看是哪个类、哪个方法在处理来自网络的请求数据。一个常见的模式是某个用于传输配置或状态的类比如DeploymentObject、SyncParameters被标记为[Serializable]并且通过网络接收后直接被反序列化。我们需要找到这个类的类型以及接收它的网络端点。构造并封装Payload假设我们找到了漏洞点它使用BinaryFormatter反序列化一个来自SyncParameters类型的数据流。使用ysoserial.net生成一个基础的命令执行Payload。例如针对ObjectDataProviderGadget适用于WPF相关程序集ysoserial.exe -f BinaryFormatter -g TypeConfuseDelegate -c cmd /c calc.exe -o base64这会输出一个Base64编码的二进制Payload。我们的自定义脚本需要做的是模拟一个正常的Web Deploy请求但在存放SyncParameters数据的位置替换成我们生成的恶意Base64字符串。请求的SOAP Action或URL路径必须与漏洞端点匹配。这里有一个关键技巧可能需要处理Web Deploy的请求签名或简单的校验。观察正常请求的Header可能需要添加特定的Headers如MSDeploy.Version、MSDeploy.RequestId等。这些信息可以从正常通信的抓包中获得。发送攻击请求使用Python的requests库或curl发送构造好的恶意HTTP请求到靶机的https://target:8172/MsDepSvc/MsDepSvc.asmx或其他确定的端点。如果漏洞存在且Payload构造正确靶机上将会弹出计算器calc.exe这证明了远程代码执行成功。实操心得在真实漏洞研究中从找到反序列化调用点到成功利用中间往往有很长的路。可能会遇到类型检查、程序集加载限制等问题。这时需要深入分析寻找在目标服务器上必然存在的、可用的Gadget Chain。有时需要混合使用多个链或者利用Web Deploy服务自身加载的程序集中的类来构造利用链这需要对.NET框架和Web Deploy的内部实现有较深的理解。4. 漏洞修复方案与深度防御建议4.1 官方补丁与紧急缓解措施微软已经针对此漏洞发布了安全更新。最根本的解决方案是立即安装对应系统的安全补丁。可以通过Windows Update自动更新或手动下载并安装KB编号对应的独立补丁包。如果因业务原因无法立即重启服务器安装补丁必须采取以下紧急缓解措施网络层面隔离立即在防火墙主机防火墙及网络边界防火墙上设置规则禁止任何非授权IP对服务器8172和8173端口的访问。原则上只允许可信的构建服务器如Azure DevOps Agent、Jenkins Slave或管理员终端的IP地址访问此服务。如果Web Deploy服务仅用于本地管理强烈建议直接禁用其远程访问功能。服务层面加固打开IIS管理器进入“管理服务”取消勾选“启用远程连接”。这是最直接有效的一键关闭远程访问的方法。部署操作可以改为通过文件共享或使用本地msdeploy.exe调用等方式进行。如果必须开启远程连接将身份验证强制为“仅限Windows凭据”并确保用于连接的Windows账户遵循最小权限原则不要使用域管理员等高权限账户。同时启用并强制使用HTTPS8173端口以防止流量被窃听。4.2 代码与配置层面的深度安全加固打补丁只是堵上了已知的漏洞从长远来看需要从架构和配置上提升安全性。弃用不安全的序列化器对于自身开发中使用到序列化的功能全面审计并弃用BinaryFormatter、SoapFormatter、NetDataContractSerializer等危险组件。微软官方明确建议对于处理来自不受信任源的数据应使用安全的替代品如System.Text.Json.JsonSerializer(用于JSON)System.Xml.Serialization.XmlSerializer(用于XML但有局限性)Protobuf-net(Google Protocol Buffers的.NET实现)如果因历史原因无法移除必须确保反序列化操作在完全受信任的上下文中进行并对输入数据进行严格的白名单验证。实施最小权限原则运行Web Deploy服务MsDepSvc的账户不应是SYSTEM或高权限管理员。可以创建一个专用的服务账户仅授予其部署目标目录所需的读写权限、必要的IIS配置权限通过IIS管理器中的“功能委派”进行精细控制别无其他。在IIS中为Web Deploy发布使用的IIS管理器用户也仅授予其部署特定站点或应用程序的权限。加强日志审计与入侵检测启用IIS的详细日志记录并确保日志中包含请求的Body对于排查此类攻击可能需要调整日志设置注意性能影响。在服务器和网络层面部署SIEM或IDS/IPS设置规则检测对8172/8173端口的异常访问特别是包含可疑二进制数据或已知反序列化Gadget特征字符串如ObjectDataProvider、TypeConfuseDelegate等类名的请求。定期审查Web Deploy的操作日志位于%SystemDrive%\inetpub\logs\wmsvc目录下查看是否有来自未知源或异常时间的部署请求。4.3 安全开发生命周期(SDLC)融入对于开发团队此次漏洞是一个警示需要在软件开发生命周期的各个环节加入安全考量威胁建模在设计涉及远程服务、数据反序列化的功能时进行威胁建模明确信任边界。将“来自网络的数据”视为不可信数据是黄金法则。代码审计与依赖检查定期使用静态应用程序安全测试SAST工具扫描代码查找不安全的反序列化API调用。同时使用软件成分分析SCA工具管理第三方依赖及时更新有已知漏洞的组件。安全测试在渗透测试和红队演练中将反序列化漏洞作为一项常规测试项。可以部署像ysoserial.net这样的工具作为内部安全测试的参考但需严格控制使用范围。5. 从CVE-2025-53772看反序列化漏洞的防御体系CVE-2025-53772不是一个孤立的案例它是近年来层出不穷的.NET反序列化漏洞中的一个典型。从经典的BinaryFormatter漏洞到针对JSON.NET、XML Serializer的各类绕过反序列化问题一直是.NET应用安全的顽疾。防御这类漏洞需要建立一个纵深防御体系。第一层输入验证与过滤网络边界这是最外层的防御。在请求到达Web Deploy服务或任何应用服务之前可以通过Web应用防火墙WAF部署自定义规则拦截请求内容中明显包含序列化对象特征如特定头部、二进制内容特征、已知的Gadget类名字符串的请求。虽然攻击者可能通过编码、加密等方式绕过但这能挡住大部分自动化扫描和低复杂度攻击。第二层安全配置与服务加固主机与中间件层正如前面缓解措施所述严格配置服务本身。关闭不必要的远程访问使用强身份认证和加密传输遵循最小权限原则运行服务。定期更新操作系统、.NET Framework和所有中间件如IIS到最新版本。第三层代码层防御应用层这是最根本的防御。对于必须使用反序列化的场景使用安全序列化格式优先选择JSON、XML配合安全配置或Protobuf等现代、安全的序列化协议。类型限制如果无法避免使用BinaryFormatter必须使用SerializationBinder进行严格的白名单控制。自定义一个Binder在BindToType方法中只允许反序列化已知的、安全的少数几个类型拒绝任何其他类型。public sealed class SafeBinder : SerializationBinder { public override Type BindToType(string assemblyName, string typeName) { // 只允许反序列化我们明确允许的类型 if (assemblyName MySafeAssembly typeName MySafeNamespace.MySafeClass) { return typeof(MySafeClass); } // 其他所有类型都抛出异常 throw new SerializationException($Type {typeName} from assembly {assemblyName} is not allowed to be deserialized.); } } // 使用前 var formatter new BinaryFormatter { Binder new SafeBinder() }; var obj formatter.Deserialize(stream);数据签名与验证对序列化后的数据进行数字签名。在反序列化前先验证签名确保数据在传输过程中未被篡改并且来源可信。但这要求有完善的密钥管理机制。第四层运行时保护与检测启用.NET安全机制确保应用程序运行在适当的安全策略下。应用控制/白名单使用Windows Defender Application Control (WDAC)或第三方解决方案限制服务器上只能运行经过批准的可执行文件、脚本和库这可以阻止攻击者通过漏洞下载并执行恶意程序。端点检测与响应EDR部署EDR解决方案监控进程创建、网络连接、文件系统修改等异常行为。当Web Deploy工作进程w3wp.exe突然去创建cmd.exe或powershell.exe并连接外部网络时EDR应能产生高优先级告警。CVE-2025-53772再次印证了一个道理功能强大的工具往往伴随着更高的安全风险。作为运维和开发者我们不能只关注功能的实现必须将安全作为基础设施的一部分来建设和维护。每一次漏洞的披露和修复不仅是打上一个补丁更应成为我们审视自身系统安全状况、加固防御体系的一次契机。从网络隔离、权限收紧到代码审计、依赖管理再到威胁检测与响应每一个环节的疏忽都可能成为攻击者突破的缺口。在这个漏洞的具体应对上立即打补丁或关闭远程访问是当务之急而从长远计建立起对反序列化等常见漏洞模式的常态化防御思维才能在日益复杂的威胁环境中站稳脚跟。
