Fork Bomb 拯救了我們

LiteLLM 1.82.8 中的惡意軟體包含一個 .pth 檔案，會在任何 Python 啟動時執行。它蒐集 SSH 金鑰、雲端憑證、加密貨幣錢包及 CI/CD 密鑰，以 4096 位元 RSA 金鑰加密後，將封存檔外傳至攻擊者控制的網域。酬載工程精良，加密無懈可擊，資料外傳手法乾淨俐落。¹ 本文屬於我的代理程式安全系列，探討那些真實世界的失敗案例如何形塑我們在自動化系統中建立信任的方式。

.pth 檔案同時會產生一個子 Python 程序來執行工作。該子程序再次觸發 .pth 檔案，又產生另一個子程序，如此反覆。指數級的 fork bomb 在數秒內就耗盡 100% CPU 與超過 5 GB 記憶體。²

Fork bomb 是個 bug。攻擊者並不希望惡意軟體被察覺。若實作正確，它會在每個受感染系統的每次 Python 呼叫中靜默運行，可能長達數週。結果卻是開發者發現機器瀕臨癱瘓、著手調查後找到了憑證竊取程式。PyPI 在發布後 46 分鐘內隔離了兩個版本。¹

四萬六千次安裝，四十六分鐘。偵測機制竟是惡意軟體中的一個實作錯誤。

重點摘要

• Bug 所在：LiteLLM 1.82.8 的憑證竊取程式帶有 fork bomb 缺陷，導致受感染的機器陷入停滯。若沒有這個 bug，竊取程式將靜默運行數週之久。
• 防線缺口：靜態分析、行為監控、程式碼審查全數未能攔截此攻擊。每一層偵測都假設另一層會攔截問題，結果無一層做到。³
• 攻擊品質曲線：攻擊者的能力隨迭代而精進。.pth 技術現已公開記錄，下一個攻擊者將繼承此技術，卻不會重蹈同樣的覆轍。
• 不依賴運氣的防禦：對外連線的網域年齡檢查、套件安裝的行為基線分析、檔案系統蜜罐、安裝環境隔離——每一項都不需要酬載本身出錯就能發揮作用。
• 不對稱優勢：防禦方掌握環境的選擇權。若安裝環境中無可竊取的憑證，即使完美的酬載也一無所獲。

我們只是運氣好

拿掉 fork bomb，攻擊便能靜默得逞。.pth 檔案在任何 import 之前、任何應用程式碼之前、任何 Python 層級沙箱之前就已執行。沒有攔截點，沒有日誌記錄。憑證竊取程式執行、加密、外傳，Python 程序照常運作。開發者毫無察覺、CI 流程毫無察覺、資安掃描器也毫無察覺——因為資安掃描器本身正是攻擊載體。³

LiteLLM 1.82.8 的偵測經過並非「我們的監控成功攔截」，而是「攻擊者出貨時帶了一個 bug」。

這不是供應鏈安全的穩固基石。正如我在你的代理程式沙箱只是個建議中所論述的，我們假設存在於受信任與不受信任程式碼之間的邊界，遠比多數團隊所想的更加脆弱。

攻擊者品質曲線

軟體品質隨迭代而提升——攻擊者亦然。TeamPCP 的行動在一週內攻擊了五個生態系統：GitHub Actions、Docker Hub、npm、Open VSX 和 PyPI。⁴ 每個生態系統的入侵都利用了前一次竊取的憑證。該行動展現出高度的作戰成熟度：酬載投放前 24 小時註冊網域、針對可變參照進行標籤劫持、利用 Aqua Security 不完整的金鑰更換來規避憑證輪換機制。

Fork bomb 是一場原本精密行動中的唯一失誤。下一次行動不會再犯同樣的錯。.pth 技術已被 CrowdStrike、Microsoft、Wiz 和 Palo Alto 公開分析記錄。³ 下一個攻擊者繼承的是技術本身，而非 bug。

攻擊能力與防禦能力遵循同一條進化曲線。技術公開了，分析也公開了，下一個攻擊者從 TeamPCP 的終點起步。我在真正讓無監督系統崩潰的是什麼中進一步探討了這條曲線對自主系統的意義。

偵測不能依賴攻擊者的失誤

現行的供應鏈偵測模型有三層防線，三層在 LiteLLM 事件中全數失守：

