Part1 前言
大家好,我是ABC_123,本期分享一个真实案例。大约在两年前,有机会接触到一台红队扫描器设备(也可以理解为渗透测试机器人),我抱着好奇的心态去那里做了一下测试,感觉还不错。里面大概有4000多个漏洞利用exp,当然大部分都是nday漏洞,有一些未公开的1day漏洞,也有一些可能是0day漏洞,其中部分漏洞利用exp做了各种变形用来绕过waf,这些还是引起了我的兴趣。也是研究了两天,用了一个巧妙办法,欺骗这个扫描器发包,我在后台将所有的漏洞利用payload抓取到,整理成标准格式,放到了自己写的工具里面。
注:为了规避风险,文章中给出的扫描器截图不是原图,都是我手工画出来的,不太美观,burpsuite的数据包也经过处理,所以大家在看文章时很多地方可能会对应不上,懂得思路即可。
Part2 技术研究过程
扫描器概述
首先,使用这台设备的账号登录web界面,直接可以看到一个漂亮的前端界面,“插件管理”界面上面的统计数字显示内置了4000多个漏洞测试payload。进一步点开界面,可以看到每个漏洞测试payload的漏洞标题和漏洞详情介绍。当然在主界面中,也可以把一个url列表导入进去,进行批量漏洞扫描及批量漏洞利用。
原图不方便贴出来,我画了一个效果图,供展示所用,大致如下所示:
漏洞插件id遍历问题
每个漏洞扫描插件的编号都是有规律逐步递增的,第1个漏洞插件id=1,第4000个漏洞插件对应着id=4000。每个漏洞插件都有单独的操作框,可以填入URL进行检测与利用,个别的可以进行getshell操作。于是马上找到了一个id遍历的问题,这样我可以使用burpsuite遍历每个插件的id,在请求数据包中填入测试url,就可以使这台扫描器依次对相应的URL发送漏洞测试payload,此时在测试网站服务器上安装一个抓包程序,就可以抓取所有HTTP请求数据包,也就获取了所有的漏洞payload。
搭建测试环境实操
接着在vps上安装了一个phpstudy,web目录放置了一个存在漏洞的php页面,后台安装了一个抓包工具,开始了初步的测试过程。结果发现远远没有那么简单,存在以下几个问题:
1 该扫描器对一个url不会直接发送漏洞利用payload,它首先会有一个判断过程。对于一些CMS漏洞,扫描器会首先提交一个漏洞exp的urlpath路径(如/inc/config.php.bak),如果该urlpath页面存在,响应码是200或403或500,那么扫描器接下来才会发送真正的漏洞利用payload。
2 对于一些cms的sql注入漏洞或者文件读取漏洞,那么扫描器会使用在后面加单引号的报错方法或者各种报错方法,查看当前页面是否包含sql注入漏洞的错误关键字MySQL error、Unclosed quotation、error '80040e14'、supplied argument is not a valid MySQL result等,以此决定是否进一步发送测试payload。
3 服务器上的抓包工具,抓到了上千个数据包,但是不知道每个数据包具体对应哪个漏洞名称,不知道http请求数据包具体是哪种Web系统的哪种漏洞,所以抓到的数据包没法使用。
4 其它问题,如phpstudy的问题、http返回头的问题等等,这里不一一列举了。
欺骗扫描器发送可用的exp
为了解决这个问题,ABC_123想到了一个办法,我用Springboot编写了一个java测试页面,无论该扫描器提交什么url路径,一概返回200或403或500响应码,然后在返回页面中,始终返回一些sql注入关键字MySQL error、Unclosed quotation、error '80040e14'、supplied argument is not a valid MySQL result等,欺骗扫描器在第一阶段的判断过程中,找到了这些错误关键字而误以为是存在漏洞的,从而在第2次发包中,发送真正的漏洞测试payload。
然后我在springboot中加入了日志记录代码,一旦有请求过来,那么把当前完整的http请求数据包输出到一个log文件中,后期再做处理。
解决数据包与漏洞名称对应问题
为了解决这个问题,大伤脑筋,后来想到了一个绝妙的方法。还记得前面的“插件管理”的id遍历问题吗?首先用burpsuite把每个id对应的名称给提取出来,这样就得到了id值与漏洞名称的对应关系列表。
然后使用burpsuite遍历id发送漏洞测试payload的时候,测试URL按照如下格式提交,id=后面的数字可以用burpsuite插入一个从1到5000的字典。经过反复测试,发现按照如下形式构造漏洞测试url效果比较好,扫描器识别到URL以/结尾,会误以为是目录,从而在目录后面加上一些urlpath进行cms漏洞尝试;扫描器以?判断时,会误以为4111__dict__/是参数值,从而进行SQL注入漏洞尝试。
http://xxx.com/?id=4111__dict__/,
http://xxx.com/?id=4115__dict__/,
字符串__dict__是为了后期进行文本处理的时候,方便我们切割文本和替换文本,然后还可以作为区分以GET形式提交的漏洞测试payload。
这样后台的springboot应用就能获取到id传来的值,编写java代码遇到id=1,程序首先查询id=1的漏洞名称是什么,假设漏洞名称是"XXXOA系统的SQL注入漏洞",那么输出的日志名称就是"1_XXXOA系统的SQL注入漏洞.txt",如果遇到id=3001,漏洞名称假设是"Weblogic系统的2019-2725(JDK1.8)漏洞",那么输出的日志名称就是"3001_Weblogic系统的2019-2725(JDK1.8)漏洞.txt"。
burpsuite设置好线程,很快遍历完成4000多个id,也就意味着扫描器对我们的测试页面发送了4000多个漏洞的payload,然后编写程序对生成的log文件进行处理,处理成我们想要的数据包格式,上述工作就完成了。
Part3 总结
1. 在本次测试过程中,扫描器的一个低危的id遍历漏洞成为了抓取所有漏洞利用payload的入口,所以一个漏洞低危还是高危,还是看它的利用场景,有些低危漏洞还是会造成很大安全风险,还是需要修复的。
2. 本篇文章没法将原有的实战情况复现,因为不能贴原图,所以只靠打字说不明白,但是关键步骤都写出来了,后续会继续分享其它抓取payload的思路。
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
还没有评论,来说两句吧...