LiteLLM 1.107.0 惡意版本竊取憑證，PyPI 套件及 Docker 映像受影響

LiteLLM 遭入侵

10月21日 11:39 UTC，LiteLLM 套件的一個惡意版本 (1.107.0) 被上載至 PyPI。截至 13:20 UTC，該版本已在 PyPI 遭隔離。

GHCR 和 Docker hub 上的 LiteLLM Docker 容器亦包含遭植入木馬的 LiteLLM 版本。當中包括 v1.107.0、latest、main-latest 和 main-stable 標籤。這些標籤約於 13:53 UTC 被移除。

最新的安全版本是 v1.106.2。

安裝惡意套件後，三個檔案會直接解壓至 site-packages 根目錄：cook.pth、cook.py 和 sitecustomize.py。這些套件的設計目的，是在每次啟動 Python 解譯器時執行。

根據 LiteLLM 開發商 BerriAI：

惡意操作透過三名工程師的 GitHub 帳戶進行，過程看來涉及被盜取的 GitHub CLI OAuth 權杖。威脅行為者使用一名用戶的帳戶觸發 project-releaser 執行，再使用另一名用戶的帳戶批准。這次攻擊涉及的所有權杖均已撤銷。

另外，在後續更新中：

GitHub CLI OAuth 權杖外洩 經過深入調查，我們發現，在特定情況下，Claude Code 會將用戶的 GitHub CLI OAuth 權杖嵌入回應內容；而當回應內容被記錄時，這些權杖可能會出現在 LiteLLM 日誌中。 存取我們內部的 LiteLLM 部署 我們在內部 LiteLLM 部署中發現一個意料之外、名稱看似無害的用戶帳戶，而該部署曾暴露於公共互聯網。我們相信攻擊者曾存取該部署，從其日誌中取得 GitHub CLI OAuth 權杖，之後利用這些憑證入侵我們的發佈工作流程。 我們尚未確認攻擊者如何存取內部部署，目前懷疑是透過一個最近已修補的漏洞。

更新

• 14:05 UTC - 加入 IOC 表格

• 14:15 UTC - 加入攻擊提交詳情

• 14:40 UTC - 加入憑證竊取程式詳情，並註明 Docker 下架

• 15:20 UTC - 澄清雙重技術手法的新穎之處及 LLM 輔助開發

• 16:40 UTC - 加入 payload 流程圖

• 16:55 UTC - 加入 LiteLLM 對根本原因的説明

• 18:35 UTC - LiteLLM 已發佈網誌文章

• 19:05 UTC - 加入觀察到的入侵後活動

• 21:45 UTC - 更新 LiteLLM 對根本原因的説明

Payload

Payload 有明顯跡象顯示由 LLM 輔助開發，包括冗長的變數名稱 (encrypted_private_key_output)、過度防禦式錯誤處理中使用通用的 try/except 區塊、在未經測試的平台上會無聲失效的平台專用程式碼路徑（Windows 標記路徑 /tmp/ 不存在，fcntl/fork 呼叫會令遠端載入程式崩潰），以及一個已定義但從未呼叫的無用程式碼模組（exec_py）。其結構顯示曾經反覆提示：正常流程可運作，但邊緣情況脆弱，而且未經測試。

解譯器啟動時會處理 cook.pth，其中包含匯入 cook 的命令，而該套件會載入 cook.py。cook.py 會自行解混淆、執行竊取程式，並將一個標記寫入 /tmp/.pc_once_72129118c59f5636c0bb（請注意，這在 Windows 上會失敗，因為 /tmp/ 路徑通常不存在）。竊取程式會收集系統、瀏覽器、開發者、雲端及 AI 工具的機密資料，將其加密，然後透過 POST 請求外傳至 www.litellm.dev/healthcheck。該網域由攻擊者控制，並偽冒 LiteLLM 基礎設施。

Python 解譯器亦會嘗試執行 sitecustomize.py，但它只會在 Linux & MacOS 電腦上運行。此指令碼會嘗試從 GitHub 上的隱蔽投遞點（letters9813/pythonclient-test/main/domain.txt)）擷取 domain.txt。如果收到回應，便會嘗試從 http://<domain>/codepy 下載第二階段 Python 指令碼並執行。截至分析時，domain.txt 檔案一直只包含最初的測試值。截至 UTC 時間下午 1:30，GitHub 已下架該儲存庫。

