Forcepoint X-Labs 5 月 18 日揭露了一起針對 LiteLLM 的供應鏈攻擊。LiteLLM 是一個開源 Python gateway,作為 100+ LLM 供應商的統一介面。威脅組 TeamPCP 毒化了 PyPI 上的 1.82.7 和 1.82.8 兩個 release。攻擊鏈沒有直接攻破 LiteLLM 的原始碼倉庫 —— 反之,TeamPCP 毒化了 Trivy(LiteLLM 在建置流水線裡用的漏洞掃描器),冒充 Trivy 維護者,觸發自動化的 release 流程,從而散布被植入後門的 Trivy 二進位。當 LiteLLM 的 CI/CD 拉取了被污染的 Trivy 建置,這個後門從 runner 記憶體裡抓取並外傳了一個 PYPI_PUBLISH token。攻擊者用這個 token 直接發布了惡意的 LiteLLM release。揭露者是 Forcepoint X-Labs 的 Prashant Kumar。
兩個版本的 payload 行為不一樣。1.82.7 在 proxy_server.py 裡用 Base64 編碼的 payload,在 proxy 啟動時執行 —— 誰去 diff 一下檔案就比較容易發現。1.82.8 更隱蔽:它在 site-packages 裡放了一個 litelllm_init.pth 檔案,「在每一個後續的 Python 直譯器啟動時啟用,不管 LiteLLM 有沒有被顯式 import 過」。這是關鍵升級 —— 一旦裝上,在那個環境裡任何 Python 直譯器一開,後門就會跑,不一定要用到 LiteLLM。被針對的憑證:OpenAI、Anthropic、Microsoft Azure 的 API key;AWS、Google Cloud、Azure SDK 的憑證;以及使用者家目錄裡的 kubeconfig 和 AWS credential 檔案。外傳走的是 AES-256-CBC 加密,32 byte session key,透過 curl 發到 models.litellm.cloud。一個叫 Sysmon.py 的持久化模組每 50 分鐘向 checkmarx.zone 輪詢新指令。
架構層面的教訓是「信任鏈劫持」。TeamPCP 沒去攻擊防得很嚴的 LiteLLM 倉庫;他們攻擊的是 Trivy —— LiteLLM 建置流程預設信任的東西。這跟 xz-utils(那場差點搞掉 systemd 的 maintainer 冒充)和今年稍早的 npm tj-actions 攻擊是同一類供應鏈攻擊。你建置流程裡的任何工具 —— 掃描器、formatter、相依性解析器、linter —— 都是一個潛在的攻擊面,哪怕它的本職工作就是安全。LiteLLM 這次的被搞特別嚴重,因為 LiteLLM 的整個 value proposition 就是「每一個主流 LLM 供應商的統一 gateway」。Prashant Kumar 的原話:「LiteLLM 作為主流 AI 供應商的統一 gateway,意味著一次被搞,攻擊者就同時拿到 OpenAI、Anthropic 和 Azure 的憑證。」如果你裝過 1.82.7 或 1.82.8,那個環境碰過的每一個 provider 憑證,都可能已經在 TeamPCP 手裡。
週一上手:如果你有任何環境跑過 LiteLLM 1.82.7 或 1.82.8,把那個環境碰過的每一個 API key 都當作已經被洩漏 —— 立刻輪換 OpenAI、Anthropic、Azure、AWS、GCP 的 key,稽核用量日誌看有沒有陌生請求。檢查 site-packages 裡有沒有 litelllm_init.pth 檔案,以及 Sysmon.py 持久化模組。在網路層屏蔽到 models.litellm.cloud 和 checkmarx.zone 的出站,直到你把 host 清乾淨。從此往後建置流水線上:把 Trivy 和其它每一個建置工具的相依pin 到已驗證的 hash(不只是版本),對安全相鄰類的 tooling 要求簽名 release,隔離 PyPI publish token 讓建置期的掃描器拿不到。Forcepoint 的 writeup 沒揭露確切時間軸、下載次數、或 BerriAI 的回應 —— 這些空白讓人沒辦法精確估暴露面。在 BerriAI 出一份協調揭露之前,按最壞情況處理。