奇安信攻防社区-代码审计之上传自解压漏洞

代码审计之上传自解压漏洞

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

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/空

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-76266f6908f27a73c758f8422bed4f168d50221f.png)

0x02 漏洞分析
=========

IDEA全局搜索关键字 unzip

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-4fac47be119bd843371e39442d862722d6e4e8cc.png)

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

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-70717c85de6f1bb9f6fe0ed44a08d3508f9281f1.png)

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-ab69a28bdb28407f8c323183a846a495289d942a.png)

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-b5552ed6d2930052999732fe78f73e4791f647d5.png)

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-0e5efca360e9fc9f7eeaa917748f479e08b2dafe.png)

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-97928a5dc193c8a6b9f0d15fb7bbfab04af280a0.png)

回到Controller层

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

后面的代码就无关紧要了

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-9d917caa480ac9ec8a826bca35e0fec311e36eb8.png)

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-f35e21a342d0fd5baeda7b0b31b58e9513cc4142.png)

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

```php
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
```

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-9abe9f699c3cac8c1fb64e60e57c265f576114b3.png)

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

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-4db9793511e2d6b36ee1c255da1faada9525e9d1.png)

上传成功

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-cdb4df1bc7e5a241b33c4b413fab27ae6dc10aee.png)

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-e8bb759f96ac88d20bdc02927e62b24323280fe4.png)

访问成功

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-97efd1da3d0502b0ec033090025e3e8919ff7b6b.png)

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-2bad07d3f97fb9954c160b07ef4e2995e027b43a.png)

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-227795c11247a6418197f4ffefbd3e4d02db9ba9.png)

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

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-0af1443761ca442d0d5b59911d3ae2163bdb1e83.png)

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-c568b3c77fbd40f7a9a77bde3906ee429f95535d.png)

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

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

![图片.png](https://shs3.b.qianxin.com/attack_forum/2022/04/attach-9bae1a196496675c897df98792cc78b4b53d2314.png)

0x03 修复建议
=========

升级版本

0x04 总结
=======

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

发表于 2022-04-02 09:41:08
阅读 ( 6105 )
分类：代码审计

1 条评论

Gocker 2022-04-15 09:55

正在向代码审计领域学习中，感谢楼主文章，可以作为学习资料和对比参照物。