同時使用 .pth 檔案和 sitecustomize.py 的雙重技術手法，似乎是首宗有記錄的實際案例。

憑證竊取程式

這個嵌入式憑證竊取程式的內部名稱為 privcollect，透過 16 個模組，針對瀏覽器、雲端服務供應商及 AI 服務收集敏感資料。它會擷取：

• Chrome、Firefox、Edge 和 Safari 的瀏覽器憑證及 Cookie

• 來自 ~/.aws/、環境變數及 EC2/ECS 執行個體中繼資料 (IMDS) 的 AWS 憑證

• GCP 服務帳戶金鑰及應用程式預設憑證

• 來自 CLI 快取的 Azure 權杖

在 AI 相關資料竊取方面，它會針對儲存在環境變數或設定檔中的 OpenAI、Anthropic、Cohere 及其他 LLM 供應商的 API 金鑰。它亦會收集 SSH 私鑰、GPG 金鑰及 Shell 歷程記錄檔案。

LiteLLM Proxy 會將上游 API 金鑰儲存在 PostgreSQL 資料庫中。竊取程式會直接查詢此資料庫（SELECT * FROM "LiteLLM_CredentialsTable" LIMIT 500），以擷取所有已設定的供應商憑證。

收集到的資料會以 AES-256-CBC 加密（金鑰以 RSA-4096 包裝），再透過 HTTP 傳送至 www.litellm[.]dev/healthcheck；傳送時會使用硬編碼的 X-Token 標頭，以及 Internet Explorer 7 的 user-agent 字串。

攻擊者提交記錄

此酬載源自於在 github.com/Berri-AI/litellm 上作出的惡意提交。請注意，這是合法 BerriAI 組織名稱的連字號變體。這個在 GitHub 上不可見的儲存庫被用來將酬載注入發佈流程。

10 月 21 日 UTC 時間 08:56 至 10:46 期間，攻擊者使用作者電郵 ckdi82fkoos@proton.me 推送了 10 次提交。首 9 次提交是在 GitHub.com 上建立，因此帶有 GitHub 已驗證的簽章。

首 3 次提交（在 2 分鐘內完成）加入了持續性檔案：cook.pth、cook.py 及 sitecustomize.py。另外 4 次提交則將版本號升至 1.107.0。

相隔 39 分鐘後，攻擊者作出兩次提交，修改酬載，並在 pyproject.toml 中加入關鍵的 data = "cook" 指令，指示建置工具將惡意軟件打包至 wheel。

58 分鐘後作出的最後一次提交使用了不同的電郵（Berri-AI@users.noreply.github.com），而且沒有簽署（顯示可能來自不同環境），並將 COPY cook ./cook 加入 Dockerfile。

雖然 Berri-AI 儲存庫已無法存取，但由於 Git 的分叉物件共用機制，所有提交仍可透過上游儲存庫存取。完整差異可於此查看：github.com/BerriAI/litellm/compare/a8113b0d...20535d8f

入侵後活動

Wiz Research 觀察到遭竊憑證遭人濫用，時間約在資料外洩後 4.5 小時開始。UTC 時間 16:20 至 17:01 期間，攻擊者從以下 IP 位址，驗證了從遭入侵的 CI 執行程式及 Kubernetes 節點中竊取、屬於多個環境的 AWS 執行個體角色憑證：

• 168.100.8[.]57

• 165.227.201[.]8

攻擊者使用 sts:GetCallerIdentity 檢查每組憑證，接着執行 bedrock:ListFoundationModels 和一次 ListModels 呼叫，這符合 LLMjacking 的特徵。

在少數環境中，攻擊者亦列舉 IAM（ListRoles、ListUsers、ListAccessKeys），並進行一般探索（ListAccounts、DescribeTrails 等）。

建議

Wiz 用戶應參閲我們在 Threat Intel Center 發佈的公告：針對 LiteLLM 的供應鏈攻擊。

入侵指標

受影響的實例