本地AI助力渗透测试与研究

来源：https://projectblack.io/blog/local-ai-for-cyber-security/ 自上次尝试类似工作（https://projectblack.io/blog/vibe-hacking-open-game-panel-rce/）以来，模型智能和技术能力在过去一年中取得了长足进步。

Anthropic 发布的研究引发了大量炒作；然而，成本和隐私问题依然存在。当无法保证工作是否彻底完成时，保障工作就变得更像是一场赌博。

0:00

/0:03

再来一次！“不要犯错，要彻底”

因此，我做了一个小测试。

我对比了四种不同方法，以识别一个我知道存在的漏洞，从而评估每种方法发现它的效率。

基准漏洞 - PHPIPAM 认证本地文件包含（LFI）

基准漏洞是一个经典的.php认证本地文件包含（LFI）问题。

控制器名称（https://github.com/phpipam/phpipam/blob/137141d89a44e9979eb0df52427ec0e676077f03/api/index.php#L236）取自用户输入，并直接拼接进require_once，未进行任何清理。

如果 API 已启用（默认禁用），并且您拥有获取 API 令牌的有效凭据，那么就有可能包含/执行 Web 服务器可访问的文件系统中任何以.php扩展名结尾的文件。

第二次请求包含了一个我放入的phpinfo();文件以演示该问题。⚠️

该问题在没有补丁的情况下被公开披露，因为其风险相对较低，且未收到 PHPIPAM 维护者的回复。

该漏洞仅影响启用了 API 的实例（默认未启用）。默认影响也有限，似乎无法将任意.php文件上传到 Web 服务器，也没有任何有趣的可包含/执行的默认文件。

如果您正在运行 PHPIPAM 并希望立即自行采取措施，我建议在此期间禁用 API。此问题已被跟踪为CVE-2026-12194（https://www.cve.org/CVERecord?id=CVE-2026-12194）。

结果

**太长不看：**在我测试的四种方法中，最成功的一种说明了一个问题：工具/方法比模型本身更重要。

如果您只对该方法感兴趣，可以跳到此处（https://projectblack.io/blog/local-ai-for-cyber-security/#local-ai-model-a-custom-harness）。

``

Semgrep

仅使用semgrep scan --config auto运行的 Semgrep 未能识别该漏洞。

当然，可以编写自定义规则来检测这种特定模式。然而，这始终是传统 SAST 工具的核心挑战之一：你只能为你已经知道存在的危险模式编写规则。

GLM 5.1 + Strix 全自主 AI 渗透测试

接下来，我尝试了Strix（https://github.com/usestrix/strix）：一个用于渗透测试的全自主 AI 工作流。

开源 AI 黑客，用于发现和修复您应用的漏洞。

https://github.com/usestrix/strix#open-source-ai-hackers-to-find-and-fix-your-apps-vulnerabilities 拥有超过 25,000 个 GitHub 星标，我很想看看它能做什么/能否识别这个漏洞。

💡

***** 注意 *****：其文档要求使用 GPT-5.4、Claude Sonnet 4.6 或 Gemini 3 Pro。

我不太想开出空白支票，所以我选择了 GLM 5.1，以便先用更便宜的模型观察 token 消耗。

GLM 5.1 的基准测试结果与 Strix 推荐的模型相当，但请对结果持保留态度。

实际运行过程非常令人兴奋。

它克隆了仓库，探索了代码库，甚至自行安装了应用程序，以便动态验证潜在的发现。

大约 12 小时后，使用了近6000 万 token，并为我准备好了一份report.md文件。

$它没有找到我们的 LFI。这让我想起了这条推文。

