文章深入探讨了漏洞扫描器的整体架构和模块设计，将漏洞分为url参数级、url级、web_domain级和service_domain级，并详细介绍了每种级别的扫描流程和模块功能。文章强调了Payload配置文件化和扫描数据统计的重要性，并分析了不同类型漏洞在扫描器中的定位和实现方式。

🔍 文章将漏洞分为url参数级、url级、web_domain级和service_domain级，根据检测原理和Payload插入位置进行分类，为扫描器设计提供了清晰的框架。

📈 每个级别的漏洞扫描都有对应的模块设计，例如service_bat模块负责service_domain级漏洞扫描，web_domain_bat模块负责web_domain级漏洞扫描，url_bat模块负责url参数级和url级漏洞扫描。这些模块的设计使得扫描器能够高效地识别和定位不同类型的漏洞。

💾 文章强调了Payload配置文件化的重要性，通过将Payload配置文件化，可以大幅减少维护成千上万Payload文件的成本，并提高扫描器的可维护性和可扩展性。

📊 文章还强调了扫描数据统计的重要性，通过统计Payload的命中次数/扫描次数等数据，可以对后续Payload的优化调整有很高的指导意义，并提高扫描器的效率和准确性。

🔧 文章最后指出，扫描器讲架构讲设计都是耍流氓，POC数量多的、质量高的才是大爷，并推荐了YSRC开源的巡风作为小型安全团队内部漏洞应急排查的工具。

原创 吃瓜群众-Fr1day 2018-05-07 20:04

确认过眼神，你就得在这里

还在上大学的时候，觉得做安全工具给别人用的人最牛逼，一心想做扫描器，就走上了安全开发的不归路（🙄翻个白眼，并给自己点一首凉凉）。

在我云实习的时候，有幸参与到一个相对完善、高创新性和高效率的扫描系统的组件开发。时间较短、接触的东西也有限，但仍然对扫描器的整体架构有了一定的了解。后来由于不可抗力，最终还是加入了现在的公司。

经过一年多的折腾和尝试，我把漏洞扫描这一块儿，里里外外摸了个透。虽然因为人力有限，POC量和更新速度远远比不上当年实习时接触到的扫描器，产(K)出(P)也(I)不符合我的预期，但整体的框架设计仍然是值得参考的。

0x00 漏洞分类

根据检测原理（或者说：扫描 Payload 的插入位置），我将漏洞分为如下几类：

url参数级

依赖于爬虫，需要在每个参数值/参数名的位置插入 Payload 进行 Fuzz，同一 Payload 被多次调用。比如 XSS、SQL注入、文件包含、命令执行等

url级

同样依赖于爬虫，但无需遍历参数，每个 URL 只调用一次相关 Payload。比如：S2-045（指定HTTP Header）、PHP CGI命令执行（指定QueryString）、部分XXE（指定POST内容）等

web_domain级

依赖于端口扫描、web服务识别，每个web站点只调用一次相关 Payload。比如：docker remote API未授权、子域名劫持、TOMCAT RCE（CVE-2017-12615）、discuz SSRF、git信息泄露、敏感文件下载等

service_domain级

依赖于端口扫描、服务识别，每个非HTTP服务只调用一次。比如：rsync未授权、mysql弱口令、redis未授权等

注：参数名处存在漏洞的可能性比较低，可以根据扫描等级来确定是否 Fuzz

0x01 扫描整体流程

整体逻辑大体如上图，但实际操作的时候为了减少漏报，会做一些特殊处理，比如：

service_bat 会 Fuzz 部分默认端口，即使端口扫描部分没有扫到对应的端口开放（比如 redis、ssh）

爬虫会输出网站的 PATH 给 web_domain_bat，方便非常见路径的文件fuzz（比如： http://example.com/nicaibudaozhegelujing/.git/config）

注： bat 取自 windows bat文件（批处理）。

0x02 模块设计

接下来会大致介绍一下各个模块的设计。各个模块的漏洞输出均为同一格式（Json）：

[{"target": "127.0.0.1","port": 22,"service": "ssh","bug_type": "ssh_weak_pass","description": "name: 111, password: 111"
}]

service_bat，对应的是 service_domain 级别漏洞的扫描，模块输入出如下代码示例：

未指定 端口 及 对应的服务 的时候，程序会 Fuzz 所有 Payload（默认端口，比如ssh弱口令对应22端口）。

web_domain_bat，对应的漏洞类型是web_domain级。模块输入如下代码示例：

这个模块涉及的 Payload 比较多，原本可以分成好几个模块，比如 弱点文件Fuzz、web通用程序漏洞Fuzz。

但从 Payload 的特性来看，都是基于单次/少量web请求，判断返回值或者返回内容是否包含指定字符串，就可以确认这个站点是否存在漏洞。

提取这些关键特征，可以将大部分的 Payload 都配置文件化，以网页的形式去管理，即可大幅减少维护成千上万 Payload 文件的成本。通过统计 Payload 的命中次数/扫描次数等数据，也对后续 Payload 的优化调整有很高的指导意义（比如：智能模式下，只扫描命中率较高的 Payload）。

url_bat，对应了 url参数级别 和 url级别 的漏洞扫描。模块输入如下代码示例：

这个模块和 web_domain_bat 模块一样，可以将 Payload 配置文件化。业界比较好的开源软件，也可以引入，比如：sqlmap（SQL注入）、tplmap（SSTI模板注入）等。

这个模块还包含了很多的通用漏洞，绕过WAF的能力也很重要。比如：

初级Payload: http://test.com/command.php?exe=cat /etc/passwd
高级Payload: http://test.com/command.php?exe=c?t /e??/p??s?d

0x03 总结

如上分析，就已经是一个比较全面的扫描模式设计了，可以给每个即将到来的漏洞POC找到自己的位置。再举几个栗子：

永恒之蓝（010）： 归属于 service_bat 模块，smb 服务。

Struts2命令执行（S2-053）：归属于 url_bat 模块，param级别扫描

docker remote API未授权：归属于 domain_bat 模块，不限定指纹

Tomcat RCE（CVE-2017-12615）：归属于 domain_bat 模块，限定 Tomcat 指纹

最后泼一万吨液氨水，扫描器讲架构讲设计都是耍流氓，POC数量多的、质量高的（0day，误报率低）才是大爷。

而小型安全团队，做内部的漏洞应急排查，YSRC开源的巡风就完全够用了（没有 爬虫 和 url_bat 模块）。

在当前国内漏洞报告普遍封闭的大背景下，想打磨大而全的强力扫描器，要么需要大量源码审计人员从修复代码中“逆向”出漏洞，要么依托于已有的漏（money）洞（money）平（money）台（money）。牛逼的越来越牛逼，吃瓜群众还是继续吃瓜...

阅读原文

跳转微信打开