在渗透过程中，我们针对特定的系统，在通过插件识别类型后，可以利用漏洞脚本进行fuzz，这里笔者给大家分享下漏洞POC验证系统的设计研发思路。

系统综述

在本系统设计之初，是采用的也是分布式平台设计架构，后来因为考虑和分布式资产扫描平台兼容接口，最后为了解耦合，完全改成了单机版。

首先我们可以看到，在这个地方我们没有单独设计web管理端，只能通过命令行去调度。

但是，在设计时预留了守护进程rest api，可以接受第三方平台发来的调度请求。

在插件模块调用方面，主模块有三个：

• 流行漏洞插件：主要用于复现常见手工测试用的手段，以及部分团队挖掘的内部漏洞。
• 口令漏洞插件：主要包含端口、中间件、应用的未授权和弱口令漏洞，包含弱口令字典。
• 第三方漏洞插件：主要用于接入网上的部分开源和泄露的插件，用于结果整合和性能调优。

在获取目标信息时，主要有下面几种的形式：

• api调度：第三方平台通过rpc传递目标信息，对本系统的api进行调度。
• 命令行调度：通过命令行参数传递目标信息，直接进行调度。
• 资产导入调度：通过接入接口的方式，对于第三方平台api给出的数据进行调度扫描。

本身在分布式资产扫描平台，是存在cms类别和应用类型信息的落库的。但是为了考虑内网的情况，还是单独提取了两个子模块出来：

• cms鉴别插件：主要针对目标进行cms类型的鉴别，如目标匹配到本地的指纹库，会给他打上标签，否则会接入互联网查询接口。
• 应用鉴别插件：主要针对cms类型进行补充，识别服务和应用的类型打上标签，作为第二梯队尝试。

当然，除了这些模块，还有部分次要的效果优化类插件，这里就不再多提了。

最后，我们简单讲讲扫描结果落库的问题。

这里采用的是log打印存储+数据库回传分布式资产扫描平台，而回传的选项是可以关闭的，这就保障了我们在苛刻环境中本系统的兼容性。

坑点总结

在对于内网系统，或者存在敏感防火墙的系统进行扫描时，我们可支持接入多类型的代理。

速率控制

在针对敏感的server进行探测时，第三方插件可能自带的口令认证爆破机制，会比较粗暴。

要么就是单线程转，要么就是起个粗放的线程池，容易把服务器给跑挂了，或者让人IDS给很快查到。

所以针对这块儿的控制，我们需要做细致优化，采用动态控制速率的策略，而不光是硬编码配置下发任务。

数据统一

对于第三方插件，我们花了不少功夫在统一调度机制和库文件上，还有一点比较关键的点，是针对落库的格式上。

我们在各类插件的上报流程中，对于第三方的插件，会尽量进行数据上报层hook，统一格式后进行上报。

但并不是每一类插件都有统一落库记录的流程的，对于这类插件可能需要做函数重写。

探测尺度

我们的插件目前都是点到为止，为了遵守法律法规层面的制度，都没有进行漏洞深度利用，需要后续人工进行利用和复核。

未来企划

• 后渗透利用：目前是没有关于内网利用信息收集的插件的，后面进行后相关poc的开发。
• 云环境利用：对于云环境漏洞目前没有poc，后面会考虑添加。
• 安全设备利用：对于目前流行的对于安全设备的反攻，后面会考虑专门添加插件。
• WAF、蜜罐探测：对于WAF类和蜜罐环境，以前只是封装了辅助类的函数，后面也会提供专门的插件进行探测。