PyPI下載量40萬的AI工具包被投毒：裝完就偷密鑰

你的Python環(huán)境可能已經(jīng)被"寄生"了——不需要import，甚至不需要運行代碼，只要裝了一個包，所有密鑰自動外泄。

3月24日，開源項目LiteLLM的PyPI發(fā)布頁突然掛出紅色警報：1.82.8版本被植入惡意代碼。這個工具包在GitHub有4萬星標(biāo)，是開發(fā)者調(diào)用OpenAI、Claude等上百種大模型的"萬能轉(zhuǎn)接頭"。

攻擊者玩了一手供應(yīng)鏈投毒的教科書操作。他們把惡意腳本藏進.pth文件——這是Python解釋器啟動時自動執(zhí)行的"鉤子文件"。換句話說，用戶pip install完，下次開Python的瞬間，竊密程序就已經(jīng)跑完了。

攻擊路徑：一個你從未注意過的文件類型

LiteLLM的定位很清晰：讓開發(fā)者用同一套代碼切換不同AI模型。支持100+家API，從OpenAI到國產(chǎn)模型通吃。這種"中間件"屬性讓它成了AI開發(fā)者的基礎(chǔ)設(shè)施級依賴。

問題出在1.82.8版本的wheel包里多了一個litellm_init.pth，34628字節(jié)。這個文件被正常記錄在包的元數(shù)據(jù)里，hash校驗值齊全，看起來像是官方文件。

但內(nèi)容是這樣的：

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"])

雙層的base64編碼把真實載荷裹得嚴(yán)嚴(yán)實實。解碼后，腳本會打包當(dāng)前環(huán)境的全部敏感信息——環(huán)境變量、SSH密鑰、云服務(wù)商憑證——然后發(fā)往https://models.litellm.cloud/。

注意這個域名。LiteLLM官方是litellm.ai，攻擊者注冊了litellm.cloud，只差兩個字母。

為什么.pth文件成了完美攻擊面

Python的.pth機制設(shè)計初衷是解決模塊路徑問題。任何放在site-packages目錄下的.pth文件，解釋器啟動時會逐行執(zhí)行其中的Python代碼。

這個特性用了幾十年，但大多數(shù)開發(fā)者根本不知道它存在。安全掃描工具通常只檢查.py文件，.pth文件連語法高亮都沒有。

攻擊者精準(zhǔn)踩中了幾個盲區(qū)：

安裝即觸發(fā)，無需用戶調(diào)用任何API

載荷不落地為.py文件，繞開靜態(tài)分析

域名仿冒足夠像，TLS證書看起來正常

有用戶在GitHub issue下回復(fù)：「我只是在測試環(huán)境裝了一下，但生產(chǎn)環(huán)境的AWS密鑰是通過環(huán)境變量注入的，現(xiàn)在全沒了。」

供應(yīng)鏈攻擊的"低成本高收益"公式

這不是PyPI第一次被投毒，但攻擊手法在進化。2023年的類似案例多是 typosquatting（拼寫近似包名），需要用戶手滑輸錯才能中招。這次是直接劫持官方發(fā)布渠道。

LiteLLM的維護者BerriAI在issue中確認(rèn)：「我們?nèi)栽谡{(diào)查攻擊向量，初步判斷是PyPI發(fā)布流程的憑證泄露。」沒有承認(rèn)GitHub倉庫本身被入侵，意味著攻擊者可能只拿到了PyPI上傳密鑰。

這種"單點突破"模式越來越常見。維護者通常把PyPI憑證存在CI/CD環(huán)境里，而CI配置的安全水位往往低于主代碼庫。

被竊數(shù)據(jù)的去向也值得玩味。攻擊者沒有選暗網(wǎng)交易常用的加密貨幣錢包地址，而是搭了一個仿冒域名做C2服務(wù)器。這種"重基礎(chǔ)設(shè)施"投入說明要么是有組織的APT行為，要么是準(zhǔn)備長期運營這個竊密渠道。

開發(fā)者能做什么：不是"別用開源"這么簡單

事件曝光后，PyPI已經(jīng)下架1.82.8版本。但如果你在過去幾天執(zhí)行過pip install litellm，或者依賴自動更新機制，風(fēng)險窗口已經(jīng)打開。

檢查方法很直接：在你的Python環(huán)境里運行

python -c "import site; print(site.getsitepackages())"

然后查看該目錄下是否有l(wèi)itellm_init.pth。有則立即刪除，并輪換所有環(huán)境變量里的密鑰。

更根本的問題是：我們憑什么信任pip install？

Python社區(qū)有過簽名驗證機制（TUF），但 adoption 緩慢。大多數(shù)開發(fā)者不會手動校驗wheel包的hash，CI/CD流水線更不會。這次惡意文件的hash甚至被正常記錄在RECORD文件里——PyPI的完整性校驗只保證"和上傳時一致"，不保證"上傳者是本人"。

有安全工程師在討論區(qū)吐槽：「我們給Docker鏡像做SBOM（軟件物料清單），給npm包做審計，但Python生態(tài)的供應(yīng)鏈安全還停留在'相信維護者人品'階段。」

LiteLLM的GitHub倉庫目前仍顯示40.2k星標(biāo)，6.7k fork。這個數(shù)字不會因為這起事件下跌——工具太有用了，開發(fā)者沒有替代方案。但issue #24512已經(jīng)被置頂，標(biāo)題里的"CRITICAL"紅標(biāo)像一道傷疤。

維護者在最新回復(fù)里說：「我們正在與PyPI安全團隊協(xié)調(diào)，1.82.9版本已發(fā)布，移除了惡意文件。」沒有道歉，沒有追責(zé)承諾，只有一行版本號更新。開源維護的殘酷現(xiàn)實是：當(dāng)你在用愛發(fā)電時，攻擊者正在用自動化工具批量收割。