记一次后台 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

在我们日常渗透测试过程中,有很多很多类似于这种的逻辑漏洞,可能就在我们不经意间就错过了,不过只要思路清晰,应该就没有问题了
标签: