黑盒漏洞扫描（系列二）

前言

怎么衡量一个扫描器的好坏，扫描覆盖率高、扫描快、扫描过程安全？而最直接的效果就是扫描覆盖率高、扫的全，怎么扫描全面？

1 流量全面 2 规则漏报低。
扫描规则漏报率低，从整体考虑，一方面是规则全，广度上有保证；一方面是检测手段有深度，可以跨能力联动检测，有能力解决主要和旁枝末节处的漏报场景

规则来源

扫描器的规则主要有两种类型：

• 针对接口的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. 测试安全防护代码的可用性、有效性
安全防护代码是否有效，能防护住所有认知里的场景，是否在压测情况下对业务性能没有过多影响，这是靶场的验证效果。

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

检测方式

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文件存在接口泄露等

总结

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