致远OA漏洞实战：从信息泄露到RCE的授权测试全流程解析

1. 项目概述

最近刚结束一个授权测试项目，目标系统是某单位正在使用的致远OA。这类协同办公系统在企业里太常见了，承载着流程审批、公文流转、信息发布等核心业务，一旦出问题，影响面可不小。测试过程中，我重点梳理和验证了致远OA近些年曝出的几个高危漏洞，并借助一个叫seeyon_exp的自动化利用工具进行了实战演练。这篇文章，我就把这次从信息收集、漏洞验证到最终利用的完整过程复盘一下，重点聊聊那些容易被忽视的细节、工具使用的门道，以及在实际授权测试环境中如何安全、高效地操作。无论你是刚入行的安全测试工程师，还是负责运维这类系统的管理员，相信这些一手经验都能给你带来些实实在在的参考。

2. 核心漏洞原理与利用链拆解

致远OA的漏洞历史可以说相当“丰富”，很多问题都源于早期版本对用户输入过滤不严、权限校验缺失，或是默认配置存在安全隐患。seeyon_exp工具集成了多个漏洞，但知其然更要知其所以然，我们不能只当个“脚本小子”。下面我挑几个典型且危害高的漏洞，拆开讲讲它们的原理和利用逻辑。

2.1 信息泄露类漏洞：系统的“身份证”被暴露

信息泄露往往是渗透测试的突破口，它能提供后续攻击所需的关键信息，比如后台路径、用户数据、甚至数据库凭证。

致远OA A8 状态监控页面信息泄露：这个漏洞的路径通常是/seeyon/management/status.jsp。这个页面本意是给管理员查看系统运行状态的，但很多管理员疏于访问控制，导致未授权用户也能直接访问。页面上会显示服务器版本、JDK版本、中间件信息、部分配置参数等。这些信息有什么用？它们能帮你精准定位系统版本，从而寻找对应的已知漏洞。比如，知道了精确的OA版本，你就能去漏洞库搜索是否有该版本未修复的远程代码执行或SQL注入漏洞。

致远OA A6 DownExcelBeanServlet 用户敏感信息泄露：这个漏洞点在于/seeyon/common/designer/pageDown.jsp?downType=excel&filePath=这个接口。攻击者可以通过filePath参数构造特定的路径，尝试下载服务器上的敏感文件。例如，通过../../这样的目录遍历（Path Traversal）手法，有可能读取到WEB-INF/web.xml配置文件，里面可能包含数据库连接池的配置，甚至是加密过的密码。更危险的是，如果系统存在用户信息导出功能，且参数可控，攻击者可能直接下载包含所有用户姓名、工号、部门甚至加密密码的Excel文件。

注意：在实际测试中，信息泄露漏洞的利用成功率很高，因为它们通常不涉及复杂的过滤机制。但切忌一上来就疯狂扫描，过快的请求速率很容易触发WAF或IDS的规则，导致IP被封锁。建议在测试初期，手动访问几个常见的信息泄露路径进行试探。

2.2 SQL注入漏洞：直达数据库的“后门”

SQL注入是老生常谈，但在一些OA系统的老版本里依然存在。致远OA A6版本的setextno.jsp和test.jsp就曾曝出过此类漏洞。

以test.jsp为例，其漏洞原理可能是接收了来自客户端的参数（比如一个ID参数），未经任何过滤就直接拼接到了SQL查询语句中。攻击者可以提交类似1' AND '1'='1或1' UNION SELECT user(), database() --这样的payload。如果页面返回了数据库用户名、库名等信息，就证实了注入点的存在。

这类注入点如果恰好存在于管理员后台等权限较高的功能模块，危害极大。利用SQL注入，攻击者不仅可以拖库（导出所有数据），还可能通过数据库的特定函数（如在MySQL中利用INTO OUTFILE）向服务器写入Webshell，从而获得系统控制权。不过，现代WAF对SQL注入的检测非常严格，你需要对payload进行大量的混淆和变形来绕过检测，比如使用十六进制编码、注释符分割、等价函数替换等。

