致远M3移动门户信息泄露漏洞深度剖析与实战复现

1. 项目概述与核心价值

最近在内部安全评估和外部众测项目中，一个名为“致远-M3”的移动门户信息泄露漏洞频繁出现，引起了我的注意。这个漏洞的标题“mobile_portal”信息泄露，乍一看可能觉得平平无奇，不就是个目录遍历或者配置不当吗？但实际深入分析后，我发现它远不止于此。它暴露的不仅仅是几个文件，而是整个移动应用后端架构的脆弱面，甚至可能成为攻击者横向移动、获取更高权限的跳板。对于从事企业应用安全、移动安全测试，或是负责运维致远系列产品的朋友来说，理解这个漏洞的原理、复现手法以及背后的深层风险，至关重要。

简单来说，这个漏洞的核心在于致远M3协同管理软件的移动端门户（mobile_portal）存在未授权的访问路径或接口，导致攻击者无需认证即可访问到本应受保护的敏感信息。这些信息可能包括服务器内部路径、配置文件、数据库连接字符串、日志文件，甚至是部分业务数据。这就像一栋大楼的门卫系统失效了，任何人都能走到后台的管理间，看到监控屏幕、值班表甚至备用钥匙放在哪里。对于企业而言，这无疑是巨大的安全隐患。接下来，我将以一个资深安全研究员的视角，带你从零开始，完整拆解这个漏洞的发现、分析、复现与修复全流程，并分享一些在实战中总结出来的独家技巧和避坑指南。

2. 漏洞环境搭建与核心思路解析

2.1 环境准备与目标定位

要复现一个漏洞，首先得有一个靶场。对于致远M3，最理想的环境当然是官方安装包搭建的测试系统。你可以从一些合法的漏洞研究平台或资源站找到对应的安装镜像（例如，针对历史版本进行安全学习的测试环境）。通常，我会准备一个干净的Windows Server或Linux虚拟机，内存建议8GB以上，因为这类协同软件相对吃资源。

安装过程按照官方文档进行即可，重点在于记住安装路径和初始访问地址。安装完成后，访问http://[靶机IP]:端口就能看到登录页面。而我们的目标——移动门户，其访问路径通常是http://[靶机IP]:端口/mobile或http://[靶机IP]:端口/mobile_portal。这里就出现了第一个关键点：路径枚举。很多此类漏洞的发现都始于对常见路径、默认路径的尝试访问。致远系列产品有多个版本，其移动端路径命名可能略有差异，mobile_portal是其中一种常见形态。

注意：所有安全测试必须在授权范围内进行，严禁对未授权的任何系统进行探测或攻击。本文所用环境均为自行搭建的本地测试环境。

2.2 漏洞挖掘的核心思路：资产识别与接口探测

拿到一个像致远M3这样的大型应用，直接盲测效率很低。我的思路通常是“先测绘，后深入”。具体分为三步：

1. 静态资产梳理：利用目录扫描工具（如 dirsearch, gobuster）对mobile_portal路径进行深度爬取。配置字典时，要加入针对Java Web应用（致远基于Java）的常见路径，如/WEB-INF/,/META-INF/,/static/,/api/,/servlet/等。同时，关注像upload,download,export,config这类高危功能关键词。
2. 动态接口分析：使用浏览器开发者工具或抓包工具（Burp Suite），正常登录移动端，记录下所有的网络请求。重点关注那些返回数据格式为JSON或XML的API接口，观察其URL规律、参数构成。然后，尝试在未登录状态下直接访问这些接口地址。
3. 非常规文件探测：除了程序文件，更要关注可能被遗忘在Web目录下的“垃圾文件”，如.git目录、.svn目录、备份文件（.bak,.old,.tar.gz）、临时文件（.tmp）以及配置文件（.properties,.xml,.conf）。这些往往是信息泄露的重灾区。

针对“致远-M3-信息泄露-mobile_portal”这个案例，其漏洞点很可能就隐藏在以上某一步的探测结果中。可能是一个无需认证即可访问的API，直接返回了用户列表或系统信息；也可能是一个配置文件的直接下载链接；或者是一个错误的调试接口，输出了服务器路径等敏感数据。

3. 漏洞复现过程与关键步骤拆解

基于上述思路，我们开始实战复现。假设通过初步扫描，我们发现了疑似泄露点。

3.1 场景一：敏感接口未授权访问

这是最常见的一种情况。在mobile_portal路径下，存在一个用于获取系统基础信息或会话状态的接口，但开发者遗漏了权限校验。

复现步骤：

