llmora/mosh

# mosh：模型驱动的开放安全测试框架 使用 AI 模拟安全研究人员的执行任务，发现您应用程序中的安全漏洞并加以解决。 ## 为什么需要测试框架？ 使用 LLM 测试应用程序的安全性，远不仅是将模型指向应用程序然后放手不管。应用程序需要界定测试范围，测试用例需要针对应用程序进行适配，模型需要借助工具与被测应用程序进行交互，而且执行过程需要受到控制、留有证据且可重复。`mosh` 实现了这套封装模型的测试框架，用于开展安全测试。 `mosh` 模拟了安全研究员在测试应用程序时执行的核心任务： - **信息发现：** 绘制应用程序面，包括路由、链接、表单、JavaScript 资源、第三方服务以及可观察到的技术栈。 - **安全规划：** 将发现的证据转化为有针对性且可测试的安全假设。 - **测试执行：** 通过受控的、基于 Docker 支持的工具，在明确的授权设置下运行已准备就绪的测试。 - **报告生成：** 撰写 Markdown 报告、结构化事件日志和共享内存，确保测试结果可审查且可复现。 当更高级的 LLM 模型发布时，您无需修改测试框架，只需配置 `mosh` 使用新模型即可。 ## 安装说明 0. 首先安装以下前置条件： - Python 3.11 -- 3.13 - [uv](https://docs.astral.sh/uv/)（Python 包管理器） - Docker 1. 克隆仓库： ``` git clone https://github.com/llmora/mosh.git cd mosh ``` 2. 运行设置脚本： ``` ./scripts/setup.sh ``` 设置脚本会运行 `uv sync` 在 `.venv` 虚拟环境中安装依赖项，然后构建 Docker 工具镜像。 3. 使用 `uv run` 执行 CLI，无需激活环境： ``` uv run mosh discover https://app.example.com ``` 您也可以手动激活环境： ``` source .venv/bin/activate ``` ## 配置 在运行 CLI 之前，请设置 LLM API 密钥。 对于默认的直接使用 DeepSeek 的设置，请在 deepseek.com 开立账户并生成 API 密钥： ``` export DEEPSEEK_API_KEY="your-deepseek-api-key" ``` 或者通过 OpenRouter 进行路由，在 openrouter.ai 开立账户并生成 API 密钥： ``` export OPENROUTER_API_KEY="your-openrouter-api-key" ``` ### 模型选择 默认情况下，`mosh` 使用 DeepSeek 模型以平衡质量和成本。要选择不同的模型，请在运行 CLI 的目录中创建 `mosh.yaml` 文件： ``` models: discovery: crawler: deepseek/deepseek-v4-flash technology_mapper: deepseek/deepseek-v4-flash reporter: deepseek/deepseek-v4-flash security_planning: planner: deepseek/deepseek-v4-flash reviewer: deepseek/deepseek-v4-pro reporter: deepseek/deepseek-v4-flash engagement_refiner: deepseek/deepseek-v4-flash security_testing: executor: deepseek/deepseek-v4-flash reviewer: deepseek/deepseek-v4-pro reporter: deepseek/deepseek-v4-flash reporting: writer: deepseek/deepseek-v4-flash reviewer: deepseek/deepseek-v4-pro ``` 仅需包含您想要覆盖的 agent；省略的 agent 将保持其默认设置。例如： ``` models: discovery: crawler: openai/gpt-5.2-mini security_planning: reviewer: openai/gpt-5.2 security_testing: reviewer: openai/gpt-5.2 reporting: reviewer: openai/gpt-5.2 ``` 请使用 OpenRouter 的模型 ID，例如 `openai/gpt-5.2` 或 `anthropic/claude-sonnet-4.5`。像 `deepseek/deepseek-v4-flash` 这样的 DeepSeek ID，在设置了 `DEEPSEEK_API_KEY` 时会直接使用该密钥；否则，它们将通过 OpenRouter 进行路由，并需要提供 `OPENROUTER_API_KEY`。 ## 运行安全扫描 ### 1. 运行信息发现 首先映射应用程序： ``` mosh discover https://app.example.com ``` 信息发现将生成： ``` report//discovery/report.md ``` 可选的调整参数： ``` mosh discover https://app.example.com --max-pages 100 --max-depth 4 --output-root report ``` ### 2. 创建安全测试计划 一旦信息发现生成了证据，即可要求 `mosh` 将其转化为可测试的假设： ``` mosh plan-security https://app.example.com ``` 这将从 `report//discovery/` 读取并写入： ``` report//security-test-planning/security_test_plan.md report//security-test-planning/engagement_template.yaml ``` ### 3. 审查授权文件 在运行安全测试之前，请审查并编辑： ``` report//security-test-planning/engagement_template.yaml ``` 此文件特意保持简洁。您可以在此确认： - 授权和主动测试权限 - 生产环境目标映射 - 替代的预发布或预生产环境目标映射 - 紧急情况联系人详情 - 执行限制 - 各角色的凭据 - 安全的测试数据 安全测试团队将此文件视为执行配置。如果您将生产环境目标映射到替代目标，测试将针对映射后的目标运行（当您希望在预生产环境中运行测试时非常有用）。您还可以添加任何您认为对测试有用的其他信息，模型会检查并自动利用您提供的任何内容来改进其测试。 ### 4. 运行安全测试 当测试计划和授权文件准备就绪后，请运行： ``` mosh test-security https://app.example.com ``` 安全测试将生成： ``` report//security-testing/preflight.md report//security-testing/executed_tests/ report//security-testing/executed_tests/history/ ``` 每次安全测试运行都以预检开始。预检会读取安全测试计划和授权文件，然后将计划好的测试分为： - **就绪测试：** 具备充足的授权、目标、凭据和安全测试数据信息，测试可以运行。 - **受阻测试：** 缺少必需的信息，或者授权文件暂不允许执行该测试。 在首次运行后打开 `preflight.md`。它会告诉您哪些测试已就绪，哪些被阻断，以及缺少哪些信息。成功运行 `test-security` 后，CLI 还会打印出任何仍然阻碍完成的受阻测试，并列出需要更新的确定性授权文件字段。常见的阻碍因素包括缺少授权确认、主动测试权限、状态更改测试权限、角色凭据、安全测试数据或目标映射。 您可以重复运行安全测试，以增量方式完成测试： ``` mosh test-security https://app.example.com ``` 如果您在 `engagement_template.yaml` 中填写了缺失的信息并再次运行该命令，之前被阻断的测试可能会变为就绪状态并被执行。对于已具备当前且经审查确认的执行报告的测试将被跳过；如果计划的假设发生更改、之前的报告未经审查确认，或者之前的报告是在执行元数据可用之前生成的，则会重新运行测试。旧报告将保存在 `executed_tests/history/` 下。 如果执行的测试发现了新的应用程序面，`mosh` 会将这些事实反馈到发现内存中，更新发现报告，并刷新安全测试计划。它不会立即自动运行新计划的测试；当您准备好执行任何新就绪的测试时，请再次运行 `test-security`。 ### 5. 生成最终报告 安全测试完成后，生成面向客户的评估报告： ``` mosh report https://app.example.com ``` 最终报告生成内容： ``` report//final-report/report.md ``` 最终报告与测试期间使用的工作文档不同。它整合了主要的发现背景、执行的测试结果、已确认的漏洞、严重程度、修复指导，以及针对未发现漏洞、结果不确定、失败或未经审查确认的测试的附录。 报告采用面向客户的交付物结构： - 执行摘要：面向安全主管的文字描述，涵盖应用程序背景、测试内容、整体安全态势、主要风险以及按严重程度划分的漏洞数量。 - 概览：关于业务/应用程序背景、已确认漏洞、最高定性严重程度、未发现漏洞的测试、结果不确定的测试以及人类可读的测试周期的简短文字总结。 - 修复优先级：按定性严重程度排序的漏洞，以便快速确定修复优先级。 - 测试评估概述：关于目标、有效目标映射、从信息发现到最终报告的生命周期日期、测试范围、限制和测试方法的文字说明。 - 漏洞摘要：按严重程度和修复优先级排序的漏洞表格、严重程度统计，以及已确认/结果不确定/失败/未发现漏洞的分布情况。 - 关键发现区域：重要的路由、认证区域、API、表单、技术栈、暴露面以及限制条件。 - 详细漏洞：仅包含已确认的漏洞，附带证据、影响、技术修复指导、特定来源的修复细节或伪代码（如果有）、复测指导以及参考资料（如果有）。 - 未发现漏洞/结果不确定的测试：针对未确认为漏洞的测试的简明附录。 - 附录：方法论、使用的工具、证据索引和原始报告参考。 只有在源执行证据中包含 CVSS 时，才会将其纳入报告。否则，最终报告会将其标记为 `Not scored`。 定性严重程度取自源证据。如果某个漏洞不再出现在最新的安全计划中，`mosh` 会退而使用执行测试报告的元数据和范围部分，而不是丢失其严重程度信息。 Markdown 报告旨在直接以原样阅读。源证据和修复代码片段在需要时使用代码块包裹，这样来自执行产物的格式错误的 Markdown 就不会破坏报告的其余部分。稍后可以在其基础上导出带有样式的 HTML/PDF，但 Markdown 始终是源交付物，因此易于审查、差异对比和版本控制。 ## 端到端示例 ``` mosh discover https://app.example.com mosh plan-security https://app.example.com # 查看并编辑 report/app.example.com/security-test-planning/engagement_template.yaml。 mosh test-security https://app.example.com # 如果 CLI 报告测试被阻止，请添加缺失的 engagement 详情并再次运行。 mosh test-security https://app.example.com mosh report https://app.example.com ``` ## 获得内容 完整运行后，您将拥有： - 一份描述观察到的应用程序面的信息发现报告 - 一份基于信息发现证据的安全测试计划 - 一份可编辑的授权模板，用于管理权限、目标、凭据、限制和安全测试数据 - 详细的测试执行报告，包含解决情况 - 一份面向客户的 Markdown 最终报告 ## 解决漏洞 安全测试报告将写入： ``` report//security-testing/executed_tests/ ``` 每份已执行的测试报告旨在支持修复，而不仅仅是检测。利用它您可以了解： - 测试了什么 - 使用了哪个目标和角色 - 收集了哪些证据 - 该漏洞是被接受、拒绝，还是需要进一步审查 - 建议采取什么修复或缓解措施 - 在应用程序更改后应重新运行什么 实际的修复闭环如下所示： 1. 审查已执行的测试报告，并根据记录的证据确认漏洞。 2. 修复应用程序中的易受攻击行为。 3. 将应用程序重新部署到授权文件涵盖的目标环境中。 4. 再次运行安全测试： ``` mosh test-security https://app.example.com ``` `mosh` 会将当前计划和执行元数据与之前的报告进行比较。已处于最新状态且被接受的测试将被跳过，而需要新证据的测试可以再次运行。这使得修复后的重复测试非常有用：您可以保留历史报告，但当前运行会显示该漏洞是否依然复现。 如果修复更改了应用程序面，请在重新测试前再次运行信息发现和规划： ``` mosh discover https://app.example.com mosh plan-security https://app.example.com mosh test-security https://app.example.com ``` 随着应用程序的变化，请保持授权文件处于最新状态。新的角色、测试账户、安全测试数据或预发布映射可以解除对更多测试的阻断，并为 `mosh` 提供充足的上下文来验证应用程序的更多部分。 ## 实现原理 模型驱动的开放安全测试框架保持了简单的 runtime 架构： ``` orchestrator -> agent -> tools ``` orchestrator 负责协调整个运行过程。agent 负责专业工作。工具由 agent 调用。外部扫描器运行在 Docker 容器中，而不是安装在宿主机上。 当前的团队包括： - **信息发现团队：** 抓取并总结应用程序面。 - **安全规划团队：** 将信息发现的证据转化为界定范围后的测试假设。 - **安全测试团队：** 使用授权文件和一次性的 Docker 执行环境来检查已就绪的假设。 信息发现镜像包含 Katana、Dirb、Extractify、静态 JavaScript endpoint 提取工具、Node.js、npm 以及系统级的 Chromium。安全镜像包含用于一次性安全测试工作区内的命令行工具。 ## 未来路线图 计划扩展的领域包括源代码评估、更深度的基于浏览器的 SPA 发现、更丰富的 API endpoint 提取、更多基于 Docker 的安全工具、基于 Web 的 GUI 以及更广泛的报告支持。 ## 开发说明 安装项目： ``` ./scripts/setup.sh ``` 运行测试套件： ``` uv run python -m unittest discover -v ``` 在开发基于 Docker 的功能时强制重建 Docker 工具镜像： ``` ./scripts/setup.sh --force-docker ``` ## 贡献指南 模型驱动的开放安全测试框架易于解释、实用且目标明确。优秀的贡献应当使其更加实用，同时不增加理解难度。 请遵循以下准则： - 以小而易于审查的粒度进行更改。 - 为每一个行为变更添加或更新测试。 - 当产品行为、架构、输出格式或路线图发生变化时，保持 `SPEC.md` 同步更新。 - 当安装、配置、命令、示例或面向用户的行为发生变化时，保持此 `README.md` 同步更新。 - 保留 `orchestrator -> agent -> tools` 的架构。 - 将外部安全工具保留在 Docker 容器中，而不是要求在宿主机上安装。 - 除非直接支持正在进行的更改，否则避免进行大规模的重构。 在提交 pull request 之前，请创建验证您更改的测试，并确保所有测试通过： ``` uv run python -m unittest discover -v ``` 当您的更改影响到 runtime 行为时，还请在您已获授权测试的应用程序上运行相关的 CLI 流程。 ## 许可证 mosh 采用 Apache License, Version 2.0 授权。详见 [LICENSE](LICENSE)。

标签：C2, DLL 劫持, Python, 大语言模型, 安全测试, 实时处理, 密码管理, 攻击性安全, 无后门, 自动化渗透测试, 请求拦截, 逆向工具