我尝试用本地 AI 模型 (Qwen 3.6 27b) 进行安全研究，效果出奇地好。https://t.co/09HOfCr6vH

本地 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 已认证本地文件包含

基准漏洞是一个经典的 php 已认证本地文件包含 (LFI) 问题。

控制器名称（https://github.com/phpipam/phpipam/blob/137141d89a44e9979eb0df52427ec0e676077f03/api/index.php#L236）直接从用户输入获取，并直接拼接到 require_once 中，没有任何清洗。

如果 API 已启用（默认禁用），并且你有有效凭据获取 API 令牌，就可以包含/执行 Web 服务器可访问的、以 .php 结尾的任何文件。

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

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

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

如果你运行 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，这样可以先使用更便宜的模型观察令牌消耗。

GLM 5.1 的基准测试与 Strix 推荐的模型相似，但请谨慎对待这个结果。

实际运行起来确实令人兴奋。

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

大约 12 小时后，消耗了近 60 百万个令牌，生成了一个 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 中存在功能级授权缺陷（非管理员用户可以创建管理员资源）
• 在状态改变的 admin 端点上存在多个 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 中使用 ‘Pro’ 计划并应用此技能，结果非常糟糕。

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

明确要求它生成子代理，结果瞬间达到了我 5 小时的会话限制……

Cursor + GPT 5.5 (Medium) – 如果使用 Open Router，大约花费 5-10 美元

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

问题所在

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

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

更彻底！使用技能提问

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

不行哎。求求啦？

再试一次。即使我能越过拒绝，这种方法可能成本也高得离谱。

但是，如果给定单个源代码文件 + 上下文，而不是一次性审查整个代码库这个困难得多的任务，本地模型是否就足够了呢？

本地 AI 模型 + 自定义框架

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

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

高级示意图。

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

``

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

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

描述

API 入口点使用未经清理的用户提供的 controller 参数来构建文件包含路径。该值从 $_GET、$_POST、JSON 主体或 XML 主体直接流入 require_once()，没有路径验证，允许目录遍历 (../) 以包含文件系统中的任意 PHP 文件。

— 截断 — ``

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

局限性

• 令牌密集 – 如果不能本地运行模型，则成本高昂。- 幸运的是，Project Black（https://projectblack.io/）已经维护了一个用于渗透测试的 hashcat 装备，在这些测试中需要密码破解（https://projectblack.io/penetration-testing/internal-network-penetration-testing/）。结果证明，这个硬件也足以运行 Qwen 3.6 27b（约 170k 上下文）。
• 误报 – 非常多。- 由于这种方法纯粹基于代码审查，可能导致误报，你可以将此阶段的输出输入到更多 AI 工具中以验证可利用性，但这会进一步增加令牌消耗。
• 缺乏威胁模型/更广泛的应用上下文理解。- 从我针对其他已知问题的测试来看，它似乎难以识别更复杂的访问控制缺陷（https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/）问题，这些问题的假设存在更细微的差异。

无论如何，一次可能只是侥幸。让我们看看它是否能找到一些我还不知道的东西？

myVesta 已认证远程代码执行

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

时机正好。目标已锁定。8 小时后，它发现了已认证的远程代码执行。

补充背景信息：像 cPanel 这样的 Web 服务器控制面板用于让互联网上的随机用户能够在共享 Web 服务器上执行有限的管理任务。此类软件中的已认证 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 在哪些方面能发挥其价值。