1. 使用Burp Suite拦截浏览器访问移动门户首页http://target_ip:port/mobile_portal的请求。
2. 在Burp的Proxy -> HTTP history中，筛选出该域名下的所有请求。你可能会看到一些像/mobile_portal/api/getAppInfo、/mobile_portal/auth/checkStatus之类的请求。
3. 选中一个看起来可能返回系统信息的GET请求，右键选择“Send to Repeater”。
4. 在Repeater标签页中，移除请求头中的Cookie、Authorization等所有认证字段，然后点击“Send”。
5. 观察响应。如果服务器在未认证的情况下，仍然返回了200状态码，并且响应体中包含了服务器版本、路径、数据库类型（哪怕只是错误信息里透露的）、内部IP等敏感信息，那么漏洞就存在了。

示例请求与响应分析：

假设未授权接口为/mobile_portal/api/client/config。

GET /mobile_portal/api/client/config HTTP/1.1 Host: target_ip:port User-Agent: Mozilla/5.0 (测试用) Accept: application/json, text/plain, */* Connection: close

正常（有漏洞）的响应可能如下：

HTTP/1.1 200 OK Content-Type: application/json { "code": 0, "data": { "serverVersion": "M3 6.0 SP1", "uploadPath": "D:/Seeyon/upload", "tempPath": "C:/Windows/Temp/seeyon", "database": { "type": "MySQL", "url": "jdbc:mysql://192.168.1.100:3306/seeyon?useUnicode=true" } } }

这个响应直接泄露了软件版本、服务器上的绝对路径以及内网数据库地址。攻击者可以利用版本信息寻找其他已知漏洞；利用绝对路径尝试路径遍历或文件上传；利用内网数据库地址尝试后续的渗透。

3.2 场景二：目录遍历与配置文件泄露

另一种常见情况是，mobile_portal下的某个静态资源处理逻辑存在缺陷，允许通过../这样的序列跳出限制目录，访问到Web根目录之外的文件。

复现步骤：

1. 通过扫描，发现可能存在文件读取功能的端点，例如/mobile_portal/file/download、/mobile_portal/static/../或/mobile_portal/resource?file=xxx。
2. 在Burp Repeater中，构造遍历Payload。例如，如果参数是fileName，可以尝试：

   GET /mobile_portal/file/download?fileName=../../../../WEB-INF/classes/db.properties HTTP/1.1

   GET /mobile_portal/static/../../../../etc/passwd HTTP/1.1 (针对Linux系统)

3. 发送请求，观察响应。如果返回了配置文件内容（如数据库密码）或系统文件内容，则漏洞存在。

实操心得：

• 编码绕过：如果直接使用../被拦截，可以尝试URL编码（%2e%2e%2f）、双重编码（%252e%252e%252f）或UTF-8编码等。
• 空字节截断：在某些老旧系统中，可以在文件名后添加空字节（%00）来截断后续的扩展名检查，例如../../../boot.ini%00.jpg。
• 重点文件列表：在测试时，我通常会准备一个包含以下文件的字典进行Fuzz：
  • WEB-INF/web.xml(应用核心配置)
  • WEB-INF/classes/db.properties,jdbc.properties(数据库连接信息)
  • WEB-INF/classes/config/*.xml(各类业务配置)
  • META-INF/MANIFEST.MF(构建信息)
  • /etc/passwd,/etc/shadow(Linux)
  • C:/Windows/System32/drivers/etc/hosts(Windows)

3.3 场景三：错误信息泄露

这种泄露更为隐蔽，通常发生在应用处理异常时，将详细的调试信息直接返回给了客户端。

复现步骤：

1. 向mobile_portal下的任意接口或页面，发送一个畸形的、非预期的请求。例如：
   • 在GET请求的URL中插入特殊字符：/mobile_portal/api/userInfo?id=1'
   • 将POST请求的Content-Type改为text/xml但发送JSON body。
   • 删除必要的请求参数。
2. 观察服务器的错误响应。如果返回的不是统一的、友好的错误页面，而是包含Java异常栈跟踪（StackTrace）、SQL语句、类加载路径等信息的详细错误报告，那么就存在错误信息泄露。

示例错误响应片段：

HTTP/1.1 500 Internal Server Error Content-Type: text/html;charset=utf-8 ...（省略HTML）... <pre> java.sql.SQLSyntaxErrorException: Unknown column '1''' in 'where clause' at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120) at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122) at com.seeyon.ctp.common.dao.BaseHibernateDao.find(BaseHibernateDao.java:345) at com.seeyon.mobile.portal.service.UserServiceImpl.getUserInfo(UserServiceImpl.java:67) ... at java.lang.Thread.run(Thread.java:748) </pre> ...

从这段错误中，攻击者可以确认后端数据库是MySQL，使用了Hibernate框架，甚至看到了部分代码路径和DAO层方法名，为后续更精准的SQL注入攻击提供了线索。

4. 漏洞深度利用与影响范围分析

仅仅复现信息泄露还不够，作为一名安全研究员，我们需要评估其真正的危害。信息泄露往往是“破冰”的第一步。

4.1 信息拼图与内网测绘

单一的信息泄露点价值有限，但多个点泄露的信息组合起来，就能拼出一张惊人的“地图”。例如：

• 从接口泄露中获取：服务器内网IP（192.168.1.100）、Web绝对路径（D:/Seeyon）。
• 从配置文件中获取：数据库密码、Redis密码、SMTP邮箱密码。
• 从错误信息中获取：中间件版本（Tomcat 8.5.xx）、框架版本（Spring 4.x）。

有了这些信息，攻击者可以：

1. 绘制内网拓扑：以泄露的服务器IP为起点，进行内网扫描，发现更多资产。
2. 尝试直接连接数据库：使用泄露的数据库IP、端口、用户名和密码，如果数据库端口（如3306）恰巧对公网开放或能从Web服务器连通，则可直接拖库。
3. 寻找已知漏洞：根据精确的软件版本（如“致远M3 6.0 SP1”），在漏洞库中搜索对应的公开漏洞或EXP，进行下一步利用。
4. 社会工程学：泄露的邮箱地址、内部系统路径名（可能包含项目代号、部门名称）可用于制作更具欺骗性的钓鱼邮件。

4.2 结合其他漏洞形成攻击链

信息泄露很少单独造成毁灭性打击，但它能极大降低后续攻击的难度。一个经典的攻击链可能是：

1. 信息泄露-> 获取uploadPath（D:/Seeyon/upload）。
2. 寻找上传点-> 在mobile_portal或其他模块找到文件上传功能。
3. 绕过上传限制-> 利用获取的路径信息，尝试进行路径穿越上传，将Webshell写入Web可访问目录（例如，如果upload目录是D:/Seeyon/upload，而Web根目录是D:/Seeyon/webapps/ROOT，可以尝试上传时使用../../../webapps/ROOT/shell.jsp）。
4. 获取服务器权限-> 通过访问上传的Webshell，获得服务器控制权。

4.3 对移动安全的影响

这个漏洞发生在mobile_portal，直接影响到移动端用户。泄露的信息可能包括：

• 移动端API密钥：用于调用第三方服务（如地图、推送）。
• 用户设备信息：虽然可能脱敏，但大量数据的聚合分析仍有价值。
• 业务数据接口地址和参数格式：方便攻击者构造针对性的数据窃取或篡改请求。 攻击者可以制作一个仿冒的官方移动应用，利用这些真实的接口信息，诱骗用户输入账号密码，造成更大范围的凭证泄露。

5. 修复建议与安全加固实操

发现了漏洞，更重要的是知道如何修复和防范。以下是我给开发和安全运维人员的具体建议。

5.1 紧急修复措施

1. 访问控制：立即检查mobile_portal目录下所有接口和静态资源的访问权限。确保每一个需要鉴权的接口，都在过滤器或拦截器中进行了有效的会话检查。不要依赖前端隐藏或禁用，后端必须校验。
2. 错误处理全局化：在Web应用的全局配置中（如Spring的@ControllerAdvice，或web.xml中的<error-page>），定义统一的、不包含任何系统细节的错误页面。确保任何未捕获的异常都不会将堆栈信息返回给客户端。
3. 敏感信息脱敏：审查所有API的返回数据。像服务器路径、内网IP、数据库连接串、密钥等，绝对不应该在任何正常业务接口中返回。如果调试需要，应通过开关严格控制，仅在内网环境开启。
4. 删除冗余文件：彻底扫描Web发布目录（包括mobile_portal），删除所有备份文件（.bak,.old）、版本控制目录（.git/,.svn/）、临时文件和旧的配置文件。

5.2 安全开发规范（长期）

1. 最小权限原则：移动端接口应遵循“按需所知”原则。只返回前端渲染所必需的最少数据字段。
2. 输入严格校验：对所有用户输入进行白名单校验，特别是文件路径、URL参数等。坚决杜绝../等目录遍历字符被传入文件操作函数。
3. 安全配置：
   • 在Web服务器（如Nginx, Apache）或应用服务器（如Tomcat）层面，为静态资源目录设置严格的访问规则。
   • 关闭HTTP方法的非必要支持（如PUT, DELETE, TRACE）。
   • 设置安全的HTTP响应头，如X-Content-Type-Options: nosniff,X-Frame-Options: DENY,Content-Security-Policy。
4. 定期安全扫描：将目录扫描、接口模糊测试（Fuzzing）纳入CI/CD流程或定期巡检任务，使用工具自动化发现潜在的信息泄露点。

5.3 针对运维的加固检查清单

为了方便运维同学快速自查，我整理了一个清单：

6. 常见排查问题与实战技巧实录

在复现和修复这类漏洞的过程中，我踩过不少坑，也总结了一些技巧。

6.1 复现阶段常见问题

1. 扫描不到路径？

   • 可能原因：路径名称不准确。致远不同版本、不同部署方式下，移动端路径可能为/m，/wap,/weaver等。可以先用浏览器尝试几个常见路径，或者从主站首页的HTML源码、JS文件中搜索mobile相关链接。
   • 技巧：使用gobuster时，可以尝试-x参数添加.jsp,.do,.action等扩展名，因为Java应用的路由可能带后缀。

2. Burp抓不到移动端流量？

   • 可能原因：移动端应用可能使用了证书绑定（SSL Pinning）或非HTTP协议。
   • 解决方案：对于测试，可以在模拟器或已Root的手机上安装Burp的CA证书，并使用像Frida这样的工具绕过证书绑定。更简单的方法是，直接分析前端代码，找到API的BaseURL和调用方式，然后在Burp中手动构造请求。

3. 返回的数据是乱码或加密的？

   • 可能原因：响应可能被GZIP压缩，或者数据本身经过了加密/编码。
   • 解决方案：在Burp Repeater的响应面板，查看 “Headers” 标签，如果有Content-Encoding: gzip，可以点击 “解码” 按钮自动解压。如果是自定义加密，需要逆向分析移动端APK的加密逻辑，这属于更高阶的移动安全测试范畴。

6.2 修复验证阶段注意事项

1. “修复了”但漏洞还在？

   • 场景：你在代码里加了一个权限校验，但只校验了GET请求，攻击者用POST方法依然可以访问。
   • 教训：权限校验必须覆盖该接口支持的所有HTTP方法。在过滤器中，要对GET,POST,PUT,DELETE等统一处理。

2. 配置了错误页面，但还有细节泄露？

   • 场景：Tomcat配置了自定义错误页，但某些深层框架异常还是绕过了它。
   • 解决方案：除了容器级配置，一定要在应用框架层面（如Spring的异常处理器）也做好兜底。同时，将生产环境的日志级别设置为WARN或ERROR，避免DEBUG或INFO级别的日志被不当输出到前端。

3. 删除了文件，但漏洞利用方式变了？

   • 场景：你删除了db.properties.bak，但攻击者通过目录遍历找到了WEB-INF/classes/目录下的编译后的类文件（.class），通过反编译同样可能获取关键信息。
   • 核心：修复不能只治标。根本原因是目录遍历漏洞本身。必须修复文件读取逻辑，进行严格的路径规范化（Canonicalization）和白名单校验。

6.3 我的独家排查技巧

• “盲猜”接口：对于像致远这类产品，其API命名往往有规律。例如，获取列表的接口可能是list或query，获取详情的接口可能是get或detail。可以尝试组合常见动词和名词进行Fuzz：/mobile_portal/api/user/list,/mobile_portal/api/config/get等。
• 关注JS文件：现代前端应用，API地址通常会在JavaScript文件中定义。用浏览器打开移动门户，在“源代码”或“网络”标签中搜索.js文件，仔细查看，经常能发现完整的API路由表。
• 利用搜索引擎语法：在授权测试中，可以使用site:target.com inurl:mobile_portal这样的语法，看看有没有被网络爬虫索引了的、本不该公开的移动端路径或参数，这本身也是一种信息泄露。

这个“致远-M3-信息泄露-mobile_portal”漏洞，是一个典型的企业级应用“表面之下”的安全问题。它提醒我们，安全是一个整体，任何一个细微的疏忽（比如一个未鉴权的调试接口，一个忘记删除的备份文件）都可能成为整个防御体系的突破口。对于企业而言，建立常态化的资产清点、漏洞扫描和代码审计机制，远比事后应急更重要。而对于安全研究者，保持对常见路径、默认配置和错误处理的敏感度，是发现此类漏洞的关键。每一次成功的复现和修复，都是对自身防御能力的一次加固。