0x01 前言

某1day漏洞，从拿代码到审计getshell，全历程。后来review发现影响很多站点。

0x02 黑盒测试任意文件下载

前台看到有相关附件下载，如下：

点击下载功能，发现URL长这样：

/xxxx/downloadFiles?downloadInfo={files:['uploadfiles/bd/doc/xxxxxx.pdf']}

直觉告诉我这里存在任意文件下载，于是进行测试。

/xxxxx/downloadFiles?downloadInfo={files:[%27/WEB-INF/web.xml%27]}

果然可以，然后分析web.xml文件，然后看具体代码位置。

偶然看到该接口可以批量下载，如下：

那先下载DownloadFilesServlet进行分析，看一下具体怎么批量下载。

结果却找不到该类，然后看了下还有其他批量下载的接口，比如：

尝试下载，发现：

开整，分析。

0x03 代码审计

3.1 任意文件下载

因为没有拿到DownloadFilesServlet 代码，所以只能分析替代品WcDownloadFilesServlet.class 代码了，，看看其怎么批量下载，然后拿到完整代码进行分析。

（1）首先从前端传入downloadInfo，然后处理成json，如果json为空，提示下载失败。

（2）84-86行代码中，把json解析好以后，传入了downLoadFiles函数。

（3）跟进downLoadFiles函数的实现如下：

跟进下getAllFiles方法，看一下其获取的所有文件的方法。

概括一下：

• 如果输入的内容中有?、*一类的字符，会认为你是通过正则类型匹配下载文件，然后解析正则，下载你想要的文件
• 如果文件名不存在正则，那么就会拼接目录，递归解析目录，然后把所有目录中的文件的绝对路径都解析出来，形成一个数组fVector

然后回到downLoadFiles中，如果返回的files.size()为1，则调用downSimple,即只下载单一代码。否则进行压缩后下载。

（4）跟进downZipFile看一下其实现

到此已经看到了下载压缩文件的全流程了。那么要利用，则只需要传递参数：/xxx/wcdownloadFiles?downloadInfo={files:['/WEB-INF/']} ,即可打包下载WEB-INF目录了。压缩web根目录会超时，无法完成下载，所以只能退而求其次，下载WEB-INF目录，但该有的代码还是可以看到的。

全部代码：

（5）上面没提到单一文件下载的downSimple，给大家看一下，没啥技术含量。

3.2 任意文件上传-

有了完整的代码以后，导入idea，进行分析，侧重能拿权限的接口。

找到对应代码进行分析如下：

（1）获取Web根目录，然后拼接路径

此时目录为[Web Real Path]/uploadfiles/[savePath用户传入]

（2）解析上传请求

（3）文件保存

最后返回给前端。

任意文件上传分析完成，然后进行测试，却....

至少应该是显示上传失败才对啊。到这，这个洞派暂时派不上用场，但在内网却起到了很大作用。

内网见到同样的CMS时，直接抄起poc就打，然后就成了。这台机器在我们后来的横向中起到了很关键的作用，因为密码是通用密码且能读到明文。

后来测试，该漏洞在互联网上也是影响很多资产。

3.3 任意文件上传2-webUploadServlet

找这个接口，主要是我在前台用过，且真实可以上传文件，但不返回文件名，而且上传什么上去都是.png，所以进行分析。

最开始没找他的代码的原因是因为class目录没这个类。

就很离谱，然后问了某大佬，说可能在依赖的jar包里面，于是在lib目录下找到了名称为项目名的jar包。果然找到了对应的代码，如下：

在解析POST请求时，定义不同的action用于处理不同内容。

首先先看下uploadFile的实现：

（1）处理上传请求，具体如下：

（2）拼接路径，完成上传，具体逻辑如下：

其实这里面有个坑点，判断chunks不为空，则取chunk作为最终文件名，这怕是少写了个字母，最开始我没注意这点，走了很多弯路。

（3）漏洞利用-1，只需要构造数据包，满足以上逻辑要求即可。

然后shell地址为：/uploadfiles/attach/chunk/test/tst.jsp,测试：

3.4 任意文件上传2+文件移动接口

上面提到说当时踩了chunks和chunk这个坑，当时是上传以后，死活也访问不到上传后的文件。

然后发现有个action分支为：checkChunk，涉及文件操作，它是这样实现的：

把用户传入的fileUuid拼接进了路径，和我们上面看到上传里面的(String)var10.get(var10.get("id"))的值对应上，到var6这里就是同一个目录，然后接着 http请求、fileUuid的值和chunks的值被传入了mergeFile函数，跟进一下看看实现。

所以，无论我们的storePath写什么内容，最后保存的文件名都可控，所以，这必然存在漏洞。

利用方法：

此时因为没chunks，所以传的文件访问不到。

是这么存的，所以需要用到另一个接口进行移动文件，测试如下：

然后访问shell：