靜態分析未能攔截。 .pth 檔案是 Python 的合法功能。酬載經過雙層 base64 編碼，在執行時才解碼。尋找已知惡意模式的靜態掃描器一無所獲，因為這是全新的模式。

行為監控未能攔截。 憑證竊取程式僅對一個外觀像合法服務的網域（models.litellm.cloud）發出一次 HTTPS POST 請求。出口監控若要透過目標網域名稱偵測，必須知道這個特定網域是 24 小時前才註冊的。大多數出口監控並不檢查網域年齡。

程式碼審查未能攔截。 惡意版本直接發布至 PyPI，完全繞過了 GitHub CI/CD 流程。沒有 pull request 可供審查，沒有 diff 可供檢視。攻擊者使用竊取的發布憑證上傳了預建好的套件。

每一層偵測都假設攻擊鏈的其他環節會攔截問題，結果無一層做到。最終攔截問題的是 fork bomb。

真正能偵測靜默惡意軟體的方法

既然無法依賴攻擊者的失誤，就需要不論酬載品質如何都能運作的偵測機制。

對外連線的網域年齡檢查。 外傳網域在攻擊前 24 小時才註冊。一條防火牆規則——標記所有連往註冊不足 7 天網域的外部請求——就能攔截此攻擊。規則簡單，誤報率可控，且能捕捉最常見的資料外傳模式。

Python 程序的行為基線分析。 pip install 突然向未知網域發出 HTTPS POST 請求，這是異常行為。在套件安裝期間追蹤網路活動的程序層級行為監控能標記此類異常。

檔案系統蜜罐。 在蜜罐路徑放置偽造的 SSH 金鑰，在另一個蜜罐路徑放置偽造的 AWS 憑證，監控任何讀取這些檔案的程序。掃描標準路徑的憑證竊取程式會讀到蜜罐，合法程序則不會。蜜罐在資料外傳完成之前就觸發警報。

安裝環境隔離。 在無法存取真實憑證的環境中執行 pip install，之後再將已安裝的套件複製到正式環境。.pth 檔案在 pip 自身的 Python 程序中觸發，意味著憑證竊取程式在安裝階段就會執行。若安裝環境中沒有可竊取的憑證，攻擊便一無所獲。

以上機制無一需要攻擊者犯錯，不論酬載品質如何都能有效運作。「設計一個即使遭受完美攻擊也無從收穫的環境」——這一架構原則，與部署與防禦：代理程式信任悖論所闡述的理念如出一轍。

不對稱優勢

防禦方擁有一個結構性優勢：環境由防禦方選擇。攻擊者必須在套件實際安裝的環境中運作。若該環境沒有憑證、沒有網路存取權限，且佈有檔案系統蜜罐，酬載在技術上成功執行，在實務上卻徹底失敗。

LiteLLM 攻擊之所以得手，是因為安裝環境同時存放了發布憑證、SSH 金鑰和雲端權杖。Fork bomb 與安全架構無關，但與偵測時程密切相關。

下一次，fork bomb 不會再出現。憑證仍然會與套件管理器同處一個環境。問題在於：在下一個攻擊者推出乾淨酬載之前，您是否已經改變了環境？我在 Ralph 代理程式架構分析中展示了如何建構代理程式系統，使受損元件無法突破其隔離邊界進行提權。

常見問題

攻擊者為何沒有測試到 fork bomb？

.pth 檔案產生子程序來執行酬載、避免阻塞父程序，是合理的實作選擇。遞迴觸發源自 .pth 與 Python site.py 初始化之間的微妙交互作用。這類 bug 通常在整合測試中才會浮現，單元測試難以捕捉，而惡意軟體作者在實際環境中進行整合測試的機會極為有限。

Fork bomb 有可能是刻意為之嗎？

可能性極低。Fork bomb 使惡意軟體立即曝光，與攻擊者的目標背道而馳。一個靜默運行數週的憑證竊取程式，所能竊取的憑證量級遠超在 46 分鐘內就被偵測到的版本。

網域年齡檢查在大規模環境中可行嗎？

可行。網域年齡可透過 WHOIS 或 DNS 註冊日期 APIs 取得，每次請求僅增加毫秒級延遲。大多數組織都能為已知的新網域建立白名單。

參考資料