當AI不再是弱點：McHire 應徵者資料外洩事件

發生了什麼事

2025年6月，安全研究員 Ian Carroll 和 Sam Curry 披露了 McHire 的漏洞鏈。McHire 是由 Paradox.ai 建立的麥當勞招聘平台，被絕大多數麥當勞特許經營店使用。Wired 和 BleepingComputer 的公開報導指出，暴露的資料集約有6400萬名求職者，其姓名、電子郵件地址、電話號碼和聊天記錄，任何循著研究人員相同路徑的人都可以存取。

最快傳播的頭條新聞將此事件描述為對聊天機器人「Olivia」的提示注入攻擊。這種說法是錯誤的。研究人員表示，他們確實首先嘗試了提示注入，但失敗了：該機器人受到嚴格限制，只能提供預設回應，從未擁有可以被誘騙洩露的後端資料。這次洩露與語言模型無關。

實際的切入點是 McHire 上的一個 Paradox.ai 管理員登入頁面，可從公共網路存取。研究人員在一個測試帳戶上嘗試了「123456」/「123456」的憑證，根據公開報導，該帳戶自2019年以來一直處於活躍狀態。他們成功登入。

登入後，應徵者 API 上的經典不安全直接物件引用 (IDOR) 讓他們可以遞增數字 ID 並提取任何應徵者的記錄。沒有模型利用，沒有新技術，沒有零日漏洞。預設憑證加上未經身份驗證的物件引用。

為什麼這種模式不斷重複

這裡有趣的失敗不是技術性的，而是組織性的。聊天機器人是可見的「AI」組件，因此它吸引了安全注意力。它背後無聊的網路管理才是實際的爆炸半徑，幾乎沒有人從這個角度看待它。

當買家將 AI 供應商視為 AI 產品，而不是一個碰巧包含模型的 SaaS 應用程式時，就會發生這種情況。模型會進行紅隊審查。而管理控制台、應徵者 API、儲存桶、審計日誌、憑證輪換策略——這些有數十年已知故障模式的東西——卻被視為管道。

供應商的激勵結構強化了這一點。AI 供應商快速出貨，通常在他們擁有成熟的安全計畫之前，他們的客戶採購團隊會詢問模型行為，而不是周圍的應用程式。一個自2019年以來使用密碼「123456」的測試帳戶，因為沒有人將審查範圍設定為找到它，因此多年來一直存在這個漏洞。

未來兩年最昂貴的 AI 洩露事件不會是模型漏洞。它們將是圍繞模型的應用程式中，1990年代的網路漏洞。

攻擊者的逐步攻略

披露的序列很短，這就是令人不安的部分。熟練的攻擊者不需要一系列新穎的原始攻擊。

步驟1：列舉 AI 供應商的攻擊面

識別可見聊天機器人背後的第三方供應商。在這種情況下，機器人表明自己是由 Paradox.ai 建立的，這指向了一個獨立的管理介面——同一 McHire 網域上的登入頁面。

步驟2：嘗試常見憑證

預設和弱憑證仍然是對供應商管理面板最高效的攻擊。報導指出，一個帶有「123456」/「123456」的測試帳戶就足夠了。

步驟3：從管理員轉向資料

管理員角色暴露了一個內部應徵者 API。該 API 使用順序數字識別碼，並且沒有檢查呼叫帳戶是否被授權讀取每個特定的應徵者。迭代 ID 返回任意記錄。

步驟4：確認範圍並披露

研究人員止步於影響證明，驗證了資料集的大小，並向 Paradox.ai 和麥當勞報告。Paradox.ai 禁用了測試帳戶，據報導在披露後數小時內修復了 IDOR。

防禦者錯過了什麼

三件事，嚴重程度大致遞減。

首先，供應商管理介面上沒有憑證衛生。一個早於生產部署的測試帳戶，帶有六位數字密碼，在創建五年後仍可從公共網路存取。任何定期憑證審計都會發現它。

其次，應徵者 API 上沒有授權檢查。IDOR 是 OWASP 目錄中最古老、記錄最完善的網路漏洞之一。經過身份驗證的管理員呼叫返回任意應徵者記錄的事實意味著 API 強制執行了身份驗證，但沒有強制執行授權。

第三，對無聊的介面沒有進行安全審查。聊天機器人之所以受到關注，是因為它是 AI。管理員登入、API 閘道以及6400萬個人身份資訊記錄的儲存沒有受到同樣的審查——無論是在麥當勞、Paradox.ai，還是部署 McHire 的特許經營商。

實用的防禦清單

修復措施並不光鮮。但它們正是可以防止這次事件發生的措施。

• 清點您使用的任何 AI 供應商暴露的所有身份驗證介面，包括管理面板、測試環境和客戶支援工具。將它們視為珍貴的網路應用程式，而不是模型的管道。
• 要求供應商書面證明生產環境中不存在預設或共享憑證，並且在上線時刪除在入職期間創建的測試帳戶。
• 對供應商暴露的每個 API 運行經過身份驗證的 IDOR/BOLA 測試，尤其是返回每個用戶記錄的 API。OWASP API 安全十大排名將其列為第一，這是原因充分的。
• 強制對每個供應商管理介面使用您的身份提供者進行 SSO，這樣憑證就不會獨立漂移，並且當員工離職時，舊帳戶會失效。
• 限制管理員會話權限，這樣一個受損的管理員帳戶就無法枚舉整個應徵者或客戶資料集。
• 要求供應商記錄並警報針對敏感 API 的批量讀取模式。讀取數千萬條應徵者記錄不應該看起來像正常的一天。

現代攻擊性測試如何發現這個漏洞

針對 McHire 供應商介面——而不是聊天機器人——進行有範圍、經授權的攻擊性測試，會在第一個下午就發現這個漏洞。相關檢查是眾所周知的：針對管理員登入的憑證噴灑、針對每個參數化 API 的經過身份驗證的橫向存取控制，以及對測試帳戶和重置工作流程的審查。

在這個故事中，模型本身不需要紅隊。模型表現正常。聊天機器人的防護措施奏效了。教訓是，對包裝產品進行徹底的應用程式安全審查，會在殺傷鏈上線之前就標記出每個步驟。

接下來要關注什麼

預計會有更多類似事件發生。AI 供應商正在吸收更多敏感的工作流程——招聘、索賠、客戶服務、排程——而圍繞這些工作流程的後端管理控制台現在集中了以前存在於較難觸及系統中的受監管個人資料。

在您自己的計畫中，有兩件事需要關注：哪些 AI 供應商代表您持有最高濃度的受監管個人資料，以及您測試其管理介面的合約權利是什麼樣的。如果您無法對供應商的面板進行經過身份驗證的應用程式安全審查，那麼您就是在相信下一個測試帳戶已被刪除，下一個 API 強制執行授權，以及下一個預設密碼已被輪換。McHire 的披露顯示了這種信任被錯置時會發生什麼。