DAST 黑盒漏洞扫描器 第二篇:规则篇

0X01 前言

怎么衡量一个扫描器的好坏,扫描覆盖率高、扫描快、扫描过程安全
而最直接的效果就是扫描覆盖率高(扫的全)
怎么扫描全面,1 流量全面 2 规则漏报低
流量方面上篇已经讲过,这篇主要讲扫描规则。
扫描规则漏报率低,从整体考虑,一方面是规则全,广度上有保证;一方面是检测手段有深度,可以跨能力联动检测,有能力解决主要和旁枝末节处的漏报场景

0X02 规则来源

扫描器的规则主要有两种类型
针对接口的web漏洞,通常是通用型漏洞,OWASP TOP 10,sql注入、xss、ssrf、xxe等,以下简称web规则
针对主机(包括整个站点)的漏洞,通常是特定框架/应用/组件的0day/nday漏洞,以下简称主机规则。

2.1 主机规则

2.1.1 覆盖nday

针对nday,主要考虑的是企业内资产。
在资产方面获取到企业内所有IP与端口后,进行端口指纹识别(服务指纹识别/WEB应用指纹识别),根据每种指纹的数量排序,优先解决TOP100 / TOP 200 / TOP 500 的服务的历史高危漏洞。

2.1.2 覆盖新出的漏洞

针对0day漏洞,我们要解决的是新曝光的影响面较大的0day(很多情况下,新漏洞都是靠朋友圈/公众号,这部分是随人的,可能随着人员流动、发现的敏锐度会变化,所以尽量做成自动化运营流程)。
这里主要通过漏洞预警功能(或类似叫法)。
周期获取cve漏洞列表,匹配内网资产,再检测其他平台是否有对应cve编号。优先判断又有资产又有poc或exp的漏洞是否有影响,有较多资产代表影响范围较大,有poc或exp代表外部大概率已经有人在扫描与利用了。
然后再判断有资产的但没有poc与exp的是否影响范围较大,是否需要投入人力对漏洞进行研究(个人认为这是甲方的研究的一个需求,但是往往投入产出较低,所以需求较低)。

对应的功能是各家乙方的漏洞预警公告
阿里云漏洞库
腾讯云漏洞扫描服务情报中心

如果短期无法进行流程建设,定期由运营人员去看一下这些列表,判断资产匹配程度,有资产的漏洞编写成插件进行扫描,也可以有较好的收敛效果。

另外说一下资产指纹识别,理想情况下通过指纹识别打标,可以知道企业所有服务。但指纹识别有一个难点在于不知道有什么资产,就写不出对应的指纹规则。
所以需要有对应的打标流程,上文提过指纹打标,通过多特征组合成规则的形式,完成一个打标功能建设。
打标的需求源头,主要一方面就是漏洞预警,针对0day快速检测对应服务的资产数量,否则内网几十万的机器量级,每次都花费数小时全部扫描一遍来判断服务数量,影响漏洞响应时间(MTTR)。同时完善资产指纹,对资产较多的服务,历史漏洞也处理一遍。

2.2 web规则

2.2.2 覆盖场景全

web规则主要是针对通用型漏洞。
首先把场景保存下来,以靶场的形式,可以周期进行验证,验证每个漏洞类型是否每个场景都能检出。
靶场作为裁判员,安全产品作为运动员。

怎么能找出所有的web通用型漏洞呢?
a. 漏洞类型
寻找各种同类安全产品支持检测的扫描类型,从中排除掉危害较低的或者不存在于公司场景的
b. 每种类型的漏洞场景
常常有这样的情况,有检测sql注入、存储xss的插件,但是有些场景没有顾及到,比如header里的注入、post json中的注入等。
场景考虑齐全,需要针对每种漏洞抽取出维度,有一部分是公共维度,有一部分是私有维度,再进行维度相乘,得到最终各种场景。
举个例子:比如注入有哪些类型和场景?
维度可以是 不同来源/不同过滤与防御条件/不同执行方式/不同输出方式等,而这些是公共维度,类比到其他漏洞类型也可以按这样划分;私有维度比如数据库版本、数据库报错是否开启等(单独影响该漏洞场景)。
将每个维度的种种可能乘起来,得到各种场景,其中之一例如 来源于cookie+过滤了单引号+jdbc执行+无回显+mysql5.7。

2.2.2 覆盖新场景

主要是漏洞召回,来源如应急响应中心、等保测评、红蓝对抗等。
召回时排查全流程问题,流量有没有进入引擎、是否绑定了对应的检测规则、扫描过程的结果是什么、最后结果有没有入库等。如果是规则问题,需要新增靶场
召回会有一部分原因是固定的无法快速解决的,比如流量缺失(post/cookie等)、检测能力不足,召回一段时间后再重点推动解决导致漏报的大头问题。

2.3 准确率保障:靶场

另外说靶场,这里靶场是一个比较重要的安全产品

