成千上萬的公司依賴 Ray 框架來擴展和管理複雜且計算密集型的 AI 工作負載。事實上,很難找到未使用 Ray 開發的大型語言模型(LLM)。然而,這些工作負載常常包含敏感數據,因此研究人員指出,由於開源統一計算框架中的一個關鍵安全漏洞(CVE),這些數據容易受到攻擊者的威脅。
根據 Oligo Security 的研究,在過去七個月中,這一漏洞使攻擊者能夠利用 AI 生產工作負載,獲取計算能力、憑證、密碼、密鑰、令牌及其他多種敏感信息。這一漏洞被稱為「ShadowRay」,目前仍存在爭議。它被歸類為「影子漏洞」,即未被識別為威脅,且缺乏官方修補。因此,它不會顯示在標準掃描過程中。
這一情況標誌著「首例 AI 工作負載因當前 AI 基礎設施的漏洞而被積極利用」,研究人員 Avi Lumelsky、Guy Kaplan 和 Gal Elbaz 表示:「當攻擊者進入 Ray 生產集群時,就是一次豐收。寶貴的公司數據與遠程代碼執行的結合創造了獲利機會,而一切行為都未被察覺。」
重大盲點
許多組織依賴 Ray 進行大規模 AI、數據和 SaaS 工作負載,包括 Amazon、Instacart、Shopify、LinkedIn 和 OpenAI,後者的 GPT-3 模型即是透過 Ray 訓練的。該框架對於需要大量計算能力並無法在單一機器上執行的數十億參數模型至關重要。由 Anyscale 維護的 Ray 支援訓練、服務和調整各種 AI 模型的分布式工作負載。用戶不需要廣泛的 Python 知識,安裝過程也簡單,依賴性極低。
Oligo 研究人員稱 Ray 為「Pythonista 與 AI 實踐者的瑞士軍刀」。儘管擁有優勢,ShadowRay 漏洞使對 Ray 的依賴更加令人擔憂。這一漏洞被標識為 CVE-2023-48022,主要因 Ray Jobs API 的授權不足,暴露於遠程代碼執行攻擊之下。任何可以訪問儀表板的人都可以在未經授權的情況下執行任意工作。
儘管這一漏洞於 2023 年底與其他四個漏洞一起報告給 Anyscale,但唯一未被處理的就是 CVE-2023-48022。Anyscale 對該漏洞表示異議,聲稱它代表了預期行為和一項產品功能,該功能促進了作業觸發和集群中動態代碼執行。
Anyscale 聲明,儀表板不應公開訪問,或應限制給可信用戶,因此 Ray 缺乏授權,因為它假設在具有「適當路由邏輯」的安全環境中運作,這通過網絡隔離、Kubernetes 名稱空間、防火牆規則或安全組來實現。這一決策體現了「在軟件開發中平衡安全與可用性的複雜性」,Oligo 研究人員指出,強調在修改像 Ray 這樣的關鍵系統時需要謹慎考慮。
此外,由於爭議性漏洞往往逃避檢測,許多安全掃描器可能會忽略它們。Oligo 研究人員發現,ShadowRay 並未出現在多個數據庫中,包括 Google 的開源漏洞數據庫(OSV),也未在靜態應用安全測試(SAST)和軟件組成分析(SCA)解決方案中顯示。
「這創造了一個盲點:安全團隊對潛在風險毫不知情。」研究人員強調,「AI 專家並非安全專家,這使他們容易受到 AI 框架帶來的風險影響。」
從生產工作負載到關鍵令牌
研究人員揭示,受損服務器泄露了一批敏感信息,包括:
- 中斷 AI 生產工作負載,導致在訓練過程中模型的完整性或準確性受損。
- 獲得敏感的雲環境(AWS、GCP、Azure),可能暴露客戶數據庫及敏感生產數據。
- 訪問 Kubernetes API,使雲工作負載遭受感染或提取 Kubernetes 密碼。
- 許多平台(如 OpenAI、Stripe 和 Slack)的敏感憑證。
- 數據庫憑證,允許靜默下載或修改完整的數據庫。
- 用於訪問額外機器的私有 SSH 密鑰,用於惡意活動。
- OpenAI 令牌,可能導致賬戶信用的消耗。
- Hugging Face 令牌,提供訪問私有庫的權限,助長供應鏈攻擊。
- Stripe 令牌,可能被用來耗盡支付賬戶。
- Slack 令牌,可能被用於未經授權的消息發送或閱讀。
研究人員報告,目前許多受損的 GPU 供應緊張且價格昂貴。他們已發現數以百計的受損集群,主要用於加密貨幣挖礦。「攻擊者針對這些系統,不僅因為有價值的信息,更因為 GPU 昂貴且難以獲得,尤其是在當今時代。」研究人員指出,在 AWS 上,某些 GPU 按需定價每年可達 858,480 美元。
隨著攻擊者有七個月的時間來利用這些硬件,估計受損的機器和計算能力的總價值可能高達 10 億美元。
應對影子漏洞
Oligo 研究人員承認「影子漏洞將始終存在」,且利用的指標可能會有所不同。他們建議組織採取幾個措施:
- 在安全和可信的環境中運行 Ray。
- 實施防火牆規則和安全組以防止未經授權的訪問。
- 持續監控 AI 集群和生產環境以發現異常。
- 如果 Ray 儀表板需要公開訪問,則使用代理添加授權層。
- 永遠不要假設默認安全性足夠。
他們強調:「保障開源安全的技術負擔落在你肩上。不要僅依賴維護者。」