【攻防演练】某采购系统1day任意文件下载到RCE

admin 2022年8月4日10:40:41HW&HVV【攻防演练】某采购系统1day任意文件下载到RCE已关闭评论38 views2135字阅读7分7秒阅读模式

0x01 前言

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

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

前台看到有相关附件下载,如下:

-w870

点击下载功能,发现URL长这样:

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

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

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

-w374

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

偶然看到该接口可以批量下载,如下:

-w692

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

-w1304

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

-w680

尝试下载,发现:

-w805

开整,分析。

0x03 代码审计

3.1 任意文件下载

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

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

-w1100

(2)84-86行代码中,把json解析好以后,传入了downLoadFiles函数。

-w552

(3)跟进downLoadFiles函数的实现如下:

-w950

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

-w757

概括一下:

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

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

-w679

(4)跟进downZipFile看一下其实现

-w1182

-w1251

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

全部代码:

-w970

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

-w1040

3.2 任意文件上传-

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

-w942

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

(1)获取Web根目录,然后拼接路径

-w1275

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

(2)解析上传请求

-w843

(3)文件保存

-w1121

-w618

最后返回给前端。

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

-w1320

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

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

image.png

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

3.3 任意文件上传2-webUploadServlet

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

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

-w668

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

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

image.png

首先先看下uploadFile的实现:

(1)处理上传请求,具体如下:

-w1066

(2)拼接路径,完成上传,具体逻辑如下:

-w929

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

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

-w1289

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

-w1348

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

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

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

-w987

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

-w1116

-w693

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

利用方法:

-w1257

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

-w1305

-w1327

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

-w1361

然后访问shell:

image.png

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年8月4日10:40:41
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  【攻防演练】某采购系统1day任意文件下载到RCE http://cn-sec.com/archives/1220471.html