作为检测能力的裁判员,主要的作用是
a. 将各种漏洞场景持久化沉淀下来,随着召回不断进行,场景也会越来越多
随着人员流动,当初某个规则所用到的测试环境,可能会消失。交接人员对规则进行优化时,又需要重复测试环境搭建过程,成本较大。而把场景转换成web代码场景、或者docker file沉淀下来,极大减小了优化过程的成本。

b. 衡量各种漏洞检测安全产品的能力,给出准确率、漏报率等数据
规则的准确率,是提高且稳定漏洞产出的一个重要环节,在规则数达到几百上千的情况下,每个规则是否有效,往往是编写时候临时做了验证。
后期可能因为某些原因(比如造成了业务影响、导致引擎性能问题)下掉或者减少检出场景,而忘了加回来丢在记忆角落里。次数多了,整体场景检出率可能很低,只有内网渗透召回时才发现那么多漏报。所以准确率验证十分有必要

c. 测试安全防护代码的可用性、有效性
安全防护代码是否有效,能防护住所有认知里的场景,是否在压测情况下对业务性能没有过多影响,这是靶场的验证效果。

整体来说,辅助功能比较大,极大的保证了每个规则的准确率,但直接产出可能不是很明显,属于发展到较为成熟时的能力。

0X03 检测方式

3.1 跨能力联动检测

结合各种侧信道功能,增强扫描能力
比如最常见的dnslog,命令执行时在服务器上执行dns查询,dns请求经过dns服务器层层穿透到外网,再传回给扫描器;根据dns标识,判断具体的扫描任务触发了。dns的特点在于可穿透不通网但不禁dns的场景,但无法锁定触发IP(一般为dns服务器IP)。

再比如http log,curl/wget发起http请求,根据http请求中的标识判断漏洞,无法检测不出网的环境,但是可以锁定访问IP。部署在公网的http log,主要面对于存储型xss这类请求可能是在外网触发的。

针对命令执行类的,最好是用部署在内网的http log。dnslog偶尔会出现触发了、但是和流量关系不大的问题,比如路由器不定时触发、某业务收集镜像流量并做了异步流量处理的定时任务、某个测试收到请求后好奇请求了一次,会有溯源难的问题。http log刚好把内网IP锁定,且ssrf也得使用内网http log。

java agent 探针,获取执行层的函数与参数,像注入/任意文件读写(写crontab等命令执行来检测有危害)这种也可以检测出来。
或者是主机agent (HIDS) 监控主机特定文件内容来判断文件操作
或者是sql日志聚合汇总来判断sql注入

另外检测时避免造成业务影响,比如log4J的ldap链接不断开可能导致业务hang住。

3.2 单一漏洞检测能力深入

比如针对XSS,现有很多场景都是前后端分离。单纯的 requests.get获取页面内容再正则匹配已经有点古老的。
使用headless浏览器解析JS。
监听弹框事件,针对所有参数插入payload;或者作预处理,针对所有payload出现的位置构造特定的payload等。

3.3 丰富检测所需流量资源

3.3.1 登录态

大多数检测所需要的登录态,镜像流量方案,无法使用用户的cookie、header(业务自定义header可能带有用户登录凭证),所以得构造测试cookie。
在有所有业务统一接入passport的情况下(一个cookie或者token对所有业务生效),和passport申请接口更新cookie就好了。
有的业务接入passport会将passport认证映射到自己的用户体系,登录passport后根据获取到的token,在后端自己验证所属用户后、赋予业务自己的账号权限。这种情况最好能找到passport下游接入调用方,统一更新对应业务的登录凭证。
而业务比较复杂、存在多种认证场景的情况下,比较麻烦。不同的域名或者子域名,需要定期的更新cookie。
这种情况需要一套自动登录程序,填写账号密码,加上验证码自动填写,获取到cookie后到每个单位的验证地址去验证cookie有效性。通过不断召回运营,丰富登录态。

3.3.2 后缀

正常情况下,流量过滤的步骤会过滤掉 js/css/zip/jpg/png等静态资源后缀。
但是有部分漏洞需要这些后缀,得通过召回丰富待检测资源。
比如 xxx.jpg?height=100&width=100,可能后端会根据参数构造返回包,会有dos的风险。
有的js文件会泄露未授权的接口,WADL文件存在接口泄露等

召回过程,会遇到很多流量缺胳膊短腿、任务丢失、核心请求函数不支持、检测手段不足、检测ROI低所以放弃等情况,路漫漫

0X04 总结

通过覆盖现有的漏洞场景,建立未知场景运营流程,深入检测手法、检测资源,并使用靶场确保每个漏洞场景都可以有效检出,可以做到保证整体覆盖率。
且自研DAST在规则检测上更贴合企业自身业务,更细、更全、更快。

posted @ 2022-06-07 10:26  huim  阅读(119)  评论(0编辑  收藏  举报