转载

扫描POC的收纳之道

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

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

经过一年多的折腾和尝试,我把漏洞扫描这一块儿,里里外外摸了个透。虽然因为人力有限,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 扫描整体流程

    扫描POC的收纳之道

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

    • 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 级别漏洞的扫描,模块输入出如下代码示例:

    扫描POC的收纳之道

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

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

    扫描POC的收纳之道

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

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

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

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

    扫描POC的收纳之道

    这个模块和 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)。牛逼的越来越牛逼,吃瓜群众还是继续吃瓜...

    扫描POC的收纳之道

    原文  https://mp.weixin.qq.com/s/bN-etCS-5Ds1dm9O_Zjk-A
    正文到此结束
    Loading...