splintersfury/AutoPiff

GitHub: splintersfury/AutoPiff

一个基于语义规则的 Windows 内核驱动补丁分析引擎,自动检测漏洞修复并追溯可达性,帮助研究者在海量驱动更新中快速定位静默安全补丁。

Stars: 55 | Forks: 2

# AutoPiff **自动化补丁智能与发现框架** 一个用于检测 Windows 内核驱动程序补丁中漏洞修复的语义分析引擎。AutoPiff 使用保守的 YAML 规则来识别具有高精度和可解释性的安全相关代码变更。 ## 概述 AutoPiff 分析易受攻击和已修补的驱动程序版本之间的差异,以自动检测: - **释放后使用 修复**(`ExFreePool` 后的空指针赋值) - **边界检查添加**(`memcpy` 前的长度验证) - **用户/内核边界加固**(`ProbeForRead`/`ProbeForWrite`) - **整数溢出保护**(安全数学辅助函数) - **状态加固**(互锁引用计数) - **IOCTL 输入验证**、**池破坏保护**、**权限检查**等 ### 关键特性 - **高精度**:保守规则最大限度减少误报 - **可解释性**:每项发现都包含理由和证据 - **汇聚点感知**:规则考虑与危险 API 的接近程度 - **评分模型**:根据可利用性和可达性对发现进行排名 - **Karton 集成**:作为分布式服务运行于恶意软件分析管道中 ## 为什么选择 AutoPiff? ### 大海捞针 ``` Vendor releases 500 driver updates/year ├── 490 are feature/performance/cosmetic changes ├── 8 are minor bug fixes └── 2 are silent security fixes (no CVE assigned) Without automation: Manually review 500 to find 2 With AutoPiff: Review 10 high-scorers to find 2 ``` 安全补丁通常在没有分配 CVE 的情况下发布。手动逆向工程每个驱动程序更新以查找与安全相关的更新是不可行的。AutoPiff 通过自动显示重要的变更来解决此问题。 ### AutoPiff 自动化了什么 | 阶段 | 手动工作量 | 使用 AutoPiff | 节省时间 | |-------|---------------|---------------|------------| | 版本配对 | 5-15 分钟/驱动程序 | 自动 | ~100% | | 反编译 | 2-10 分钟/二进制文件 | 批量、并行 | ~95% | | 函数匹配 | 30-60 分钟/对 | 即时 | ~100% | | 识别安全变更 | 2-8 小时/对 | 秒级 | ~99% | | 初步分类与排序 | 1-2 小时 | 即时 | ~100% | | 报告生成 | 30-60 分钟 | 即时 | ~100% | **总计:每个驱动程序对从 4-12 小时缩减至 2-5 分钟** ### 什么仍然需要人类专业知识 ``` ┌─────────────────────────────────────────────────────────────────┐ │ AUTOMATED by AutoPiff │ │ ├── Find the needle: "This function changed near ExFreePool" │ │ ├── Classify: "Looks like a use-after-free fix" │ │ └── Rank: "Score 5.5 - worth investigating" │ ├─────────────────────────────────────────────────────────────────┤ │ STILL MANUAL (Your expertise) │ │ ├── Confirm exploitability: "Can I actually trigger this?" │ │ ├── Root cause analysis: "Why was this vulnerable?" │ │ ├── Exploit development: "How do I reach this sink?" │ │ └── Impact assessment: "What's the real-world risk?" │ └─────────────────────────────────────────────────────────────────┘ ``` AutoPiff 并不能取代漏洞利用研究。它通过自动化侦察阶段,使其**在规模上变得可行**。 ### 用例 **1. 静默补丁检测** - 监控驱动程序是否有未发布 CVE 的安全修复 - 当出现高分的语义差异时获取警报 - 在漏洞公开披露之前发现它们 **2. 1-Day 漏洞研究** - 当宣布 CVE 时,快速识别确切的补丁 - 将补丁模式与漏洞类别相关联 - 加速漏洞利用开发时间表 **3. 供应商安全审计** - 随时间分析驱动程序系列的所有版本 - 生成显示修复出现时间的 timelines - 识别供应商解决漏洞的模式 **4. 历史 CVE 语料库构建** - 处理已知的 CVE 驱动程序对以构建训练数据 - 验证并改进检测规则 - 创建补丁签名知识库 ## 架构 AutoPiff 作为一个 Karton 管道运行,包含 8 个顺序阶段以及一个并行的 DriverAtlas 分类分支。每个阶段都是一个独立的微服务,通过 Redis/RabbitMQ 进行通信。 ``` graph LR sources["WinBIndex
VirusTotal"]:::src --> s0["Stage 0
Monitor"] s0 --> s14["Stages 1-4
Patch Differ"] s0 --> triage["DriverAtlas
Triage"]:::triage s14 --> s5["Stage 5
Reachability"] s5 --> s6["Stage 6
Ranking"] s6 --> s7["Stage 7
Report"] s6 --> s8["Stage 8
Alerter"] triage --> alerts["MWDB Tags
+ Alerts"]:::triage classDef src fill:#1a1a2e,stroke:#e94560,color:#eee classDef triage fill:#1a1a2e,stroke:#e9a345,color:#eee classDef default fill:#16213e,stroke:#0f3460,color:#eee ``` | 阶段 | 服务 | 功能 | |-------|---------|-------------| | 0 | [`driver-monitor`](services/driver-monitor/) | 轮询 WinBIndex 和 VirusTotal 以获取新驱动程序版本,上传至 MWDB | | 1-4 | [`karton-patch-differ`](services/karton-patch-differ/) | 版本配对、Ghidra 反编译、函数匹配、语义规则评估 | | 5 | [`karton-reachability`](services/karton-reachability/) | 从 IOCTL/IRP 入口点到变更函数的 Ghidra 调用图 BFS,完整反编译导出 | | 6 | [`karton-ranking`](services/karton-ranking/) | 使用可达性、语义严重性和攻击面对发现进行评分 | | 7 | [`karton-report`](services/karton-report/) | 生成结构化 markdown 报告,上传至 MWDB | | 8 | [`autopiff-alerter`](services/autopiff-alerter/) | 为评分 >= 8.0 的发现发送 Telegram 警报 | | — | [`autopiff-driver-triage`](services/karton-driver-triage/) | DriverAtlas 攻击面评分(与 1-4 并行),标记 MWDB 样本,Telegram 警报 | ## 语义规则 AutoPiff 包含 22 个类别共 58 条规则。有关完整规范,请参阅 [`Docs/semantic_rules.md`](Docs/semantic_rules.md);有关技术参考,请参阅 [`Docs/SEMANTIC_RULES_REFERENCE.md`](Docs/SEMANTIC_RULES_REFERENCE.md)。 | 类别 | 检测示例 | |----------|-------------------| | `bounds_check` | 在 memcpy 前添加长度检查 | | `lifetime_fix` | ExFreePool 后的空指针赋值 | | `user_boundary_check` | 添加 ProbeForRead/ProbeForWrite | | `int_overflow` | 安全数学辅助函数使用 | | `state_hardening` | 互锁引用计数操作 | | `ioctl_input_validation` | 分发处理程序中的新大小/类型检查 | | `pool_type_hardening` | 迁移到 NonPagedPoolNx | | `privilege_check` | 添加 SeSinglePrivilegeCheck | ### 汇聚点组 规则引擎跟踪 8 个汇聚点组中的 50 多个危险 API 符号: - `memory_copy`: RtlCopyMemory, memcpy, memmove - `pool_alloc`: ExAllocatePool, ExAllocatePoolWithTag - `pool_free`: ExFreePool, ExFreePoolWithTag - `user_probe`: ProbeForRead, ProbeForWrite - `io_sanitization`: RtlULongAdd, RtlSizeTMult - `exceptions`: __try, __except - `string_copy`: strcpy, wcsncpy - `refcounting`: InterlockedIncrement/Decrement ## 评分模型 发现使用可配置模型 ([`rules/scoring.yaml`](rules/scoring.yaml)) 进行评分: ``` final_score = semantic_score + reachability_bonus + sink_bonus - penalties ``` **评分组成:** - **语义分**:规则权重 x 置信度 x 类别乘数 - **可达性加成**:IOCTL (+4.0), IRP (+2.5), PnP (+2.0), Internal (+0.5) - **汇聚点加成**:memory_copy (+1.5), user_probe (+1.5), pool_alloc (+1.2) - **惩罚**:低匹配质量,高噪声风险 **门槛:** - 置信度 < 0.45 的发现将被丢弃 - 匹配置信度 < 0.40 将分数上限设为 3.0 ## 安装 ### 作为 Karton 服务(推荐) ``` git clone https://github.com/splintersfury/AutoPiff.git cd AutoPiff docker compose up -d ``` 有关包含 MWDB、仪表板和监控的完整生产堆栈,请参阅 [driver_analyzer](https://github.com/splintersfury/driver_analyzer)。 ### 独立库 ``` pip install pyyaml from services.karton_patch_differ.rule_engine import SemanticRuleEngine engine = SemanticRuleEngine('rules/semantic_rules.yaml', 'rules/sinks.yaml') hits = engine.evaluate(func_name, old_code, new_code, diff_lines) ``` ## 配置 ### 环境变量 | 变量 | 描述 | 默认值 | |----------|-------------|---------| | `MWDB_API_URL` | MWDB Core API 端点 | `http://mwdb-core:8080/api/` | | `MWDB_API_KEY` | 用于上传的 MWDB API 密钥 | (必填) | | `KARTON_REDIS_HOST` | Karton 的 Redis 主机 | `karton-redis` | | `AUTOPIFF_GHIDRA_TIMEOUT` | Ghidra 反编译超时(秒) | `900` | | `VT_API_KEY` | 用于驱动程序监控的 VirusTotal API 密钥 | (选填) | | `TELEGRAM_BOT_TOKEN` | 用于警报的 Telegram 机器人令牌 | (选填) | | `TELEGRAM_CHAT_ID` | 用于警报的 Telegram 聊天 | (选填) | | `AUTOPIFF_SCORE_THRESHOLD` | Telegram 警报的最低分数 | `8.0` | | `DRIVERATLAS_SCORE_THRESHOLD` | 分类警报的最低攻击面分数 | `8.0` | ### 规则自定义 编辑 [`rules/semantic_rules.yaml`](rules/semantic_rules.yaml) 以添加或修改规则: ``` rules: - rule_id: my_custom_rule category: bounds_check confidence: 0.85 required_signals: - sink_group: memory_copy - change_type: guard_added - guard_kind: length_check plain_english_summary: Added length validation before memory copy. ``` ## 输出格式 AutoPiff 生成附加到 MWDB 样本的 JSON 报告: ``` { "pairing": { "driver_new": {"sha256": "...", "version": "2.0.9.0"}, "driver_old": {"sha256": "...", "version": "2.0.8.0"}, "decision": "accept", "confidence": 0.95 }, "semantic_deltas": { "deltas": [ { "function": "HandleIoctl", "rule_id": "null_after_free_added", "category": "lifetime_fix", "confidence": 0.88, "sinks": ["pool_free"], "final_score": 5.5, "why_matters": "Pointer is now set to NULL after freeing memory." } ], "summary": { "total_deltas": 1, "top_score": 5.5, "match_rate": 100.0 } } } ``` ## 文档 | 文档 | 描述 | |----------|-------------| | [`Docs/semantic_rules.md`](Docs/semantic_rules.md) | 语义规则规范:规则的结构及每个类别的检测内容 | | [`Docs/SEMANTIC_RULES_REFERENCE.md`](Docs/SEMANTIC_RULES_REFERENCE.md) | 规则引擎、评估逻辑和评分的技术参考 | | [`Docs/reachability.md`](Docs/reachability.md) | 可达性标记规范:从分发入口点开始的调用图 BFS | | [`Docs/reporting.md`](Docs/reporting.md) | 报告输出规范和格式 | | [`Docs/decisions.md`](Docs/decisions.md) | 设计决策和理由日志 | | [`rules/semantic_rules.yaml`](rules/semantic_rules.yaml) | 所有 58 条检测规则 (YAML) | | [`rules/sinks.yaml`](rules/sinks.yaml) | 按类别分组的 50 多个危险 API 符号 | | [`rules/scoring.yaml`](rules/scoring.yaml) | 评分模型配置 | | [`schemas/`](schemas/) | 每个管道阶段输出的 JSON 模式 | ## 项目结构 ``` AutoPiff/ ├── Docs/ # Design docs and specifications ├── ghidra/scripts/ # Ghidra headless scripts │ └── autopiff_reachability.py # Reachability BFS + decompilation export ├── rules/ │ ├── semantic_rules.yaml # 58 detection rules │ ├── sinks.yaml # 50+ dangerous API symbols │ └── scoring.yaml # Scoring model configuration ├── schemas/ # JSON schemas for each stage ├── services/ │ ├── karton-patch-differ/ # Stages 1-4: diffing + semantic analysis │ ├── karton-reachability/ # Stage 5: call-graph + decompilation │ ├── karton-ranking/ # Stage 6: scoring │ ├── karton-report/ # Stage 7: report generation │ ├── karton-driver-triage/ # DriverAtlas attack surface triage │ ├── autopiff-alerter/ # Stage 8: Telegram alerts │ ├── driver-monitor/ # Stage 0: version polling │ └── dashboard/ # Web UI ├── tests/unit/ # 137 unit tests ├── docker-compose.yml └── README.md ``` ## 与 driver_analyzer 集成 AutoPiff 旨在与 [driver_analyzer](https://github.com/splintersfury/driver_analyzer) 协同工作,后者提供完整的生产基础设施(MWDB、Karton、MinIO、仪表板)。driver_analyzer compose 文件直接构建 AutoPiff 服务: ``` # 在 driver_analyzer/docker-compose.yml 中 karton-driver-patch-differ: build: context: ../AutoPiff dockerfile: services/karton-patch-differ/Dockerfile volumes: - ../AutoPiff/rules:/app/rules:ro ``` 有关设置说明,请参阅 [driver_analyzer README](https://github.com/splintersfury/driver_analyzer)。 ## 许可证 MIT 许可证 - 详情请参阅 [LICENSE](LICENSE)。 ## 致谢 - [Karton](https://github.com/CERT-Polska/karton) - 分布式恶意软件处理框架 - [MWDB Core](https://github.com/CERT-Polska/mwdb-core) - 恶意软件存储库 - [Ghidra](https://ghidra-sre.org/) - NSA 的软件逆向工程框架
标签:0day挖掘, API追踪, DAST, Diffing, Ghidra, UAF检测, Web报告查看器, Windows内核, YAML规则, 二进制分析, 云安全监控, 云安全运维, 云资产清单, 内核安全, 可达性分析, 威胁情报, 开发者工具, 恶意软件分析, 搜索引擎查询, 整数溢出, 白帽子, 补丁比对, 请求拦截, 逆向工具, 逆向工程, 静态分析, 驱动程序分析