2.3 文件上传与登录绕过组合拳：获取立足点

这是seeyon_exp工具集成的核心攻击链之一，也是本次测试中成功getshell的关键。它主要利用了ajax.do接口的登录绕过和任意文件上传漏洞。

漏洞原理浅析：致远OA的某些版本中，用于处理Ajax请求的ajax.do接口存在权限校验缺陷。攻击者可以构造特定的HTTP请求，在未登录的情况下调用本应需要权限的后台功能，例如文件上传。更致命的是，该上传功能对文件类型、内容、路径的检查可能形同虚设，导致攻击者可以直接上传一个可执行的JSP Webshell文件。

利用链还原：

1. 绕过登录：工具会向目标/seeyon/ajax.do发送一个精心构造的POST请求。这个请求可能包含了一个特定的method参数或Content-Type头，欺骗系统认为这是一个合法的、已认证的内部请求，从而绕过登录校验。
2. 上传Webshell：在绕过登录后，工具会利用同一个接口或关联的上传功能，将一段JSP格式的Webshell代码作为文件内容上传到服务器可访问的目录，比如/seeyon/webapps/下的某个子目录。seeyon_exp默认使用的是冰蝎（Behinder）3.0的Webshell，其特点是流量加密，能有效绕过一些基于特征码的入侵检测。
3. 访问Webshell：上传成功后，工具会返回Webshell的访问地址。攻击者（或工具本身）就可以通过浏览器或客户端连接这个地址，使用预设的密码（默认为rebeyond）进行连接，从而在服务器上执行任意命令。

这个漏洞的可怕之处在于，它从“门外汉”到“获得服务器控制权”的路径非常短，几乎是一步到位。对于防守方来说，除了及时打补丁，还必须加强对ajax.do这类通用接口的权限校验和输入过滤。

3. seeyon_exp工具实战操作详解

工具能提高效率，但用不好反而会“打草惊蛇”甚至触犯规则。下面我结合这次测试，详细说说seeyon_exp的使用要点、参数含义以及每一步背后的操作逻辑。

3.1 环境准备与工具获取

首先，你需要一个Python3环境。这没什么好说的，建议使用Python 3.8及以上版本，兼容性更好。然后从GitHub上获取seeyon_exp工具。你可以直接git clone仓库，或者下载ZIP包。我建议在虚拟机或独立的测试环境中操作，避免影响本地其他项目。

下载后，用pip安装必要的依赖库。通常这类工具会用到requests、argparse等，如果运行报错提示缺少模块，就用pip install装上即可。

实操心得：永远不要在连接着公司内网或重要业务的电脑上直接运行这类渗透测试工具。最好准备一个干净的虚拟机环境，并配置好系统代理（如果需要测试互联网目标），确保网络环境的隔离性和可控性。

3.2 单目标检测与利用

工具的基本用法很清晰。假设我们的目标地址是http://oa.target-company.com。

第一步：漏洞检测（信息收集阶段）

python3 seeyon_exp.py -u http://oa.target-company.com

执行这个命令，工具会按照其内置的POC列表，依次对目标发起探测请求。这个过程是“只读”的，主要是发送一些无害的探测请求，检查目标是否存在信息泄露、SQL注入点等漏洞。运行后，控制台会打印检测进度，并将结果保存到当前目录下的result.txt文件中。

你需要仔细阅读result.txt的输出。它会列出发现的所有漏洞类型和对应的URL。例如：

[+] http://oa.target-company.com/seeyon/management/status.jsp 存在A8状态监控信息泄露 [-] http://oa.target-company.com/seeyon/test.jsp SQL注入漏洞检测失败 [+] http://oa.target-company.com/seeyon/ajax.do 可能存在登录绕过漏洞

这个阶段的目标是“摸清家底”，确认哪些漏洞是真实存在的。特别注意：即使工具报告某个漏洞存在，也需要人工进行二次验证，特别是SQL注入，要判断是真漏洞还是误报。

