java代码审计-内容管理系统

本文章仅供学术研究

如果想要快速定位漏洞点可以直接使用一些敏感函数进行搜索，如果要找整个源码的安全问题，还是无非要对每个controller进行调试

首先分析下这个网站使用的是哪些框架组件

pom.xml

主要的是Net.mingsoft的依赖，源代码大部分保存在maven包下，也是我们重点审计对象

我们可以通过maven的download sources来下载源文件

dependency-check-maven

由于站点的部分源码在jar包下，所以我们只能将前面的pom.xml，将包的pom.xml复制到本地的pom下之后report

我们重点关注的是spring、freemarker、jackson、fastjson、log4j2、Elasticsearch

通过扫描发现shiro存在默认密钥，可造成代码执行，mybatis也存在二级缓存反序列化漏洞，没找到对应poc可以测试，大概率存在漏洞，fastjson也存在反序类和漏洞

application.yml

关注点在黑白名单、认证相关的key，这是我们重点观察的地方

文件上传黑名单

config目录

ShiroConfig.java

目录权限检测

SwaggerConfig.java

REST API配置，查看下是否存在api接口泄漏

swagger-ui接口配置不对，访问不到，应在启动类加上一个@EnableSwagger2注解即可被访问，则不存在接口泄漏问题

WebConfig.java

webConfig.java

api鉴权的spring mvc拦截器

xss过滤器

简单测试了下payload，就很奇怪后端写的不知道为什么没能执行过滤器，这是因为前端用的是vue框架，实体化了标签说明前端做了过滤

不会走到下面的new一个XssHttpServletRequestWrapper，直接在下面直接doFilter

网站目录结构

fortify扫描检测

使用fortify是无法扫描到jar包的源文件，但是该目录重要文件都是jar包，所以我们可以使用JD-gui将jar包导出到一起再通过fortify进行扫描

未授权检测

通过梳理出所有api接口，使用dirsearch来扫描目标

访问200页面大部分是用户的功能，可以说鉴权写的没问题

模板注入

虽然FreeMarker中预制了大量的内建函数,极大地增强和拓展了模板的语言功能，但也可极大地增强和拓展了模板的语言功能，但也可能引发一些危险操作。若研发人员不加以限制，则很可能产生安全隐患。

freemarker.template.utility.Execute继承了TemplateMethodModel，实现了exe方法

插入poc，点击上面保存

${"freemarker.template.utility.Execute"?new()("calc")}

访问http://localhost:8080/mcms/index.do，成功弹出计算器

SQL注入

使用free-mybatis插件跳转到mapper文件中

dao层的接口

通过find usages来查找调用链

看到service实现层调用了query函数，并且没有看到过滤的代码

发现dict可控

尝试单引号报错，并且存在延迟和报错注入

文件上传

jspx后缀绕过

据前面过滤的文件后缀是jsp和exe，但是忘记了jspx可以进行绕过

全局搜索new File

可以看到这是一个统一的文件上传的方法

我们搜索调用链，可以看到FileAction调用到了upload

找到一个上传点，传入了Bean类，Bean有两个参数，只需要传入file即可

构造payload，上传成功

编辑器图片上传后端代码存在缺陷

编辑器在上传的时候，用户上传文件后缀可控，导致的文件上传，最终可以导致命令执行

主要的上传代码是这一段

用户可以对jsonConfig可控，并且jsonConfig可以修改获取到编辑器的配置

修改配置后，执行exec函数

并且我们exec并没有传入callbackName参数，直接执行到下面的invoke方法

通过获取到上传的类型，也就是我们上传的是图片

走到上传图片的case执行下面代码，获取配置传入Uploader进行上传

我们可以看到configManager.getConfig存入的配置，可以看到是一个数组

通过doExec进行上传

我们存入一个imageAllowFiles数组加入一个.htm后缀

"imageAllowFiles":[".htm"]}

成功上传

我们访问网页并没有对模板进行渲染，我们可以通过search的BasicUtil.getString方法来获取我们注入的模板payload，也就是说我们要加个tmpl参数指向我们传的网页

最终search通过ParserUtil.rendering传入

可以看到通过rendering方法的buildTempletPath在这个模板路径下查找，正好我们传入htm文件就在这个路径下

通过获取模板文件，添加到自定义模板中

最后通过process进行生成

成功渲染

任意文件删除

该漏洞出现是在FileUtils.deleteDirectory删除目录的函数上，并没有对非法路径进行过滤

找到模板，点击删除，进行抓包

可以看到数据包是该功能点的

可以看到heima的模板在template的1文件夹下

我们在webapp下创建test文件夹

成功删除