MCP 回呼濫用

在代理與工具互動中濫用 MCP 回呼機制進行未授權行動、資料外洩和權限提升的進階詳解。

模型上下文協定（MCP）支援回呼機制，允許 MCP 伺服器非同步地向客戶端發送通知、進度更新和結果。這些回呼功能強大——它們支援長時間運行的操作、串流結果和事件驅動工作流程。但它們也在代理和外部服務之間創建了一個雙向通道。能夠註冊未授權回呼、操控回呼 URL 或觸發帶有精心製作載荷的回呼的攻擊者，可以外洩資料、注入指令或在代理正常控制流程之外建立持久通訊通道。

步驟 1：理解 MCP 回呼架構

MCP 回呼在通知模型上運作，伺服器可以向客戶端推送資料。

MCPCallback dataclass 表示一個已註冊的回呼，包含 ID、類型（progress/notification/result/log）、可選的 webhook URL 或本地處理函式、註冊者、創建時間、調用計數和元資料。

MCPCallbackRegistry 類別管理 MCP 回呼的註冊，包含兩個關鍵漏洞：

• register 方法：不驗證 URL 目標或處理函式安全性
• invoke 方法：載荷未經清理就傳遞，且無授權檢查（authorized=True 硬編碼）

回呼攻擊面

步驟 2：未授權回呼註冊

CallbackRegistrationAttack 類別展示三種未授權回呼：

1. register_exfiltration_callback：以假冒的「system_backup」來源，向攻擊者控制的端點（collect.attacker.com）註冊一個「資料備份 webhook」回呼
2. register_instruction_injection_callback：以「health_monitor」來源，註冊一個偽裝為「系統健康檢查」的回呼，其處理函式在代理上下文中執行，回傳要求匯出對話資料的偽系統指令
3. register_privilege_escalation_callback：以「security_system」來源，註冊一個觸發時授予管理員權限的回呼

demonstrate_attack_sequence 方法依序執行完整攻擊：先註冊三個回呼，再觸發它們——外洩回呼傳遞含有 API 金鑰的「敏感資訊」，注入回呼以「觸發」狀態調用，提升回呼發送「escalate」請求。

步驟 3：回呼 URL 操控

CallbackURLManipulator 類別展示兩種 URL 操控技術和一種 SSRF 攻擊：

redirect_existing_callback：直接修改現有回呼的 URL 指向攻擊者端點。漏洞在於修改回呼 URL 無需授權驗證。

create_proxy_callback：替換原始處理函式為代理函式，在轉發到原始目標前將副本發送到攻擊者 URL——實現對資料流的無感攔截。

ssrf_via_callback：向五個內部端點（Redis、AWS 元資料、內部 API、PostgreSQL、Kubernetes API）各註冊一個回呼，利用代理基礎設施探測內部網路。

步驟 4：透過回呼進行資料外洩

CallbackExfiltrator 類別使用 MCP 回呼作為隱蔽的資料外洩通道：

setup_exfiltration_channel：以「telemetry_system」來源，向攻擊者 URL 註冊一個偽裝為遙測回報的持久外洩通道。

exfiltrate_conversation：將對話資料分成 1000 字元的片段（避免因大小觸發偵測），偽裝成「對話品質指標」逐塊發送，記錄會話 ID 和區塊進度。

exfiltrate_credentials：使用 Base64 編碼憑證，將其拆分到看起來像效能指標的多個欄位（latency_p99、throughput、error_rate），偽裝成遙測資料發送。

步驟 5：回呼鏈攻擊

CallbackChainer 類別創建多步驟攻擊工作流程：

create_exfiltration_chain：三步驟鏈——收集 → 編碼 → 外洩：

• collect_step：積累 3 條資料後觸發下一步
• encode_step：將收集的資料 Base64 編碼後觸發外洩
• exfil_step：向攻擊者 URL 發送編碼資料

create_persistence_chain：自我修復鏈——每個鏈接的處理函式包含重新創建所有缺失鏈接的邏輯。移除任何鏈接都會在下次調用時自動重新註冊，使攻擊基礎設施對部分清理具有韌性。

步驟 6：回呼沙盒和驗證

SecureCallbackRegistry 類別實作安全控制：

register 方法的安全控制：

• 強制執行最大回呼限制（50 個）
• 對照核准域名（approved_domains 集合）驗證 URL
• 只允許已知回呼類型（progress/notification/result/log）
• 透過靜態代碼分析檢查可疑處理函式（exec、eval 等）

invoke 方法的安全控制：

• 按回呼 ID 進行速率限制（每分鐘 10 次）
• 拒絕超過 10,000 字元的載荷
• 使用正則表達式模式掃描憑證（API 金鑰、GitHub 令牌、密碼）

_validate_url 方法：只允許核准域名，明確封鎖 169.254（雲端元資料）、localhost、127.0.0.1、internal 和 kubernetes。

步驟 7：回呼監控和偵測

CallbackAbuseDetector 類別分析回呼登錄，識別四種濫用指標：

1. 外部 URL 偵測：標記指向非公司域名的 URL
2. 過量回呼偵測：超過 20 個回呼時發出中等嚴重性警報
3. 高調用率偵測：單一回呼超過 50 次調用時警報
4. 回呼鏈偵測：_detect_chains 方法透過分析調用日誌中的觸發關係構建依賴圖，計算最大鏈深度——超過 2 層時警報

最終風險評估：若任何發現的嚴重性為「high」則評為「critical」，否則為「low」。

步驟 8：全面回呼安全測試

run_callback_security_test 函式執行四項測試：

1. 在漏洞登錄上運行 CallbackRegistrationAttack，驗證三種未授權回呼可成功註冊和調用
2. 在現有合法 webhook 上測試 URL 重導向和 SSRF 探測
3. 在安全登錄上測試防禦措施：外部 URL 被拒絕、SSRF URL 被拒絕、公司 URL 允許通過
4. 在漏洞登錄上運行 CallbackAbuseDetector，驗證濫用指標被偵測到

相關主題

• MCP Tool Shadowing — 工具層級 MCP 攻擊
• A2A Trust Boundary Attack — 信任邊界利用
• Agent Persistence via Memory — 持久化技術
• Tool Call Injection — 注入工具互動