对5.6w条xray结果的简单分析
2022-10-12 15:25:15 Author: RainSec(查看原文) 阅读量:32 收藏


前言

     自动化扫描src已经做一段时间了,各类问题累计扫出来7.3w+,其中xray作为扫描漏洞的主力之一,上报了5.6w+问题 。目前应该是全网使用xray漏洞记录最多的一个了吧。

     这里便根据这5.6w+扫描结果来对xray做一个简单的分析及复盘,先说下我目前使用方式:

扫描目标

  • • 各大国内src相关资产

扫描方式

  • • crawlgergo爬取网站请求并发送到xray

  • • xray扫描爬取的网站请求将结果发送给webhook

  • • webhook收集并报告漏洞

简单来说就是: crawlgergo---->xray---->webhook

开局套个盾

  • • 统计结果仅包含src的资产,一般有src厂商的网站安全性要比普通厂商的安全性要高出很多,不同src对应厂商的安全性也不相同,分析结果仅供娱乐,不代表某个具体公司,亦不代表整体情况。

  • • 随着扫描结果越来越多,后续根据我的扫描习惯关闭了一些误报过高和没有太大利用价值的插件,所以对于对于一些插件的统计结果是偏低的。

  • • 本次取的是xray直接的报告结果,其中包含了xray的误报。

正片

     本次统计漏洞总数为56666,这里将漏洞分为xray内置插件扫描和加载yaml插件扫描两类,其中

  • • 内置插件漏洞数量:54507

  • • yaml插件漏洞数量:2159

xray自带插件分析

xray自带插件可以分为10个大类

  • • dirscan

  • • baseline

  • • xss

  • • redirect

  • • brute-force

  • • sqldet

  • • jsonp

  • • path-traversal

  • • cmd-injection

  • • crlf-injection

     细分总计有60个小类(ps:实际不止60,这里取的是报告结果统计出来的分类),具体如下

对整体漏洞统计如下

dirscan和baseline远高于其他插件,下面具体说说各类漏洞的情况及使用体验

baseline

  • • baseline/cors/allow-https-downgrade/cors/allow-https-downgrade/cors/allow-https-downgrade

  • • baseline/cors/allow-null-with-credential

  • • baseline/cors/any-origin-with-credential

  • • baseline/cors/reflected

  • • baseline/sensitive/server-error

     其中server-error最多,达到20711条。baseline对自动化挖src来说,没有太多价值,为了减少干扰,后来直接在配置文件关掉这个大类检测,所以这块的实际统计是偏少的。

dirscan

     感觉xray花了大量精力来做这个插件,直接分了45个小类,漏洞种类它占了三分之一,由于分的太细,有些漏洞名字完全不知道干嘛的,这里根据具体的报告做了个简单的记录

导致dirscan数量偏高的主要是以下4个插件,总计22971个。

  • • dirscan/debug/readme

  • • dirscan/sourcemap/default

  • • dirscan/sensitive/crossdomain

  • • dirscan/directory/default

     第一个第三个价值不大。第二个是js.map泄漏,第四个是目录遍历,由于xray没做相关去重,一个网站有问题,那么连带着可能报上来几十甚至上百条报告。

     仔细梳理下来,dirscan细分了很多类,其实有些是相似的,可以合并到一起,分成两级其实更简洁明了。

     diarscan中实际可直接利用的并不多,可以把其中的一些高价值或命中高价值关键字的漏洞做一些醒目的提醒,减少干扰。比如目录遍历的文件可进一步读取。泄漏密码或者其他重要配置。

     部分插件可以做进一步扫描的,比如发现phpmyadmin和tomcat可以尝试爆破。

     git/svn插件误报有点多。

sqldet

sql注入检测插件

  • • sqldet/blind-based/default

  • • sqldet/error-based/default

  • • sqldet/time-based/default

     报错注入,bool盲注,时间盲注都有检测。实际使用中扫出来过报错注入,在本地扫描的时候扫出来过被我漏掉的时间盲注。但是bool盲注,时间盲注在这套自动化测试流程中全是误报,而且误报特别多,后来直接关闭这俩检测,只保留了报错注入。

