记一次后台 getshell 测试过程
最近团队在对某个厂商进行测试，在进入后台后的情况下进行黑盒测试，这次 webshell 差点被厂商以 “管理员身份进行 webshell 为由” 给我个低危评价，后面在我据理力争之下最终保住了，此漏洞在最新版本中也修复了
首先进入后台是这样子的：
通常后台最容易出现漏洞的地方在哪里呢?
在日常渗透测试过程中，进入后台后，首先考虑的是系统管理模块，该模块通常是控制整个软件的核心，是最关键的模块之一，也是最容易出漏洞的地方
在插件管理处，可以从本地安装插件，是选择一个压缩文件进行上传的，本来是想测试看看是否有文件上传漏洞的，测试了各种方法，各种 bypass 都不行，最后只能把目光放在压缩包之中了，我就不信了，压缩包里面的内容总不会被查吧.....
先分析下从上面安装之后的插件里面有点什么
在插件目录中出现了一个含有 system.check 的目录
进去看看有些什么
里面有两个文件， jar 文件和 xml 文件， jar 文件是插件应该就是插件的本身了， jar 文件我们是改动不了，那只能把目光发在 xml 文件中了
粗略分析一下 xml 内容就可以看出，这些是定义了一些插件的信息，比如定义了插件的主包是哪个等一系列信息，也就是说xml文件是必须存在的，不然的话软件是无法读取到插件信息，从而无法上传成功
那如果我们构造恶意压缩文件时，只需要有这个 xml 文件，是不是就可以上传上去了?
话不多说直接实操，先复制上面那个 xml 文件，然后再放入一个恶意的 jsp 文件
然后打压成压缩包上传
显示该插件已经安装了更高的版本，那就证实了之前的猜测，软件会去读 xml 文件的信息，那我们只需更改更高的版本或者直接手动删除这个插件就可以了，我们选择第一种方法吧
在 xml 文件中直接修改插件版本
这次是提示我是否更新，我们按确认
这里显示已经更新成功了
插件目录也出现了一个新的目录，是我们刚刚上传插件后解压后的目录
里面就是我们刚刚构造的插件包了，不过 plugin-com.fr.plugin.report.system.check-1.1.0 目录名太长了，先来分析下目录名的规律，他是以 - 符进行分割，plugin 是标识插件的，每个插件目录都会存在，中间部分之前在 xml 文件中看到了，应该就是可以在 xml 文件中修改
将id修改为 shell，版本重新修改为 1.2.0 了，再根据所有插件目录前面都有 plugin 的这个规律，那么生成后的目录应该就会是 plugin-shell-1.2.0 了
果不其然，成功生成了一个 plugin-shell-1.2.0
不过上传之后发现这软件貌似是走路由的，网页上根本访问不了，现在只能去找那种移动目录地方了
后面团队中的一个大佬发现在备份还原中有一个备份插件的功能，备份后的文件夹会在 web 根目录下创建一个 backup 的目录，backup 目录就是存放备份的目录，看上去这没啥，可是，backup 是在 web 根目录下面创建的，web 根目录下面创建的!也就是说我们可以访问!!!
设置备份目录名字确认即可
可以看到 web 根目录中创建了 backup 目录，然后 backup 里面就是套娃了，一个目录套一个，最后到了我们我们刚刚备份好的目录下面
本以为里面就是我们备份的插件了，没想到里面居然还套了一层
然后选择 plugin 目录，终于出现了我们备份的插件了
上面这些目录都是可以推算出来的，所以在黑盒测试的时候完全可以放心，接下来就是见证奇迹的时刻了
直接访问恶意代码的路径：
backuppluginsmanualshellpluginsplugin-shell-1.2.0shell.jsp
在我们日常渗透测试过程中，有很多很多类似于这种的逻辑漏洞，可能就在我们不经意间就错过了，不过只要思路清晰，应该就没有问题了
