处置：从告警到溯源
七一重保期间，某合作公司向我司紧急求救，其APT系统出现攻击告警。现场人员发现有IP正针对其系统进行Ueditor编辑器任意文件上传漏洞攻击，并且攻击者已成功上传了木马文件。应急响应工作随即展开。
-
初步处置：在电话中与客户沟通后，建议其暂时切断服务器外部通信以控制风险。客户采纳建议，直接关闭了服务器。
图：被攻击服务器的管理界面。
-
现场分析：抵达现场后，首先查看APT系统，确认存在大量关于Ueditor文件上传的攻击告警。
图：APT系统捕获到的Ueditor任意文件上传漏洞攻击日志。
日志显示，攻击者已利用此漏洞成功上传了木马文件。这不禁让人疑惑，部署的WAF在关键时刻为何未能生效？
图：攻击成功的HTTP请求与响应，文件已上传至服务器。
-
文件排查：重启服务器并关闭外网访问后，根据攻击回显的路径，定位到被上传的文件目录。
图：根据攻击回显找到服务器上的文件路径。
经查，上传的文件是一个常见的冰蝎（Behinder）ASPX webshell，这让人稍微松了口气。
图：攻击者上传的冰蝎木马文件代码片段。
-
清理与加固：将所有可疑文件备份至本地后，立即从服务器中删除。检查过程中还发现了一些涉及赌博等内容的黑页文件。为彻底排查风险，立即对网站目录进行了后门扫描。
图：使用工具对网站进行后门文件扫描。
-
威胁情报溯源：对攻击源IP和用于承载木马的域名进行威胁情报分析，结果显示两者均被标记为恶意。
图：微步情报显示攻击者IP和域名均为恶意。
进一步分析发现，相关IP和域名均位于香港，且未进行备案。
图：SEO综合查询显示攻击者域名无备案，IP位于香港。
-
样本分析：尝试访问攻击者用于上传的木马源地址，并将文件下载到本地进行分析。
该文件实质是一个GIF图片与冰蝎aspx木马拼接而成的图片马。
图：下载的“图片马”文件，实为GIF头部拼接了ASPX webshell代码。
将该文件提交至云沙箱检测，也被确认为恶意软件。
图：微步云沙箱检测报告，多款引擎检出该文件为后门。
成因：深入代码分析漏洞原理
Ueditor的官方网站虽已停止访问，但其源码仍可在GitHub上获取。
-
入口分析：查看 /net/controller.ashx 文件，第14行接收了一个名为 action 的参数。
图：Ueditor控制器入口文件，接收action参数。
-
路由判断：action 参数通过 switch case 进行判断。当 action 等于 catchimage（远程图片抓取）时，会调用 CrawlerHandler。
图：根据action参数值，路由到不同的处理器。
进入 CrawlerHandler 查看，当 source 参数为空时，会返回“参数错误：没有指定抓取源”。这正是我们探测漏洞是否存在时利用的特征。
图：Ueditor net版本后端处理器的文件结构。
图：访问漏洞路径，返回特定错误信息，证明接口存在。
-
核心逻辑：当 source 参数不为空时，程序会为每个 source 创建一个 Crawler 对象并执行抓取。
图：CrawlerHandler中处理多个图片源的核心代码。
-
漏洞触发点：在 Crawler 类的 Fetch 方法中，程序会向 source 指定的URL发起请求。
图：Crawler类中发起网络请求的代码片段。
随后，代码会检查响应的 ContentType 是否包含“image”字符串，以此判断是否为图片。
图：漏洞关键点之一，仅通过ContentType判断文件类型。
-
任意文件上传：如果 ContentType 检查通过，文件就会被保存到服务器上。因此，攻击者只要控制一个远程服务器，使其返回的HTTP响应头中 Content-Type 包含“image”（例如 image/jpeg），就可以诱使Ueditor将任意文件（如aspx木马）当作图片抓取并保存到本地，从而造成任意文件上传漏洞。
图：通过路径格式化，将远程文件保存到服务器指定目录。
Tips:
常见的利用方式为何是上传 xxx.gif?.aspx？这是因为服务器端获取文件后缀的逻辑是通过截取URL中最后一个点（.）来实现的。对于URL http://evil.com/shell.gif?.aspx，GetFileName() 方法会将其解析为 shell.gif，但最终保存到服务器的文件扩展名却是 .aspx，从而绕过简单的文件类型检查。
复现：验证漏洞影响
-
漏洞探测：访问 Ueditor/net/controller.ashx?action=catchimage，返回“参数错误：没有指定抓取源”，初步证明该接口存在且存在风险。
-
上传HTML测试：构造请求，让Ueditor从远程抓取一个HTML页面，上传成功。
图：利用漏洞成功上传HTML文件到服务器。
-
上传图片马测试：构造请求，抓取一个 Content-Type 为 image/jpeg 但实际内容为webshell的“图片马”，同样上传成功。
图：成功上传图片格式的Webshell文件。
修复：临时处置与彻底修补
在系统开发商到场前，采取临时修复措施控制风险：
-
访问控制：在防火墙上配置策略，禁止外网IP访问存在漏洞的 admin 目录以及文件上传后的存储目录 f_load。
图：通过配置WAF/防火墙策略限制目录访问。
图：应用访问控制策略后，外网访问相关目录返回403禁止访问。
-
请求重定向：通过规则，将访问漏洞路径 action=catchimage 的请求重定向到登录退出页面。
图：配置规则将攻击请求302重定向到安全页面。
-
代码修复：开发人员到达后，最根本的修复是修改后端代码，关闭或严格校验 catchimage 功能。例如，可彻底移除该功能，或在保存文件前进行更严格的文件头校验，而非仅依赖 ContentType。临时方案也可关闭上传成功的路径回显。
图：修复回显后，攻击虽可能成功，但攻击者无法获取文件路径。
总结：应急响应标准化流程
通过此次实战，可以总结出处理类似Web漏洞应急响应事件的一般步骤，这对于从事安全攻防与应急响应工作的工程师具有参考价值：
- 初步控制：详细了解事件情况，与客户协商对受影响服务器进行断网或关机，防止危害扩大。如有终端安全管理系统，立即发起全盘病毒查杀。
- 证据保全与清理：备份木马、可疑文件至本地分析，然后彻底清除服务器上的相关文件。
- 样本与影响分析：分析木马类型、功能及可能造成的危害（如数据泄露、内网渗透等），评估事件等级。
- 漏洞分析与复现：分析攻击手法，定位漏洞成因，并在测试环境中复现漏洞，明确修复点。
- 临时与永久修复：优先利用WAF、防火墙等设备部署虚拟补丁或访问控制策略进行紧急防护。随后协调研发人员对源码进行彻底修复，并验证修复效果。
通过以上系统化的流程，能够高效、有序地应对突发的网络安全攻击事件，将损失降到最低。希望这次针对Ueditor漏洞的应急响应实录，能为你的渗透测试与安全防御工作带来启发。更多技术交流与深度内容，欢迎关注云栈社区。 | 
发表于 2025-12-30 02:45:25
|
查看: 26|
回复: 0
