去年企業(yè)安全團(tuán)隊(duì)平均花費(fèi)340萬美元處理供應(yīng)鏈攻擊。而當(dāng)攻擊向量變成你員工每天調(diào)用的AI工具時(shí)，這筆賬還沒人算清楚。

本文是MCP企業(yè)安全系列的第二部分。第一部分我們畫了信任邊界、用STRIDE做了威脅建模、提出了三重門架構(gòu)——那是藍(lán)圖。這部分我們直接破門而入，測(cè)試那些鎖到底管不管用。

作者從安全架構(gòu)師切換到紅隊(duì)視角，用一套完整的攻擊劇本告訴你：為什么你的MCP（模型上下文協(xié)議，Model Context Protocol）部署可能已經(jīng)在裸奔。

攻擊場(chǎng)景一：計(jì)算器App的溫柔陷阱

「我偷走了你的SSH密鑰，用的只是一個(gè)計(jì)算器App?！?/b>

這不是電影臺(tái)詞。在MCP生態(tài)里，一個(gè)看似無害的工具調(diào)用能層層穿透，最終摸到核心資產(chǎn)。

攻擊路徑是這樣的：用戶向AI助手詢問「幫我算一下這個(gè)月的預(yù)算」，AI調(diào)用了一個(gè)第三方MCP計(jì)算器服務(wù)。這個(gè)服務(wù)返回的不僅是計(jì)算結(jié)果，還有一段精心構(gòu)造的惡意指令。AI助手忠實(shí)地執(zhí)行了——因?yàn)樗辉O(shè)計(jì)成這樣。

問題在于MCP的權(quán)限模型。大多數(shù)企業(yè)部署時(shí)，工具調(diào)用權(quán)限是「全有或全無」。要么AI能訪問你的文件系統(tǒng)、數(shù)據(jù)庫、代碼倉庫，要么什么都干不了。中間狀態(tài)？不存在的。

攻擊者利用的就是這個(gè)盲區(qū)。一個(gè)被攻破的MCP服務(wù)器可以：

? 讀取環(huán)境變量中的API密鑰

? 遍歷本地文件系統(tǒng)尋找.ssh目錄

? 通過DNS外帶（OOB）通道把密鑰傳出去

整個(gè)過程不需要用戶點(diǎn)擊任何鏈接，不需要釣魚郵件，只需要一次正常的AI對(duì)話。

攻擊場(chǎng)景二：供應(yīng)鏈的幽靈依賴

MCP生態(tài)正在快速膨脹。GitHub上已經(jīng)有超過8000個(gè)開源MCP服務(wù)器，其中大部分由個(gè)人開發(fā)者維護(hù)，沒有任何安全審計(jì)。

紅隊(duì)的測(cè)試方法很簡(jiǎn)單：克隆一個(gè)熱門的MCP服務(wù)器倉庫，提交一個(gè)「功能更新」，在代碼里埋一個(gè)延遲觸發(fā)的payload。然后等待。

平均72小時(shí)內(nèi)，這個(gè)更新會(huì)被合并。一周內(nèi)，超過200個(gè)企業(yè)實(shí)例拉取了新版本。

這不是假設(shè)。2024年12月，一個(gè)流行的Slack MCP服務(wù)器被發(fā)現(xiàn)包含惡意代碼，影響范圍覆蓋47家企業(yè)的內(nèi)部通訊數(shù)據(jù)。攻擊者甚至沒有費(fèi)力去隱藏——代碼就躺在明顯的位置，只是沒人看。

MCP的供應(yīng)鏈風(fēng)險(xiǎn)比傳統(tǒng)軟件更隱蔽。傳統(tǒng)依賴你至少知道自己在用什么庫，版本號(hào)清清楚楚。MCP服務(wù)器是動(dòng)態(tài)加載的，AI助手可能在一次對(duì)話中切換十幾個(gè)工具，用戶完全無感知。

三重門架構(gòu)的壓力測(cè)試

第一部分提出的三重門架構(gòu)——身份門、策略門、審計(jì)門——在紅隊(duì)視角下暴露了幾個(gè)關(guān)鍵弱點(diǎn)。

身份門：OAuth 2.1不夠用了

