前言
这周授权测试了某系统,凭借着一个任意文件读取的漏洞,不断深挖,一波三折,历时将近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原创奖励计划,未经许可禁止转载
来源:freebuf.com 2020-03-23 08:00:02 by: CSeroad
请登录后发表评论
注册