# 整体框架

# 0x01 想法

每当有新漏洞细节披露后,对于安全领域的工作者来说,通常会经过这样的一个的漏洞应急生命周期

漏洞复现 ---->原理分析 ----> poc 编写 ----> 靶机验证 ----> 大规模目标扫描

poc 完成后,通常有多种使用场景,或是快速刷洞(时间就是money),或是赋能到公司商业化产品(工作价值)。因此要有一套标准化的 poc 框架,否则会浪费很多时间研究同一个 poc 的N种语言实现。

基于以上分析,我认为一款优秀的漏洞验证框架应该具备以下基础功能:

  1. 跨平台
  2. 可视化
  3. 支持高并发
  4. 资源(cpu / 内存)占用小
  5. 对于框架 poc 维护来说,应该具备:
    • poc 格式标准化,具备统一的 poc 定义规范和解析 SDK
    • 不应该限制只能使用某种特定语言编写
    • poc 构建过程尽可能简单,能不写代码就不写代码
    • poc 易读,最好能可视化。

在经过对多种流行的 poc 框架对比后发现,需要编写 python 脚本来维护 poc 的框架通常摆脱不了 python 自身的性能问题,而且不方便规则可视化,维护困难。长亭的 xray 以及 ywolf 师傅的 kunpeng,使用 yaml / json 定义 poc 是个不错的选择。经过对比发现 xray 的poc 体系更为完善,更能经得起时间的推敲,但无奈 xray 并不开源,即使维护 poc ,也无法给 poc 调用方提供 SDK。

TIP

因此,我决定自己实现一个poc框架。主要实现 poc管理、poc 编辑、编写过程中的靶机验证、大规模目标批量检测等等都通过前端配置就能搞定,希望帮助安全研究员们集中精力专注于 poc 的原理分析和逻辑实现,避免浪费大量时间在编写代码上。

# 0x02 框架

image-20210606161157522

TIP

两个核心功能:

  1. poc可视化编辑和测试
  2. 大规模目标批量检测

细分为:

# 2-1 poc 运行

  • poc 规则体系
  • poc运行

TIP

poc 运行是 pocassist 框架的核心。根据 poc 规则对原始请求变形,然后获取变形后的响应,再检查响应是否匹配规则中定义的表达式

rule-detail

rule-run

# 2-2 poc 管理

  • poc 规则的可视化编辑:增、删、改、查、搜索、详情展示
  • 配置靶机对当前编辑的 poc 规则进行验证(无需保存)
  • poc 配套的漏洞描述 和 相关组件

rule-index

# 2-3 并发引擎

大规模目标扫描检测的核心。

  • 自定义条件加载 poc
  • 扫描任务调度
  • 并发控制
  • 速率控制
  • 多种检测目标类型:单个url 、请求报文、url列表
  • 资源控制:避免无节制的占用主机资源(内存/cpu/带宽)
  • 日志:记录检测过程中所有里程碑日志、错误日志、网络请求、响应,方便回溯

# 2-4 任务管理

  • 任务列表:任务状态、任务下发时间、任务完成时间

  • 扫描结果展示

task-index

task-new

result-detail