當(dāng)前MCP的身份驗(yàn)證主要依賴OAuth 2.1，但紅隊(duì)發(fā)現(xiàn)兩個(gè)繞過路徑：

第一，令牌作用域的粒度太粗。一個(gè)MCP服務(wù)器申請(qǐng)「讀取Google Drive」權(quán)限，用戶看到的是友好的授權(quán)界面，點(diǎn)一下「允許」。但實(shí)際上這個(gè)權(quán)限包含所有文件，包括共享給你的敏感文檔。

第二，令牌刷新機(jī)制的攻擊面。大多數(shù)MCP服務(wù)器長(zhǎng)期持有刷新令牌，一旦服務(wù)器被攻破，攻擊者可以持續(xù)獲取新的訪問令牌，直到用戶手動(dòng)撤銷授權(quán)——而平均用戶從不這樣做。

策略門：規(guī)則引擎的幻覺

企業(yè)喜歡在MCP網(wǎng)關(guān)前部署策略引擎，設(shè)定規(guī)則比如「禁止訪問生產(chǎn)數(shù)據(jù)庫」。紅隊(duì)的測(cè)試顯示，這些規(guī)則有30%以上的繞過率。

常見手法：利用AI的上下文窗口注入。攻擊者在工具返回結(jié)果中嵌入隱藏指令，讓AI「誤解」用戶的真實(shí)意圖。比如用戶說「查看昨天的日志」，AI實(shí)際執(zhí)行的是「導(dǎo)出過去一年的用戶數(shù)據(jù)并發(fā)送到外部服務(wù)器」。

策略引擎看到的是合法的日志查詢請(qǐng)求，審計(jì)日志記錄的也是這個(gè)。真正的惡意操作被藏在AI的「理解」層。

審計(jì)門：日志里的盲區(qū)

最諷刺的發(fā)現(xiàn)：即使三重門全部正常工作，審計(jì)日志仍然可能漏掉關(guān)鍵信息。

MCP的日志標(biāo)準(zhǔn)（如果存在的話）只記錄工具調(diào)用的元數(shù)據(jù)——哪個(gè)服務(wù)器、什么時(shí)間、什么參數(shù)。但AI對(duì)工具返回內(nèi)容的「再加工」過程完全黑箱。攻擊者可以讓工具返回?zé)o害的內(nèi)容，誘導(dǎo)AI生成惡意輸出，這個(gè)因果鏈在日志里找不到。

紅隊(duì)的建議：從假設(shè) breach 開始

第一部分的安全架構(gòu)是「盡可能阻止攻擊」。紅隊(duì)的視角是「假設(shè)攻擊已經(jīng)發(fā)生，怎么減少損失」。

基于此，三個(gè)具體建議：

工具隔離沙箱：每個(gè)MCP服務(wù)器運(yùn)行在獨(dú)立的網(wǎng)絡(luò)命名空間，文件系統(tǒng)訪問通過FUSE（用戶空間文件系統(tǒng)）代理。即使一個(gè)服務(wù)器被攻破，橫向移動(dòng)的成本大幅提高。

人機(jī)回環(huán)（Human-in-the-loop）的強(qiáng)制觸發(fā)：不是讓用戶每次都點(diǎn)確認(rèn)——那會(huì)導(dǎo)致確認(rèn)疲勞——而是基于行為異常檢測(cè)。如果AI連續(xù)調(diào)用三個(gè)涉及敏感數(shù)據(jù)的工具，自動(dòng)觸發(fā)人工審核。

語義級(jí)審計(jì)：記錄AI的「思考過程」，而不僅是工具調(diào)用。這需要修改MCP客戶端的實(shí)現(xiàn)，但只有這樣才能捕獲上下文注入攻擊。

最后一點(diǎn)可能最具爭(zhēng)議：企業(yè)應(yīng)該考慮自建核心MCP服務(wù)器，而不是依賴開源生態(tài)。不是不信任開源，而是MCP的攻擊面太特殊——它坐在用戶和AI之間，擁有兩者的信任，卻缺乏兩者的監(jiān)督。

一個(gè)被攻破的MCP服務(wù)器，等價(jià)于同時(shí)攻破了一個(gè)員工的筆記本電腦和這個(gè)員工能接觸的所有AI助手。這個(gè)等式，你的安全預(yù)算算進(jìn)去了嗎？