前言

这周授权测试了某系统，凭借着一个任意文件读取的漏洞，不断深挖，一波三折，历时将近24小时，也和Tide安全的小伙伴不断讨论，最终拿下目标的webshell。过程简直不要太美、太狗血，在此做个整理。

基本信息

目标：wy.xxx.com.cn（子域名）

IP：114.xxx.xxx.xxx（阿里云）

web 四大件：

java、Apache Tomcat 7.0.61、mysql、linux

端口开放了太多，确定的是30126端口为ssh

子域名更多了，大多数均反查为该阿里云服务器。

弱口令

测试首先发现验证码无效，直接爆破。

这里分享了小技巧：

阿里云服务器在扫描目录或者爆破口令的时候，如果线程多高，IP会容易被封。可以再找一台阿里云服务器做代理进行测试。

放弃图片上传

选择权限比较高的用户登陆系统后，发现一处图片上传。

该处上传无任何校验，可以上传任何格式的文件。但都统一受到images.xxx.com.cn域名下，受nginx解析。

多次尝试无果后，遂放弃。

任意文件读取

在系统里闲逛一圈后，发现一处任意文件读取漏洞。

点击"下载模板文件"抓取数据包，可在数据包path参数看到系统路径。使用字典fuzz该参数。

查看返回包可收集到系统的许多信息。

1./etc/passwd

看到系统只有root、ftpimage这两个账户是可以登录的。

2./etc/shadow

看到shadow文件，说明当前权限是比较高的。

3./root/.bash_history

看到root用户执行的历史命令。确定当前为root权限。

且发现网站绝对路径的一部分/www/xxx-tomcat1/，马上想到翻看tomcat-users.xml文件，但并没有配置用tomcat manager。

还发现了logs目录的catanlina.out日志文件。

下载catanlina.out文件进行分析。

4.catanlina.out日志

该日志文件比较大，下载了多次都失败了，最终也是用自己阿里云服务器wget命令下载下来的，高达1.9g

war包

下载后，直接检索/www/xxx-tomcat1/，存在多个war包。

靠着任意文件读取下载了几个war包，部署到自己搭建的tomcat下进行查看。

基本上几个war包都大致差不多。猜测：系统使用war包部署到tomcat，一个war包对应一个域名。

ftpimage账号密码

在config.properties配置文件中发现了ftpimage账户密码，以及该war包所对应的域名。

比如run.war包。

一般配置文件都存放在/WEB-INF/classes/这个文件夹下。

记录着ftpimage账户的用户名密码

ip.imgservice这个属性也看得出，上传的图片都会在image.xx.com.cn这个域名下。

放弃axis2框架

有些war包里存在axis2框架

找到对应的域名访问axis2-web

如果可以上传arr木马就美滋滋了，但多次上传均404。

查找资料，发现axis2框架的正确结构是这个样子的。

猜测axis2框架应该无法使用，遂放弃。

放弃提权

之前获取到的ftpimage账号密码登录阿里云，发现权限特别低。只有www、var文件夹可读可写可执行的权限。但也能看到nginx、redis文件夹。

执行了几条提权命令也都不行，考虑到阿里云服务器，遂放弃。

33个域名

看到nginx文件夹，想到读取nginx.conf配置文件。

统计大概有33个域名，而且看到nginx统一设置了白名单，均image.xxx.com.cn这个域名解析。验证了之前的猜测。

结合catanlina.out日志和nginx.conf配置文件的域名，最终找到绝对路径和网站域名对应的关系。

/www/xxx-tomcat1/wy/ROOT/---------wy.xxx.com.cn
/www/xxx-tomcat1/care/ROOT/-------care.xxx.com.cn
/www/xxx-tomcat1/nd/ROOT/---------nd.xxx.com.cn
/www/xxx-tomcat1/elder/ROOT/------elder.xxx.com.cn
/www/xxx-tomcat1/wx2/xxxx.war/----wx2.xxx.com.cn

查看目标绝对路径/www/xxx-tomcat1/wy/ROOT/

/www/***-tomcat1/提示没有权限

但是/www/***-tomcat1/wy/ROOT/竟然有权限。

看到upload这个文件夹，比较好奇，ls发现全是xls文件。

xls上传

猜想一下：上传的xls表格文件存放在/www/xxxx-tomcat1/wy/ROOT/upload/这个文件夹下，和图片上传的那个位置不一样，存放在/www/upload/文件夹下。那么可以在目标系统里找对应的表格上传。

其实一些表格的上传、导入导出这种我很少测，认为会有格式校验

但转念一想，都测那么多了，不差这点了。

选择模板文件，抓取数据包上传。

返回包里还真有upload，但对应的temp目录下并没有a1a6d54010a34a58a9497fdc41ef42b2.xls这个文件。

空空如也，见鬼了！！！

做到这里想放弃了，实在是没有思路了。

没思路的我就只能一个文件一个文件的翻找，试图再发现点别的有价值的信息。然后我意外的在/www/xxxx-tomcat1/wy/ROOT/upload/images/文件夹下发现了大量的xls、jsp文件。

难道我上传的xls、jsp文件到这个目录下了？那也不对啊。

上传重命名后a1a6d54010a34a58a9497fdc41ef42b2.xls这个文件也不在啊。

于是我尝试又上传一个文件。

诡异的事情发生了！！！该目录下还真多了一个文件。

比较一下哪个是新增的文件，并尝试访问。

竟然真的可以。

直接上传冰蝎马。

然后系统就这样被拿下了，感觉最后这步太狗血了。多亏了Tide安全的小伙伴相互启发、相互激励。

我是Tide安全的CSeroad，对渗透测试、红蓝对抗方向感兴趣的小伙伴可以相互交流、相互学习。

总结

1、文件上传漏洞是最快一种获取webshell的方式。在图片上传、附件上传、头像上传都不行的情况下，试着看看模板上传、文件的导入、mp4的上传等等。最好任意一处上传也别放过。

2、不要忽视任意文件读取漏洞的危害，他可以为你收集系统、服务器的许多信息，比如系统的绝对路径、一些配置文件、备份文件的名称、有没有使用一些解析库（fastjson）等等。几个漏洞结合起来的效果也不错。

*本文原创作者：CSeroad，本文属于FreeBuf原创奖励计划，未经许可禁止转载