常态期讨老口子3: JeecgBoot 模板注入分析

黑伞安全 · 公众号 · · 2024-07-24 20:43

正文

这段常态化时期，每天都整理和学习历年能打穿小朋友的漏洞，本文转载自

https://forum.butian.net/share/2491 这个师傅写的真得很细

这篇文章是关于某系统模板注入漏洞的分析，具体内容如下：

漏洞概述：

漏洞是由于程序在处理传入的SQL语句时使用了Freemarker模板渲染，导致模板注入问题。

SQL注入分析：

文章首先介绍了SQL注入问题，通过分析公开的payload和接口逻辑，发现程序对传入的SQL语句进行了黑名单过滤，但存在漏掉的 exp() 函数关键字，可以利用它进行报错注入。

模板注入分析：

进一步分析发现，程序在处理SQL语句时，使用了Freemarker模板，这导致了模板注入漏洞。
通过分析代码，发现传入的 sql 参数值被当作模板处理，Freemarker模板中的语句可以创建一个继承自 TemplateModel 类的变量。
利用Freemarker的 Execute 类，可以执行系统命令，从而实现模板注入。

漏洞利用过程：

文章通过反编译和调试，详细分析了漏洞的成因和利用过程。
描述了如何通过构造特定的payload来绕过SQL关键字过滤，以及如何利用Freemarker模板引擎执行系统命令。

修复措施：

官方在最新版本中使用了 setNewBuiltinClassResolver(TemplateClassResolver.SAFER_RESOLVER) 来禁用Freemarker模板注入中常用的三个类的解析，从而修复了该漏洞。

某系统前阵子公开了模板注入的漏洞，漏洞点在于程序对传入的sql语句处理时使用了freemarker模板渲染导致的问题。代码对该接口传参的处理先经过sql关键字的过滤，且分析中发现了一处可用的sql注入的payload,故先从sql注入开始介绍。

1.sql注入

下载源码后导入idea运行（使用mysql数据库）

先来看一眼公开的模板注入的payload，传参的字段和接口名称让人不免怀疑此处是否还有sql注入，于是看看接口逻辑

POST /jeecg-boot/jmreport/queryFieldBySql HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Content-Length: 100

{"sql":"select '${value(\"whoami\")}'"}

反编译漏洞依赖包后导入idea，全局搜索queryFieldBySql定位漏洞代码如下

打上断点，bp发送payload({"sql":"select 1 from demo"})，开始调试

进入i.a()方法

定义了黑名单的sql关键字

String[] var1 = " exec |peformance_schema|information_schema|extractvalue|updatexml|geohash|gtid_subset|gtid_subtract| insert | alter | delete | grant | update | drop | chr | mid | master | truncate | char | declare |user()|".split("\|");