xss

     基于语义化检测的检测逻辑,检测过程无明显流量特征,对于有防护的场景依然有很高的准确度。

     最开始的时候手工验证了很多报告,很多防御不严谨的都被识别出来了,基本上绕一下就能触发xss,算得上扫xss神器。

     可惜是国内的xss,还是反射型xss,有的还有条件限制。即时交了给的赏金还不够写报告的手工费。后来扫出来的越来越多,也懒得挨个看了,现在默认忽略xss漏洞。

redirect

     检测payload设计的挺巧妙的,payload自带绕过能力,精确度也挺高。可惜不值钱,也被我当做默认忽略的漏洞之一了。

brute-force

  • • brute-force/basic-auth/default

  • • brute-force/form-brute/default

     这个模块,基本都是误报= =.

     basic-auth报告3个全是误报,form-brute报告378条具体正确多少个忘记了,但不超过5个,这个插件怎么说呢,关掉吧,万一命中一个说不准就是个高危漏洞,不关吧,命中率实在感人,自己写一个吧,不经过大量测试写出来的命中率估计还不如这个呢。。

jsonp

     扫出来的结果并不多,且利用价值都不高。纯依靠插件来检测这类漏洞中高价值的还是有点难度的。

cmd-injection、crlf-injection、path-traversal

     这三个的报告很少,而且报上来的也是全是误报。

xray加载的yaml插件分析

在写这篇文章前的印象是除了两三个特别容易误报的插件外,其他插件相对较好的。然而在写这篇文章的时候重新整理了一下这些结果,发现这里面的误报真的多,很多插件直接全是误报。。。这里直接不展开分析了。

     简单说一下结果:

     yaml插件总计352个,有报告漏洞的插件共36个。

     将插件根据发现漏洞数量排序,原本想挑几个效果比较好的插件分析下的,结果发现好多插件插件误报率百分百,一直找到第20个才凑齐10个,直接放弃。(ps:这里说的是误报不是漏报,造成原因是目前扫描的目标里面没有这些漏洞。)

     这里放个排除掉误报比较高的插件后的前十插件占比。

yaml插件估计是官方在审核插件的时候只是审核插件是否会漏报,并没有进行大范围的测试。

后记

最后简单总结下在这段时间使用下来后对于xray的评价

先说优势

  •     • 在基础普通漏洞验证上做的相对完善。部分类型的漏洞验证方式及思路非常巧妙。

  •     • 支持额外加载yaml插件来补充其对1day漏洞的扫描能力

  •     • 有官方运营的社区,可不断补充1day插件

然后缺点

  •     • 编译型语言的导致的硬伤,不如脚本语言灵活。只能通过解析yaml文件来进行poc编写,但yaml在应对复杂场景的检测局限性很大。

  •     • 针对新的影响范围较广的漏洞等的补充只能等待官方更新,比如log4j到目前都没有支持。

  •     • 不支持被动扫描插件编写。

  •     • 用于大范围扫描时很多插件误报严重。

     在最初了解到基于流量的被动扫描时就感觉这是个很好的漏洞扫描思路,能做的事情应该远高于传统扫描器。xray作为最火的被动扫描,在长时间使用下来的体验是相比传统扫描器有一定特色,除具备传统扫描器功能外,也有一定的灵活性。但由于其不开源,开放出来的版本本质还是基于传统漏洞和僵硬的1day扫描,无法完成被动扫描插件的开发,没有将被动扫描真正的灵活性完全的体现出来。想要完全发挥被动扫描的能力仍然需要配合其他的被动扫描工具。


文章来源: http://mp.weixin.qq.com/s?__biz=Mzg3NzczOTA3OQ==&mid=2247485763&idx=1&sn=3fa458a20868d713f336e86509fe703d&chksm=cf1f246bf868ad7d15f4fc0b34c6e080e30d127f8f7da9097efee0fc6ac30fd2374677fb1d0f#rd
如有侵权请联系:admin#unsafe.sh