巧妙方法抓取某商用红队扫描器的4000多个漏洞利用exp

adopi

第78篇：巧妙方法抓取某商用红队扫描器的4000多个漏洞利用exp
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的思路。