帆软10.0 Getshell漏洞分析

由于帆软10.0报表系统前台只有一个登陆口，并且10.0的认证机制做了很大的改动，想要通过文件读取或者其他漏洞来获取管理员信息几乎不可能，所以下面所述的几个漏洞都是需要用户登录权限。getshell漏洞是由多个漏洞组合而成，比较有意思，故分享出来。

帆软软件（以下简称“帆软”）成立于2006年，是中国专业的大数据BI和分析平台提供商，专注商业智能和数据分析领域，致力于为全球企业提供一站式商业智能解决方案。帆软在专业水准、组织规模、服务范围、企业客户数量上均为业内前列，先后获得包括Gartner、IDC、CCID在内的众多专业咨询机构的认可。并于2018年入选福布斯中国非上市潜力企业榜50强，工信部中国电子信息产业发展研究院与中国大数据产业生态联盟“中国大数据企业50强”。

这里测试的版本为帆软报表v10.0(2019-07-19更新)，厂商提供了软件版和服务器版，经过测试发现两个版本都存在同样的问题，不过服务器版由于多了tomcat的功能，所以利用链可能更丰富点。

联想到8.0系统的getshell流程，任意文件读取->任意文件上传->任意文件重命名，那么虽然更新了版本，但是已知漏洞的尝试，然后寻找绕过手法成了我的第一选择。这里就从原先出问题的插件上传模块入手，看看能否上传一些恶意文件等。

根据8.0漏洞的思路，我们直接从本地安装一个zip包，这个zip包里含有jsp shell，但是会提示“未找到安装包”，这里没看源码，直接拷贝了一份已有的插件目录，然后在目录下插入任意文件，发现上传成功

原先一个插件包里应该包含一个xml文件和插件对应的jar包文件，这里我插入了一个jar包文件，一个jsp文件，至此已经能够上传任意文件到目标服务器上。

重命名漏洞没有专业的名词来解释这个漏洞，大意就是通过文件名重命名来移动文件位置，这个移动位置可能造成的漏洞有任意文件读取、命名执行等，所以这个重命名漏洞利用好了就是一个核弹，利用不好就是一块板砖。

漏洞代码位于com.fr.web.controller.decision.api.map.edit.MapEditResource中的entry函数，这里比较特殊的一点就是使用了PUT方式来传输数据

@RequestMapping(value = {“/entry”}, method = {RequestMethod.PUT})

@ResponseBody

public void renameEntry(HttpServletRequest paramHttpServletRequest, HttpServletResponse paramHttpServletResponse, @RequestBody Map<String, Object> paramMap) throws Exception { MapEditService.getInstance().renameEntry(GeneralUtils.objectToString(paramMap.get(“oldPath”)), GeneralUtils.objectToString(paramMap.get(“newPath”))); }

我们跟进MapEditService中的renameEntry函数，代码位于com.fr.decision.webservice.v10.map.MapEditService

继续跟进也没什么意思，最后函数肯定是两个文件流进行读取和写入

跟进到最后com.fr.geojson.helper.GEOJSONHelper，发现使用rename函数来实现重命名

通过对页面功能的查询，这里也找到了对应的功能界面

这里命令执行可以说是整个利用链的最关键的地方，在看一些通用接口时发现存在一个反射动态调用class的地方，怎么看都觉得有问题，漏洞代码位于com.fr.web.controller.common.FileRequestService

重点看CLASS的分支，就会发现下面使用了Reflect反射来动态调用class类，并且这里没有任何的class限制，那么这里只需要找到一个class类，然后看看能否做些文章。

这里找到一个继承了TextGenerator的class，但是不太尽如人意，这里原本想要找的是继承了TextGenerator的class，并且class类中有能够控制的参数，并且还要含有命令执行的函数，找了一圈没找到，此路放弃。

配合前面两个漏洞我决定直接上传一个新的jar包来覆盖原先jar包，这个新的jar包中的class是被我篡改过的，引入了命名执行的代码。这里选择在ConstantGenerator中加入了恶意代码，这个类在程序加载的时候会自动调用，所以优先对这个类进行了篡改。

替换恶意jar包命令包含：

1)javac -cp fine-decision-10.0.jar:fine-core-10.0.jar:servlet-api.jar com/fr/decision/web/constant/ConstantGenerator.java

2)jar -uvf fine-decision-10.0.jar com/fr/decision/web/constant/ConstantGenerator.class

至此我们已经能够生成了恶意的jar包，下面开始组合漏洞进行Getshell

首先利用插件上传将恶意的jar包附在插件目录下，通过后台的插件管理平台上传新的插件包

其次利用文件重命名漏洞将恶意的jar给移动到指定的lib目录下，以覆盖原先jar包

PUT /webroot/decision/map/entry

{“oldPath”:”plugins/plugin-com.fr.plugin.mobile.web-10.2.21/fine-decision-10.0.jar”,”newPath”:”lib/fine-decision-10.0.jar”}

最后重启服务器即可，可以看到已经弹出了计算器。

账号认证那块由于比较复杂，没有动态调试有点看的晕乎乎的，所以前台登录那块暂时还没找到相关漏洞，另外由于java都是先将程序加载到内存里，所以需要重启服务器才能使配置生效，这两点可能算比较影响漏洞质量的关键因素吧。