第二步：漏洞利用（获取Shell）如果检测阶段确认了ajax.do等高风险漏洞存在，并且本次授权测试的范围允许进行利用测试，那么可以尝试getshell。

python3 seeyon_exp.py -u http://oa.target-company.com --att

加上--att参数，工具就会从检测模式进入攻击模式。它会尝试利用文件上传漏洞，将Webshell写入服务器。如果成功，命令行会输出Webshell的访问地址，类似于：

[+] Webshell uploaded successfully! [+] URL: http://oa.target-company.com/seeyon/webapps/xxx.jsp [+] Password: rebeyond

这里有一个至关重要的细节：工具默认上传的是冰蝎3的Webshell。这意味着你不能直接用浏览器访问这个地址，那样会看到一堆乱码或者直接下载。你需要使用冰蝎客户端来连接。将工具给出的URL和密码（rebeyond）填入冰蝎客户端，才能成功建立连接并管理服务器。

3.3 批量检测与注意事项

当需要对一个IP段或大量目标进行初步筛查时，批量功能就派上用场了。

1. 将目标URL按行存入一个文本文件，例如urls.txt。
2. 执行批量检测：

   python3 seeyon_exp.py -f urls.txt

3. 同样，结果会汇总到result.txt。

核心避坑指南：

1. 速率控制：工具本身可能没有内置延时。在批量扫描时，务必在代码中或通过外部手段（如使用time.sleep()简单修改工具）添加请求间隔，比如每个请求之间暂停2-5秒。疯狂请求不仅不道德，而且极易触发目标的安全防护机制，导致你的扫描IP被永久封禁。
2. 结果筛选：result.txt文件可能会很大。建议写个简单的脚本或使用文本编辑器的搜索功能，快速筛选出存在ajax.do漏洞或任意文件上传漏洞的目标，这些是后续深入测试的重点。
3. 授权！授权！授权！：这是红线中的红线。seeyon_exp工具说明里也明确写了“仅用于授权测试”。在没有获得书面、明确授权的情况下，对任何系统进行漏洞扫描和利用都是违法行为。我们所有的操作都必须严格控制在授权书规定的目标、时间和范围内。

3.4 工具背后的请求逻辑分析

作为一个有追求的测试者，不能只满足于运行脚本。我习惯用Burp Suite等代理工具拦截seeyon_exp发出的所有请求，看看它到底做了什么。通过分析，我发现它的攻击流程大致如下：

1. 探测阶段：对每个POC，工具会发送一个或多个特定的HTTP请求。例如，检测status.jsp就是发一个GET请求，然后检查返回内容里是否包含“系统状态”、“JDK”等关键词。
2. 攻击阶段（--att模式）：
   • 请求一：向/seeyon/ajax.do?method=...发送一个POST请求，其报文头或参数可能设置了特定的值，用于绕过权限验证。拦截到的请求可能看起来平平无奇，但关键就在某个参数值或Cookie里。
   • 请求二：利用上传功能，发送一个 multipart/form-data 格式的POST请求，将JSP Webshell作为文件部分上传。文件名可能经过随机化处理，以规避简单的文件后缀检查。
   • 请求三：尝试访问上传的文件路径，根据HTTP状态码（200成功，404失败）来判断是否上传成功。

理解这些请求，能帮助你在工具失效（例如目标系统已修补）时，手动调整payload进行测试，或者编写自己的检测脚本。

4. 授权测试全流程实战记录

下面我模拟一次完整的、合规的授权测试流程，将漏洞原理和工具使用串联起来。

4.1 前期信息收集与确认

在拿到授权书后，第一步不是直接运行工具。而是：

