0x00 前言

最近在学习java代码审计, 这两天看了一篇Java审计文章后, 举一反三, 写了本篇文章. 上传自解压漏洞是一个容易被 大家忽略的漏洞, 一些网站对上传功能进行了黑白名单过滤, 但当网站有一些上传压缩包功能需求的时候, 就可能忽 略解压后的文件是否为恶意文件, 进而可能产生漏洞.

0x01 环境搭建

本文使用的是jspxcms_v9.0.0版本代码来学习该漏洞
安装包下载地址: https://www.ujcms.com/uploads/jspxcms-9.0.0-release.zip
源码下载地址: https://www.ujcms.com/uploads/jspxcms-9.0.0-release-src.zip

网站搭建过程如下:
1.创建数据库, 导入database目录下的sql文件数据. 2.将压缩包中的ROOT目录替换掉Tomcat自身的ROOT目录.
3.修改 ROOT\WEB-INF\classes\application.properties 配置文件中的数据库配置. 4.启动Tomcat.
5.访问 http://192.168.77.3:8080/cmscp/index.do
如下图所示, 即环境搭建完成.
默认密码: admin/空

0x02 漏洞分析

IDEA全局搜索关键字 unzip

有好几处接口存在问题, 这里我们选择进入SiteController.java第157行

src/main/java/com/jspxcms/core/web/back/SiteController.java

这是一个后台接口, 我们需要先登陆再进行测试

通过该方法接收参数可以看到, 这里只接收了一个标准的上传数据包 根据已知的漏洞, unzip方法会自动解压我们上传的zip文件 我们构造一个上传数据包打断点看下代码逻辑

这里代码逻辑比较清晰, 如下图所标记, 主要做了以下处理:
1.接收上传数据
2.将数据流写入临时文件中
3.解压临时文件

我们跟进com/jspxcms/common/file/AntZipUtils.java文件中的unzip()方法 AntZipUtils工具类如下图所标记, 主要做了以下处理:
1.遍历临时压缩包中的文件
2.利用遍历得到的文件名创建File对象
3.从压缩文件中读取指定文件的数据流
4.将读取到的数据流写入创建的File对象指定的位置
依次循环遍历, 完成解压.
可以看到, 这里并没有代码校验解压后文件的类型

回到Controller层

AntZipUtils.unzip(tempFile, unzipFile); //到这里解压操作已经执行完成 
FileUtils.deleteQuietly(tempFile); //删除临时压缩包文件

后面的代码就无关紧要了

请求完成后响应会报错, 但压缩包已经上传并自解压完成

此时后端的主要操作如下:

1.将前端接收的压缩包存储为临时文件 C:\\apache-tomcat-8.5.73\\temp\\099c70ab\_56ed\_4f88\_815d\_1762e1dcabb4000000018.tmp

2.以当前临时文件名为路径创建目录,解压临时文件到  
C:\\apache-tomcat- 8.5.73\\temp\\099c70ab\_56ed\_4f88\_815d\_1762e1dcabb4000000018.tmp\\print.jsp

3.删除临时文件 C:\\apache-tomcat-8.5.73\\temp\\099c70ab\_56ed\_4f88\_815d\_1762e1dcabb4000000018.tmp

在服务器上可以看到文件已经解压成功

但此处并不能访问, 我们需要将一个war文件上传到 C:\apache-tomcat-8.5.73\webapps 目录下 然后tomcat会自动对war包进行解压部署

1.制作一个恶意war包
2.利用python脚本将war包打包为目录穿越的zip文件 (向上跳2级目录,到webapps目录下)

上传成功

访问成功

这里需要注意, 如果直接上传jsp脚本文件到jspxcms项目目录下, 我们去访问时jsp文件时, 过滤器会自动在我们访问 的路径前加上/jsp 目录, 进而无法访问我们的文件.

具体原因文末参考文章中已经分析过了, 有兴趣可以再阅读下.
写着写着突然有了一个想法, 既然访问jsp文件时会自动在路径前加上/jsp 目录, 那我们可以直接利用这个特性, 将

shell上传的jsp目录下, 不就可以访问成功了? 测试结果发现是可行的哈哈

到这里该上传自解压漏洞已经利用完成了, 但此时只是一个后台漏洞. 我们从pom.xml文件中可以看到shiro版本为1.3.2

低版本shiro是存在权限绕过漏洞的, 整好此处没有再做额外的权限校验. (几个漏洞位置貌似只有这里没做...) 我们可以通过将两个漏洞组合利用, 变为前台RCE.

经过测试, 利用成功. 去掉Cookie后请求对比效果如下:

0x03 修复建议

升级版本

0x04 总结

很多时候, 我们做代码审计挖掘到的大多数是后台的漏洞, 这时我们尽可能的可以再去找一个类似权限绕过的漏洞去 配合, 将后台漏洞变为前台漏洞. 文章内容不完全正确, 如发现错误还请各位师傅多多指出.