chicken
- 关注
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9

过年期间在家打算开始尝试挖SRC赚取一些零花钱,打开burpsuite真的是一点也不想动,开始思考如何自动化躺着捡洞挣钱,于是如下图的一个自动化SRC捡漏系统就诞生了。
一、信息收集
OneForAll已经是一款很成熟的信息收集产品,所以拿来开箱即用就好,OneforAll信息收集结果支持sqlite、csv等格式,那么我们需要配置一个想要挖掘SRC根域名的表。写一个python脚本定时获取配置表任务扔到OneForAll里面做信息收集,另一个脚本从sqlite里面取结果写入扫描任务表。做配置表的一个好处是你任何时候想挖新的SRC只需要添加几行配置信息就好。
有时候OneForAll信息收集也会有些遗漏,我喜欢去一些网络空间测绘平台根据公司名称批量导出资产,所以还需要一个批量录入的扫描任务的脚本。
二、扫描任务
扫描任务表以及上面说的SRC目标配置表都是mysql,扫描任务还是以web漏洞扫描为主,我们可以根据你想要的扫描器、目标、扫描周期等各种元素算一个唯一id值作为主键,从存活域名生成任务,那么后续每次信息收集只会有新的任务插入:
hashlib.md5((row[4]+'|'+'nuclei').encode('utf-8')).hexdigest()
OneForAll也会有真实IP的判断,我们可以抽取对应的真实ip去探测主机层面是否有脆弱性,为了快速扫描我选用了masscan+nmap,masscan先测试1-65535端口是否存活,根据存活的端口信息生产nmap扫描任务。nmap扫描任务生成各个SRC的资产指纹库,我们根据资产指纹库进一步生存扫描任务,例如协议为http、https的再生成web扫描任务,这样某一些ip绑定不同的web服务可以作为之前域名信息收集的补充,同样的其他服务如redis可以去探测是否存在未授权漏洞,其他服务是否存在弱口令(目前主机层面漏洞探测没有去做,感觉存在一些风险)。
三、扫描器节点
如开篇的架构图所示,虽然没有自动化的调度系统和消息队列(主要是穷买不起更好的云主机),但是目前的各个节点也是可以拆开的且支持分布式,漏洞扫描器主要采用了两个方案,一个是rad+xray通用漏洞挖掘比较厉害,另一个是nuclei其poc合集强大。扫描节点也是两个python脚本的定时任务,一个是从扫描任务表拉取未扫描的任务进行扫描,另一个是检查扫描任务是否完成,如果完成则解析扫描结果入到es。扫描器节点的关键就是并发的控制,我直接采用ps aux|grep nulei统计当前扫描任务的个数,如果任务数量小于并发控制数则继续下发扫描任务。而任务结果解析则是又用到了前文说的任务唯一id,拉取任务表在扫描中的任务查看本节点ps aux|grep id,如果id存在则扫描任务未结束,如果不存在则解析任务结果。扫描并发目前是写死在标本里,其实也可以另外做一个扫描器并发控制表去做并发的控制。
masscan、nmap扫描节点的部署与上述同样。
四、任务结果
选择elk做任务结果的存储和展示好处有两个,一个是不管接多少扫描器我不需要取考虑表结构一股脑的往里面滋就好,另一个是kibana展示效果良好且支持灵活的筛选,这样就不需要自己去写一个前后端了。如下分别是漏洞和资产指纹展示:
目前系统迭代修改大概两周多时间,结果基本上是sql注入、各种各样的未授权访问、信息泄漏为主,还是赚了几千块钱的嘻嘻,最舒服的状态莫过于泡杯茶玩玩手机,时不时上es上看看有没有有效漏洞可提交。但是现在这只能算是0.5版本的自动化,未来还有很多的功能需要去完善,例如动态代理池、自动化从SRC平台拉取目标、根据漏洞置信度和知识库自动化提交漏洞、关键漏洞与新增资产消息推送、更好的分布式架构、引入自动化编排系统等等。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)