• 确认目标范围：授权书明确写的是oa.xxx.com这个主域名，那么测试就严格限制在此域名下，不应对其子域名或其他关联系统进行探测。
• 基础信息收集：使用nslookup、ping了解目标IP。使用浏览器简单访问，确认是致远OA的典型登录界面。查看页面底部或帮助页面，初步判断版本（例如，版权信息显示“致远互联A8-V5”）。
• 测试环境准备：在我的Kali Linux虚拟机上配置好Python环境、seeyon_exp工具，并打开Burp Suite设置好代理，准备拦截所有流量以便分析。

4.2 渐进式漏洞探测

我遵循“先无害，后有害；先读，后写”的原则。

1. 手动试探：首先在浏览器中手动输入几个常见的信息泄露路径，如/seeyon/management/status.jsp。发现返回403 Forbidden，看来这个版本可能默认关闭或加强了访问控制。这是一个好迹象，说明管理员可能做过一些安全加固。
2. 工具初步检测：运行python3 seeyon_exp.py -u http://oa.xxx.com。工具运行后，在result.txt中发现了一条关键记录：

   [+] http://oa.xxx.com/seeyon/common/designer/pageDown.jsp?downType=excel&filePath=WEB-INF/web.xml 存在任意文件下载漏洞

   这证实了DownExcelBeanServlet漏洞存在。
3. 手动验证与利用：我复制这个URL到浏览器，果然开始下载一个web.xml文件。打开后，找到了数据库连接字符串，其中包含了数据库IP、端口、库名和加密的密码。至此，我已经拿到了非常敏感的信息，并立即记录在测试报告中。在授权测试中，到这一步已经可以证明系统存在高危漏洞，通常就会暂停进一步利用，优先报告。但为了完整演示，我们假设授权范围允许继续。

4.3 关键漏洞利用尝试

根据工具检测结果，目标还存在ajax.do漏洞。我决定手动验证一下，而不是直接用--att参数。

1. 我使用Burp Suite的Repeater模块，手动构造一个指向/seeyon/ajax.do的POST请求，并参照工具可能使用的payload（通过之前拦截的流量学习到），在请求体中添加了method=ajaxAction&managerName=...等参数。
2. 发送请求后，返回的响应不是常见的“未登录”或“权限不足”，而是一个包含“success”或某些业务数据的JSON响应。这强烈暗示登录绕过是成功的。
3. 此时，我并没有立即上传Webshell。在真实的授权测试中，对于这种能直接getshell的漏洞，我会非常谨慎。我需要和客户确认，他们是否允许进行这种可能影响系统稳定性的攻击测试。如果允许，我会选择在一个非业务高峰时段，上传一个无害的测试文件（如一个只包含<% out.println("test"); %>的简单JSP）来验证上传功能是否真的可用，而不是直接上传功能强大的冰蝎马。

4.4 后渗透模拟与痕迹清理

在获得Webshell连接后（假设已获得授权），模拟攻击者可能会做的操作：

• 信息收集：使用冰蝎的虚拟终端，执行whoami、ipconfig /all（Windows）或id、ifconfig（Linux）、systeminfo等命令，了解服务器权限、网络环境。
• 权限提升：检查当前用户权限，如果是低权限用户，尝试利用系统本地提权漏洞。
• 内网探测：利用服务器作为跳板，探测内网其他主机（这必须严格在授权网络范围内进行！）。
• 数据访问：定位OA的数据库，尝试连接并导出关键业务数据（用于证明漏洞危害，而非窃取）。

重中之重：痕迹清理。授权测试的最后一个环节是清理测试过程中产生的所有痕迹，这是职业操守的体现。

1. 删除Webshell：通过冰蝎的文件管理功能，找到上传的JSP文件，彻底删除。
2. 清理日志：查找OA应用日志（如Tomcat的catalina.out、localhost_access_log）、系统日志（Windows事件查看器、Linux的/var/log/），删除或修改包含你测试IP和攻击payload的日志条目。注意：有些日志是实时写入且不可篡改的，对于这些，应在测试报告中明确说明可能留下的日志痕迹。
3. 恢复配置：如果测试中修改了任何系统或应用配置（如为了验证漏洞临时关闭了某项安全设置），必须将其恢复原状。
4. 生成报告：最后，将漏洞发现过程、利用步骤、危害证明（截图）、修复建议整理成详细的报告，交付给客户。