GPT-5 在一次调用中重构了我的整个代码库。25 次工具调用。3000+ 行新代码。12 个全新文件。它模块化了所有内容。拆分了大块代码。清理了混乱结构。但其中没有一个能正常工作。不过，它真的很美。pic.twitter.com/RCTGK1DE9H (https://t.co/RCTGK1DE9H) — vas (@vasuman) 2025年8月7日 (https://x.com/vasuman/status/1953531950137815374?ref_src=twsrc%5Etfw)

使用 GLM 5.1 的实际花费约为 30 美元（尽力将请求也路由到免费推理提供商）。

如果我使用 Sonnet，成本大约在 180 美元到 300 美元之间。使用 Opus 成本将翻倍。

我不想花那么多钱用更昂贵的模型再试一次。

`` 生成时间： 2026-05-22 04:33:37 UTC

执行摘要

对 phpIPAM（IP 地址管理）1.8.1 版本进行的外部渗透测试发现了多个安全弱点，如果被利用，可能导致敏感数据泄露、存储型跨站脚本攻击、服务器端请求伪造和权限提升。

总体风险等级：高。

主要发现包括：

• 通过 API 泄露敏感用户数据（任何认证用户均可访问密码哈希、令牌、2FA 密钥）
• 通过 API 的存储型 XSS（HTML 转义被禁用，允许持久性脚本注入）
• 在 vault 证书获取中的 SSRF（可进行内部网络扫描和云元数据访问）
• API 中功能级授权失效（非管理员用户可以创建管理员资源）
• 多个状态变更管理端点的 CSRF 漏洞
• 自定义字段重排序功能中的二阶 SQL 注入
• 使用松散比较而非时序安全比较导致的弱 CSRF 令牌验证 ``

其中一些问题按 PHPIPAM 的威胁模型设计本是如此。其他问题看起来像是误报/不太有趣/已被修复。

云端 SOTA + 基于技能的代码审查

接下来我尝试了不同的方法：AI 技能。

对于不熟悉这个概念的人来说，AI 技能本质上是 Markdown 文件，为代理提供特定的指令、工作流程和专业知识。

我以社区贡献的安全审查技能为基础。

awesome-copilot/skills/security-review/SKILL.md at main · github/awesome-copilot 社区贡献的指令、代理、技能和配置，帮助您充分利用 GitHub Copilot。 - github/awesome-copilot GitHubgithub (https://github.com/github/awesome-copilot/blob/main/skills/security-review/SKILL.md) 我所做的更改包括：

• 移除了依赖审计、密钥扫描和提议补丁步骤。
• 将每个漏洞类别分解为其专用的子代理。
• 扩展了注入缺陷部分，增加了关于本地文件包含（LFI）的额外指导。

最终，我发现结果非常不一致。扫描有时能找到漏洞，有时却完全遗漏。

Claude Code + Opus 4.8

在 Claude Code 中尝试使用“专业”计划配合此技能，结果相当糟糕。

查看推理过程，它决定不生成子代理来处理每个漏洞类别。

要求它显式生成子代理导致立即达到我的 5 小时会话限制……

Cursor + GPT 5.5（中等）- 如果使用 Open Router 大约 5-10 美元

又尝试了几次不同的模型后，有一次使用 Cursor 和 GPT 5.5 找到了问题。

问题所在

我很快意识到，在相当大的代码库中，审查并不彻底。问题是否被发现通常取决于代理决定读取哪些文件以及它选择 grep 什么术语。

有趣的是，一旦指向正确的文件，几乎所有模型都能立即识别漏洞。

更彻底些！通过技能请求

尝试使用技能方法立即遭到了拒绝。查看模型的推理，它经常得出结论认为任务太大，无法一次性完成。

不。求求你了？

再试一次？即使我通过了拒绝，这个方法也可能成本过高。

但是，如果只给本地模型单个源代码文件 + 上下文（而不是一次性审查整个代码库这种更难的任务），它是否足够呢？

本地 AI 模型 + 自定义工具

我们的下一种方法将单个大规模审查替换为一个小的本地工具。该方法不是让一个代理一次性推理整个代码库，而是让该工具逐个源文件地遍历项目，每次只向本地模型传递一个文件及其所需的上下文。

对于每个源文件： | +--> 本地模型审查单个文件（+ 上下文） | +--> 编写结构化报告 | v 收集所有报告 | v ？？？ | v 利润

高层示意图。

这种方法每次运行都找到了我们的基准漏洞。

``

安全漏洞报告：api/index.php

高风险：通过控制器参数进行路径遍历/任意文件包含

描述

API 入口点使用未经清理的用户输入构建文件包含路径。该值来自 $_GET、$_POST、 JSON body 或 XML body，直接传入 require_once() 而未进行路径验证， 使得目录遍历（../）能够从文件系统中包含任意 PHP 文件。

— 截断 — ``

对于这个代码库，我估计审查大约 800 个源文件消耗了大约1.2 亿 token。

局限性

• Token 密集 - 如果你无法本地运行模型，则成本高昂。
  • 幸运的是，对于需要密码破解（https://projectblack.io/penetration-testing/internal-network-penetration-testing/）的渗透测试，Project Black（https://projectblack.io/）已经维护了一套 hashcat 设备。事实证明，这些硬件也足以运行 Qwen 3.6 27b（约 170k 上下文）。
• 误报 - 很多。
  • 由于这种方法完全基于代码审查，可能会产生误报。你可以将本阶段的输出输入到更多的 AI 工具中以验证可利用性，但这会进一步增加 token 消耗。
• 缺乏威胁模型/更广泛应用上下文的理解。
  • 根据我对其他已知问题的测试，它在识别更复杂的失效的访问控制（https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/）问题时似乎有些吃力，这些问题在假设上存在更细微的差异。

不管怎样，一次可能是侥幸。让我们看看它是否能找到一些我还不知道的东西？

myVesta 认证 RCE

就在我完成基准测试时，我收到了一个使用myVesta（https://github.com/myvesta/vesta）的朋友的消息——这是一个类似于 cPanel 的 Web 服务器控制面板。

时机正好。目标已确认。8 小时后，它发现了认证 RCE。

作为背景，像 cPanel 这样的 Web 服务器控制面板用于让互联网上的普通用户能够在共享 Web 服务器上执行有限的 administrative 任务。这种软件中的认证 RCE 漏洞意味着你可以注册一家托管服务提供商的账户，并可能接管服务器。此命令以 Web 服务器上权限更高的admin用户身份执行，而非你自己的用户。

结果发现，FTP 用户名删除函数中的一些遗留代码允许将 Username 参数直接传入exec。

创建示例请求。用 POC 替换请求中的用户名。检查服务器上是否创建了文件。感谢 myvesta 团队对此问题的快速响应！此问题已被跟踪为CVE-2026-12195（https://www.cve.org/CVERecord?id=CVE-2026-12195）。

web\edit\web\index.php 修复 · myvesta/vesta@95d7e43 myVESTA 控制面板。通过在 GitHub 上创建账户来贡献 myvesta/vesta 的开发。 GitHubmyvesta (https://github.com/myvesta/vesta/commit/95d7e43bf286d6881ca753dac93cb42d98cc7422) 已在此处修补。

我们能否继续？

事实证明，可以。

还有更多发现正在进行中。

我们暂不透露细节，以便给受影响的项目时间进行修补。它们会适时公开，但后续还有更多内容。

结论

随着本地 AI 模型的不断改进，这些能力将落入更多的人手中，而不是更少。我认为总体上是件好事。

在我们这边，我们正在尝试如何将这类技术融入我们的工作方式，这可能意味着为我们的客户提供更快、更彻底的渗透测试（https://projectblack.io/penetration-testing/）。这里潜力巨大，我们将继续摸索，看看本地 AI 在哪些地方能真正发挥作用。