前言
这周授权测试了某系统，凭借着一个任意文件读取的漏洞，不断深挖，一波三折，历时将近24小时，最终拿下目标的webshell。过程简直不要太美、太狗血，在此做个整理。
基本信息
目标：wy.xxx.com.cn（子域名）
IP：114.xxx.xxx.xxx（阿里云）
web 四大件：
java、Apache Tomcat 7.0.61、mysql、linux
端口开放了太多，确定的是30126端口为ssh
子域名更多了，大多数均反查为该阿里云服务器。
弱口令
测试首先发现验证码无效，直接爆破。
image.png
这里分享了小技巧：
阿里云服务器在扫描目录或者爆破口令的时候，如果线程多高，IP会容易被封。可以再找一台阿里云服务器做代理进行测试。
放弃图片上传
选择权限比较高的用户登陆系统后，发现一处图片上传。
image.png
该处上传无任何校验，可以上传任何格式的文件。但都统一受到images.xxx.com.cn域名下，受nginx解析。
image.png
多次尝试无果后，遂放弃。
任意文件读取
在系统里闲逛一圈后，发现一处任意文件读取漏洞。
image.png
点击"下载模板文件"抓取数据包，可在数据包path参数看到系统路径。
使用字典fuzz该参数。
image.png
查看返回包可收集到系统的许多信息。
1./etc/passwd
image.png
看到系统只有root、ftpimage这两个账户是可以登录的。
2./etc/shadow
image.png
看到shadow文件，说明当前权限是比较高的。
3./root/.bash_history
image.png
看到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包。
image.png
image.png
image.png
靠着任意文件读取下载了几个war包，部署到自己搭建的tomcat下进行查看。
image.png
基本上几个war包都大致差不多。
猜测：系统使用war包部署到tomcat，一个war包对应一个域名。
ftpimage账号密码
在config.properties配置文件中发现了ftpimage账户密码，以及该war包所对应的域名。
比如run.war包。
image.png
一般配置文件都存放在/WEB-INF/classes/这个文件夹下。
image.png
记录着ftpimage账户的用户名密码
image.png
ip.imgservice这个属性也看得出，上传的图片都会在image.xx.com.cn这个域名下。
放弃axis2框架
有些war包里存在axis2框架
image.png
找到对应的域名访问axis2-web
image.png
如果可以上传arr木马就美滋滋了，但多次上传均404。
查找资料，发现axis2框架的正确结构是这个样子的。
image.png
猜测axis2框架应该无法使用，遂放弃。
放弃提权
之前获取到的ftpimage账号密码登录阿里云，发现权限特别低。只有www、var文件夹可读可写可执行的权限。但也能看到nginx、redis文件夹。
image.png
执行了几条提权命令也都不行，考虑到阿里云服务器，遂放弃。
33个域名
看到nginx文件夹，想到读取nginx.conf配置文件。
image.png
统计大概有33个域名，而且看到nginx统一设置了白名单，均image.xxx.com.cn这个域名解析。验证了之前的猜测。
image.png
结合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/
image.png
/www/xxx-tomcat1/提示没有权限
但是/www/xxx-tomcat1/wy/ROOT/竟然有权限。
看到upload这个文件夹，比较好奇，ls发现全是xls文件。
image.png
xls上传
猜想一下：上传的xls表格文件存放在/www/xxxx-tomcat1/wy/ROOT/upload/这个文件夹下，和图片上传的那个位置不一样，存放在/www/upload/文件夹下。那么可以在目标系统里找对应的表格上传。
其实一些表格的上传、导入导出这种我很少测，认为会有格式校验
但转念一想，都测那么多了，不差这点了。
image.png
选择模板文件，抓取数据包上传。
image.png
返回包里还真有upload，但对应的temp目录下并没有a1a6d54010a34a58a9497fdc41ef42b2.xls这个文件。
image.png
空空如也，见鬼了！！！
做到这里想放弃了，实在是没有思路了。
没思路的我就只能一个文件一个文件的翻找，试图再发现点别的有价值的信息。
然后我意外的在/www/xxxx-tomcat1/wy/ROOT/upload/images/文件夹下发现了大量的xls、jsp文件。
image.png
难道我上传的xls、jsp文件到这个目录下了？那也不对啊。
上传重命名后a1a6d54010a34a58a9497fdc41ef42b2.xls这个文件也不在啊。
于是我尝试又上传一个文件。
images
诡异的事情发生了！！！该目录下还真多了一个文件。
image.png
比较一下哪个是新增的文件，并尝试访问。
image.png
竟然真的可以。
直接上传冰蝎马。
image.png
image.png
然后系统就这样被拿下了，感觉最后这步太狗血了。
总结
1、文件上传漏洞是最快一种获取webshell的方式。在图片上传、附件上传、头像上传都不行的情况下，试着看看模板上传、文件的导入、mp4的上传等等。最好任意一处上传也别放过。
2、不要忽视任意文件读取漏洞的危害，他可以为你收集系统、服务器的许多信息，比如系统的绝对路径、一些配置文件、备份文件的名称、有没有使用一些解析库（fastjson）等等。几个漏洞结合起来的效果也不错。
网友评论