5. 常见问题排查与防御建议

在实际使用seeyon_exp或进行手动测试时，你肯定会遇到各种问题。下面是我总结的一些常见情况及应对方法。

5.1 工具运行与利用失败排查

5.2 针对致远OA系统的防御加固建议

对于系统管理员而言，亡羊补牢永远不晚。以下是一些关键加固措施：

1. 及时更新与补丁管理：这是最根本、最有效的措施。立即关注致远官方发布的安全公告和补丁，并尽快在测试环境验证后，应用到生产系统。很多被利用的漏洞都是早已公布并有官方补丁的。
2. 最小化权限原则：
   • 应用权限：运行Tomcat等中间件的系统用户，不应具有过高权限（如root、Administrator）。使用专用低权限账户。
   • 目录权限：严格限制Web应用目录（如webapps/seeyon）的写权限。静态资源目录只读，仅允许上传功能的特定目录有写权限，且该目录应禁止脚本执行。
   • 数据库权限：为OA应用连接的数据库账户分配最小必要权限，通常只授予特定库的增删改查权限，杜绝FILE、PROCESS等高级权限。
3. 强化访问控制：
   • 后台管理入口：将后台管理地址修改为不易猜测的路径，并设置强密码和二次验证。
   • 敏感接口：对ajax.do、*.jsp等通用或敏感接口，实施严格的访问控制列表（ACL）或基于角色的权限验证，确保每个请求都经过充分的会话校验。
   • 信息泄露路径：删除或重命名status.jsp、test.jsp等非必需的管理和测试页面。如果必须保留，则配置防火墙策略，只允许管理员IP访问。
4. 部署安全防护设备：
   • WAF（Web应用防火墙）：在OA服务器前端部署WAF，可以有效拦截SQL注入、路径遍历、恶意文件上传等常见Web攻击。
   • IDS/IPS（入侵检测/防御系统）：监控网络流量，对异常访问模式（如短时间内大量访问敏感路径）和已知攻击payload进行告警或阻断。
5. 安全编码与配置：
   • 对所有用户输入进行严格的过滤和校验，使用参数化查询杜绝SQL注入。
   • 文件上传功能要同时校验文件后缀、文件类型（MIME Type）、文件内容，并将上传的文件重命名、存储在非Web可访问目录，通过程序映射访问。
   • 定期进行安全审计和漏洞扫描，主动发现潜在风险。

5.3 授权测试中的法律与道德边界

最后，我必须再次强调合规的重要性。授权测试是一把双刃剑，用得好可以帮助企业提升安全，用不好则会害人害己。

• 获取书面授权：测试前，必须获得目标系统所有者的明确书面授权，授权书应清晰界定测试目标、范围、时间、方式以及双方的责任。任何超出授权范围的操作都是非法的。
• 最小影响原则：测试应以不破坏系统稳定性、不影响正常业务为前提。避免使用压力测试工具进行DDOS，避免删除或修改真实业务数据。对于上传Webshell等高风险操作，务必事先沟通并获得许可。
• 数据保密：在测试过程中接触到的任何数据（包括漏洞利用过程中获取的数据），都必须严格保密，仅用于撰写测试报告证明漏洞危害，并在报告交付后妥善销毁，不得留存、传播或用于其他任何目的。
• 完整报告：测试结束后，应提供详尽、专业的报告，不仅说明漏洞，更要给出清晰、可操作的修复建议，帮助客户真正解决问题。

这次对致远OA的测试复盘，让我再次感受到，安全测试不仅仅是技术活，更是责任活。工具让我们的工作更高效，但对漏洞原理的深入理解、对测试流程的严谨把控、以及对法律边界的清晰认知，才是我们在这个行业里安身立命的根本。每一个漏洞的背后，可能都关系着一个企业的正常运转，谨慎，再谨慎，总是没错的。