【vulhub漏洞复现】Auth Bypass -- Apache OFBiz 身份验证绕过导致远程代码执行 (CVE-2024-38856)
本文最后更新于 2026年3月16日 下午
Apache OFBiz 是一个开源的企业资源规划(ERP)系统。它提供了一套企业应用程序,用于集成和自动化企业的许多业务流程。
这个漏洞是由于对 CVE-2023-51467 的不完全修复而产生的。在 Apache OFBiz 18.12.11 版本中,开发人员认为他们已经修复了该漏洞,但实际上他们只解决了其中一种利用方法。Groovy 表达式注入仍然存在,允许未经授权的用户在服务器上执行任意命令。
1.什么是Groovy?
https://www.w3cschool.cn/groovy/
Groovy是一种基于JVM(Java虚拟机)的敏捷开发语言,它结合了Python、Ruby和Smalltalk的许多强大的特性,Groovy 代码能够与 Java 代码很好地结合,也能用于扩展现有代码。由于其运行在 JVM 上的特性,Groovy 可以使用其他 Java 语言编写的库
2.Groovy试用场景
Groovy 诞生的核心目标是补充 Java 的不足—— 既保留 Java 的生态优势,又解决 Java 语法繁琐、脚本化能力弱的问题,因此它的应用场景几乎都围绕「Java 生态」展开,主要分为以下几类:
1. 企业级应用的「动态业务逻辑」(核心场景,关联 OFBiz 漏洞)
这是 Groovy 最核心的应用场景,也是它出现在 OFBiz 中的原因:
- 适用场景:企业系统(如 ERP、CRM、电商平台)中,很多业务规则需要「动态调整」(比如价格计算规则、订单审核逻辑、权限控制规则),如果用 Java 写,修改后需要重新编译、重启应用,成本很高;
- Groovy 的优势:可以把这些动态规则写成 Groovy 脚本,存储在数据库 / 配置文件中,应用运行时直接加载执行,修改规则无需重启系统;
2. 自动化脚本 / 工具脚本(替代 Shell/Perl)
Java 开发者写自动化脚本(比如部署脚本、数据清理脚本、日志分析脚本)时,用 Java 写太繁琐(需要写类、main 方法),而 Groovy 兼容 Java 所有 API,语法又极简
3. 构建工具(Gradle 核心语言)
你日常接触的 Android 开发、Java 项目构建工具 Gradle,其核心脚本语言就是 Groovy(后来也支持 Kotlin,但 Groovy 仍是主流)
4. 自动化测试(Spock 测试框架)
Groovy 衍生的 Spock 框架是 Java 生态中最强大的测试框架之一,比传统的 JUnit 更简洁、可读性更高,广泛用于 Java/Groovy 项目的单元测试、集成测试
5. Web 开发(Grails 框架)
Grails 是基于 Groovy 的 Web 框架,底层封装了 Spring Boot,语法比 Spring Boot 更简洁,适合快速开发中小型 Web 应用
6. 应用扩展 / 插件开发
很多 Java 应用允许用户通过 Groovy 脚本扩展功能(支持「热插拔」),比如:
- Jenkins(持续集成工具):部分插件和自定义构建步骤可以用 Groovy 编写;
- Elasticsearch(早期版本):支持 Groovy 脚本实现动态的索引计算、查询逻辑(后来因安全问题禁用)
3.漏洞原理
这个漏洞的核心就在于外部可以直接注入执行Groovy代码调用系统命令
CVE-2024-38856 这类 Groovy 注入漏洞,必须同时满足以下 4 个条件才会发生:
系统使用 Groovy 支持动态脚本执行;
系统接收外部用户可控的输入(HTTP 参数、表单、报文等);
开发者将这些输入传入 Groovy 的执行引擎(如
eval()、ScriptEngineManager);开发者未对输入做有效过滤 / 权限限制(比如仅用黑名单过滤关键字,或未启用 Groovy 沙箱)
只要打破其中任意一个条件,漏洞就不会发生
4.漏洞复现
/webtools/control/main/ProgramExport 是 OFBiz 用于处理 Groovy 程序导出的功能接口,该接口的groovyProgram 参数未做严格过滤,会直接执行传入的 Groovy 代码
使用bp构造请求
1 | |
——WebKitFormBoundaryDbR7sY3IIwQX7kcJ这个是边界,可以自定义,
例如:
1 | |
查看报错可以看到返回信息,执行cat /etc/passwd
成功绕过
3.其他思路
(1)无源码也能做:黑盒盲测(核心靠 “规律 + 测试”)
第一步:用 Nmap 枚举接口
(衔接之前的目录扫描):
1nmap -p 8443 --script http-enum --script-args http-enum.use-ssl=true 目标IP扫描,重点关注
1/webtools/control/路径下的接口(OFBiz 核心功能都在这里);
第二步:筛选高风险接口:
优先测试命名含 “Service、Program、Script、Groovy、Export、Import” 的接口(这类接口大概率处理动态脚本),比如
1/SOAPService(SOAP 服务常处理动态参数)、
1/ProgramExport(程序导出可能执行脚本);
第三步:测试是否支持 Groovy 执行:
- 对 SOAP 接口:发送含
<cgitool>%25{1+1}</cgitool>的 SOAP 请求,若响应返回2,说明表达式被执行;- 对表单接口:用
multipart/form-data格式提交groovyProgram=1+1,若响应返回2,说明参数可被 Groovy 解析;第四步:验证 RCE 可行性:
把表达式换成
1'id'.execute().text,若返回系统用户信息,即确认是注入接口。
(2)精准定位:白盒源码审计(有源码时)
关键词检索(核心!):
下载 OFBiz 目标版本源码,用 IDE 全局搜索以下关键词,直接定位风险代码:
- 执行相关:
groovy.eval、ScriptEngineManager、GroovyScriptEngine、execute();- 漏洞参数相关:
cgitool、groovyProgram;- 接口路径相关:
/webtools/control/、SOAPService、ProgramExport;追踪参数流向:
找到关键词所在代码后,看参数是否来自外部请求
1request.getParameter("groovyProgram")且未做过滤就传入 Groovy 执行引擎
1engine.eval(参数)确认接口映射:
OFBiz 接口通过配置文件
1controller.xml映射,找到风险参数对应的
1path,即可确定注入接口
1path="/webtools/control/main/ProgramExport"