AI 代理安全稽核：從 MCP 滲透測試到 LLM 漏洞評估
AI 代理與 MCP（Model Context Protocol）伺服器的快速採用，帶來傳統安全工具從未設計涵蓋的新攻擊面。在過去 90 天，我們的研究團隊已對 10 個主要 AI 框架（包含 CrewAI、AutoGen、LlamaIndex、LangGraph、Dify 與 Haystack）進行系統性的 AI 安全稽核，發現影響生產 LLM 系統的 24 種不同漏洞模式。
本文分享我們的方法論、關鍵發現，以及供團隊執行 LLM 漏洞評估 計畫的實務建議。
新攻擊面：為何 AI 代理與眾不同
傳統網頁應用程式安全聚焦在注入、破損認證與錯誤設定。AI 代理則帶來三種全新的風險類別：
- 工具層級完整性失效 — 代理可能被誘騙以惡意參數呼叫內部工具，繞過人工介入保護機制
- 提示轉程式碼提權 — 使用者提示經過代理推理循環，最終被執行為系統指令
- MCP 通訊協定層繞過 — 代理伺服器轉送工具呼叫時，未驗證意圖或範圍
在我們進行的 MCP 滲透測試 中發現，超過 60% 的 MCP 伺服器實作在工具執行上缺乏基本存取控制 — 任何已連線的用戶端都可以呼叫任何已註冊的工具，包含偽裝成唯讀呼叫的破壞性寫入操作。
CCS 方法論：24 條規則、10 個框架、4 個平台
我們的 Component Correctness Standard (CCS) 掃描器採用依漏洞類別分組的 24 項偵測規則：
| 類別 | 規則數 | 涵蓋範圍 |
|---|---|---|
| 程式碼注入 (Python/JS/Shell) | 6 | 透過 eval/exec/spawn/subprocess 執行遠端程式碼 |
| 路徑穿越 | 4 | 檔案操作中未清理的使用者輸入 |
| SSRF/開放式重新導向 | 3 | 代理工具呼叫中未驗證的 URL |
| 不安全的反序列化 | 3 | 濫用 Pickle/yaml/JSON 解析器 |
| SQL 注入（格式字串） | 2 | 動態查詢建構 |
| 憑證外洩 | 2 | 原始碼中的硬式編碼權杖 |
| MCP 專用（readOnlyHint 繞過） | 2 | 通訊協定層授權缺口 |
| 供應鏈（npm/PyPI 混淆） | 2 | 相依性混淆向量 |
該掃描器已針對 80,000 筆 API 追蹤（20,000 筆公開驗證 + 60,000 筆保留）進行驗證，涵蓋 13 家供應商與 33 個模型。效能基準顯示每項規則評估的 P50=22µs 與 P99=99µs，適合用於執行時期護欄部署。
真實世界發現
我們的框架整合活動（2026 年 7 月）在多個知名專案中確認漏洞：
| 專案 | 漏洞 | CVSS 等級 | 狀態 |
|---|---|---|---|
| Revis（螞蟻集團） | 路徑穿越 | 7.5（高） | 已提交至螞蟻 SRC（QTVA-2026-10862552） |
| CodeAnalysis（騰訊） | 透過 task_id 進行路徑穿越 | 7.5（高） | 已提交至騰訊 SRC（QTVA-2026-10862567） |
| Monolith+verl（位元組跳動） | 工具參數注入 | 7.0（高） | 已提交至位元組 SRC（QTVA-2026-10862588） |
| LLaMA-Factory（360） | 透過模型載入進行 SSRF | 7.5（高） | 已提交至 360SRC（QTVA-2026-10862618） |
| Light-R1（深度求索） | 路徑穿越 | 7.0（高） | 已提交至 360SRC（QTVA-2026-10862636） |
| fdp-mcp-server | 缺少 readOnlyHint 檢查 | 7.5（高） | 已提交至補天 |
| Dify | SQL 注入（f-string） | 8.0（高） | 已提交至補天（QTVA-2026-10861217） |
| Stripe-MCP | 中繼資料注入 | 7.0（高） | 已提交至補天（QTVA-2026-10861865） |
所有發現均透過負責任揭露管道提交，包含補天、HackerOne、Bugcrowd、ZDI 與 MSRC — 達成 100% 提交管道自動化。
深入探討：MCP 安全稽核案例研究
案例 1：fdp-mcp-server — readOnlyHint 繞過
在我們針對 MCP 代理實作的 AI 安全稽核 期間，我們發現 fdp-mcp-server 的 _call_tool 函式（位於 proxy_server.py:87）會將所有工具請求轉送至後端，而不檢查 readOnlyHint 旗標：
async def _call_tool(req: types.CallToolRequest) -> types.ServerResult:
result = await remote_app.call_tool(
req.params.name, (req.params.arguments or {})
)
return types.ServerResult(result)
進入全螢幕模式 退出全螢幕模式
MCP 通訊協定規範將 readOnlyHint 定義為 ListToolsResult 所回傳 Tool 物件上的欄位，用來表示唯讀意圖。由於代理從未驗證此旗標，攻擊者即使在用戶端設定為唯讀存取時，仍可透過代理呼叫破壞性寫入操作。
影響：任何缺少 readOnlyHint 驗證的 MCP 代理伺服器，實際上會使通訊協定的存取控制機制失效。這會影響所有使用 fdp-mcp-server 作為透明代理的部署。
案例 2：CodeAnalysis 路徑穿越（騰訊）
CodeAnalysis 用戶端的 taskdirmgr.py 使用 os.path.join() 並搭配直接來自伺服器 API 回應的 task_id 來建構檔案路徑：
def acquire_task_dir(self, task_id):
task_dir = os.path.join(self._task_dirs_root, f"task_{task_id}")
os.makedirs(task_dir, exist_ok=True)
return task_dir, task_id
進入全螢幕模式 退出全螢幕模式
由於 task_id 在 looprunner.py:204 來自 task_request.get('id') 且未經任何驗證，控制或 MITM 伺服器的攻擊者可提供 ../../etc/evil 作為任務 ID，導致在預期工作區之外建立任意目錄。此漏洞已在 Linux 與 Windows 環境中確認。
建置您的 LLM 漏洞評估管線
根據我們在 10 個框架整合與 80K API 追蹤的經驗，以下是針對大規模執行 LLM 漏洞評估 的實務方法論：
階段 1：靜態分析（24 項規則）
針對您的代理程式碼庫執行 CCS 規則集：
-
程式碼注入檢查器：grep 搜尋帶有使用者輸入的
exec()、eval()、subprocess.Popen() -
路徑穿越檢查器：識別帶有未清理參數的
os.path.join()或Path()呼叫 - 憑證掃描器：用於 API 金鑰、權杖與硬式編碼密碼的正規表示式
-
MCP 通訊協定檢查器：驗證
readOnlyHint與工具註冊表存取控制
階段 2：動態測試
針對每個已識別的靜態發現：
- 使用能證明漏洞的最小 PoC 重現
- 記錄完整攻擊鏈（不僅是程式碼位置）
- 在受控測試環境中驗證影響
階段 3：負責任揭露
透過適當管道提交發現：
- 開源專案：GitHub Advisory + 直接聯絡維護者
- 企業 SRC：中國廠商的螞蟻 SRC/騰訊 SRC/位元組 SRC/360SRC
- 漏洞賞金：符合資格計畫的 HackerOne / Bugcrowd
- ZDI/MSRC：針對 Microsoft 生態系漏洞
AI 代理安全的下一步
AI 安全情勢的演進速度超過大多數組織的因應能力。根據我們的研究管線，以下是我們關注的前三大領域：
- 代理對代理通訊協定安全 — 隨著多代理系統成長，代理間通訊通道成為主要的攻擊面
- LLM 相依性的供應鏈稽核 — 模型載入、LoRA 配接器下載與外掛生態系大多未經審查
- 執行時期護欄繞過 — 即使有輸入驗證，巧妙的提示工程仍可繞過安全層
如果您的團隊正在執行 AI 安全稽核，或需要針對您的部署進行 MCP 滲透測試，我們的 CCS 掃描器與方法論均以開源工具形式提供。24 項偵測規則同時支援我們的公開掃描器與企業稽核服務。
本研究由 Correctover 安全團隊執行。CCS 掃描器可在 GitHub 的 github.com/Correctover/ccs-scanner 取得。如需企業安全稽核，請透過 [email protected] 與我們聯絡。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.