漏洞POC验证系统实践

在渗透过程中,我们针对特定的系统,在通过插件识别类型后,可以利用漏洞脚本进行fuzz。

漏洞POC验证系统全景图

系统综述

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

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

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

在插件模块调用方面,主模块有三个:

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

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

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

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

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

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

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

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

坑点总结

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

速率控制

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

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

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

数据统一

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

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

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

探测尺度

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

未来企划

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