前言

这周授权测试了某系统,凭借着一个任意文件读取的漏洞,不断深挖,一波三折,历时将近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