记一次从任意文件下载到getshell

文章首发在：奇安信攻防社区

https://forum.butian.net/share/4031

从下载慢慢探索，总归还是有一点乐趣。

下载接口的获取

地市攻防起手，这样的一个页面，看着就比较没那么的新，然后验证码之类的全无，是很有机会进行尝试的点，很多时候也是靠这点直觉进行的测试

用URLfinder跑了一遍获取后台的接口

我个人其实非常喜欢关注响应内容较小或者响应500报错的接口，前者大概率会有些信息，而后者大概率可以根据报错反推请求

这里其实很明显，请求路径大概率可以进行自定义，是一个很经典的任意文件下载的潜在漏洞点，这里也是经过尝试，先看到报错，这里可以看到直接把全路径暴露出来，报错是没找到文件

那么简单的../../etc/passwd，这里目标有waf，但是尝试后确定了https他们应该没弄，就完全无感。

下载目标的源码

那么到这里其实就可以尝试进行文件的读取，这个显然是linux，那么直接读历史命令记录看看是否存在打包的源码或者信息，来支撑我们进一步的利用

从这些命令记录我们可以得到非常多有用的信息，比如web应用的启动路径，比如一些日志路径情况，但是这里我们只能够明确的知道lib.zip中是应用的依赖，以及web应用配置的目录情况看大概率可能是一个jar包，那么就有一个新的问题，这个jar叫什么名字，因为大多数启动的jar应用一般不会跟依赖放在一起，依赖中可能存在很多分开开发的业务代码，虽然也能看到一些信息，但是核心jar的缺失会让审计的工作不好进行。

这里我通过尝试/proc/self/cmdline以及map去读这个jar的启动信息，但是返回均为空

这里这条路不通，那就换条路，根据上面那个重启的restart.sh

没毛病，停了再启动，很ok，接着看start

让AI看吧

牛，那么直接把lib.zip下载解压一下就行，这里我是直接把这些jar扔到我自己搭建的测试环境里面，让这些jar成我自己项目的依赖，经典一个jar 启动，剩余的路由之类的可能都在依赖里面。

插曲-burp插件检测到权限绕过

这里顺手看了眼burp插件的告警，看到了这个，可能有权限绕过，这里还有一个小伏笔。

整体源码下载后进行审计

这里目标其实很简单，jar项目那就找可以各类组件的漏洞、可能存在的反序列化以及可以完全控制的上传。

整体扔到jadx里面，在jadx里面搜上传的关键字，很可惜，大多数基本上都是这种路径不可控或者文件整体重命名的上传，意义不大，相关的版本如fastjson之类的也是1.2.83，只有个mysql可能在能打的范围内。

这里也尝试了审之前那个下载的地方，这里很有趣，根据代码看像是这个接口上传和下载都是走的9002端口，就是在9002端口有一个服务进行文件操作

这里又回去看了一下burp的包以及nginx的配置文件，确认事实就是如此

JDBC

这里后面就开始听歌摆烂了，随手翻翻@RequestMapping，终于看到几个名字不对劲的了

看到这个其实就有点想法了，顺手看了一下应用
打开就能非常明显的看到这几个路由，可以创建和验证数据库连接

跟一下发现验证的接口应该是存在jdbc路径可控，这里是直接传入ReportDatasource

但是这里是根据DBTypeEnum来确定dirverclass

看一眼DBTypeEnum是只有6种可选，其中存在mysql

这里又回头看了下jdbc的依赖，也符合要求

但是这里还有个小问题，这里的参数可控，但是jdbcurl是已经写好的。


也就是db后面的内容是死的，这里打jdbc需要传入dbname为

midpl?&autoDeserialize=true&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor

但是这里后面还有问号

?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

最终jdbcurl可能就是

jdbc:mysql://${ip}:${port}/${db}?&autoDeserialize=true&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

所以这里还需要进行一下处理，传入参数为

autoDeserialize=true&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor#

说实话这个是我随手试了一下试出来的，没怎么搞懂是为啥。

那么根据参数进行构造，报错了。

这里回到之前的actuator，这里的接口可能是转发了ngnix，和之前的疑似权限绕过是不同的。这里其实还有httptrace及heapdump端点，下载heapdump端点里面看到了token。

再次尝试，这里看着是一下，其实是很多下，试探了一下是不出网（诸葛亮五丈原流泪.jpg）。

但是漏洞总是要验证的，网上搜了下特征，还是有的，找到个出网的。
用webchain一把梭(https://github.com/Java-Chains/web-chains)

花了点时间找到了文件服务这个端口的源码，但是可惜的是上传接口好像存在问题

说实话手艺不精，看不出来上传哪里存在问题，非常标准的拼接和cpfile

本地环境搭建起来尝试了是没问题的，但是目标还是存在问题，实在是难搞，上传直接报错，尝试下载也没反应。

所幸看到了低版本的fastjson，可能是因为这个本身业务量很少就没升级，之前jdbc的包里面的fastjson是已经升级的版本


这里也通过目标下载接口确认了，确实是有低版本。

代码里面也刚好有个接口调用了fastjson的paseObject


这里找大哥要了一下不出网的payload，终于还是成功了，也算是了了一桩心事。

结语

猛猛推荐web-chains，脚本小子之光！！！用了这个妈妈再也不用担心我打反序列化了！！https://github.com/Java-Chains/web-chains