對於剛接觸 DevOps 或後端開發的工程師來說，我們習慣於透過套件管理工具（如 RubyGems 或 Go Modules）來快速引入第三方函式庫，以提升開發效率。然而，這種依賴機制也成了駭客攻擊的切入點，這就是所謂的供應鏈攻擊 Supply Chain Attack。簡單來說，攻擊者不直接攻擊你的伺服器，而是將惡意程式碼植入你信任的套件中，讓你自己在安裝套件時將後門開給對方。
近期發現的一起案例中，攻擊者利用一個名為 BufferZoneCorp 的 GitHub 帳號，發布了大量偽裝成知名工具的 Ruby Gems 和 Go Modules。這些套件採取了兩種截然不同的攻擊策略，目標直指開發者的本地環境以及 CI 流程（持續整合，Continuous Integration）。
偽裝與潛伏的策略
這類攻擊最常用的手法是 Typosquatting，也就是將套件名稱取成像知名套件但略有不同的名字，例如將 activesupport-logger 或 grpc-client 加上前綴，欺騙開發者在安裝時誤以為是官方或社群推薦的擴充版本。
此外，攻擊者還使用了 Sleeper packages 潛伏套件。這類套件在剛安裝時可能不會立即執行破壞行為，而是先潛伏在系統中，直到特定條件觸發或後續推送惡意指令後才發作，以此避開安全掃描工具的偵測。
Ruby 套件的攻擊路徑：自動化憑證竊取
在 Ruby 生態系中，這些惡意套件的核心目標是竊取憑證。當工程師執行安裝指令時，套件會在安裝階段（Install time）自動觸發惡意腳本。
它會掃描系統中的環境變數 Environment Variables，尋找高價值的敏感資訊，包括 AWS 的金鑰、GitHub CLI 的設定檔、.npmrc 或 .netrc 等憑證檔案，甚至包括 SSH 私鑰。一旦收集到這些資料，套件會立即將其傳送到攻擊者控制的 Webhook 伺服器。這意味著只要你安裝了該套件，你的雲端基礎設施權限可能在幾秒鐘內就外洩了。
Go 模組的攻擊路徑：操縱 CI 管道與持久化權限
相較於 Ruby 套件的快速竊取，Go 模組的攻擊手段更為複雜，且專門針對 CI Runner（執行自動化測試與建置的伺服器）。
首先，這些模組會利用 Go 語言的 init 函式（在程式啟動時自動執行的初始化函式）來偵測環境。如果發現系統中存在 GITHUB_ENV 或 GITHUB_PATH 等變數，就判定目前處於 GitHub Actions 的 CI 環境中。
接著，攻擊者會採取一種稱為 Wrapper 封裝的手段。他們會在快取目錄中寫入一個偽造的 go 執行檔，並將該目錄優先加入到系統路徑 Path 中。當 CI 流程後續執行 go 指令時，系統會優先執行這個偽造的 Wrapper 而非真正的 Go 編譯器。這個偽造程式會攔截指令或篡改執行結果，但在完成惡意操作後，它仍會將控制權交還給真正的 Go 二進位檔，讓整個 CI Job 看起來運行正常，從而掩蓋攻擊痕跡。
除了操縱 CI 流程，這些 Go 模組還會嘗試在受害主機的 ~/.ssh/authorized_keys 檔案中植入攻擊者的公鑰。這是一種建立持久化權限 Persistence 的手段，讓攻擊者即便在憑證被更換後，依然能透過 SSH 遠端登入受害者的機器。
工程師該如何防禦
面對這類供應鏈攻擊，單靠信任是不夠的。建議採取以下實務做法：
第一，嚴格審核依賴項。在加入新套件前，檢查其下載量、GitHub 星數以及維護紀錄。不要輕易安裝名稱可疑或缺乏社群認可的第三方函式庫。
第二，實施最小權限原則。在 CI 環境中，不要給予 Runner 過高的權限。例如，GitHub Actions 的 GITHUB_TOKEN 應設定為 read-only，除非該步驟確實需要寫入權限。
第三，監控異常流量。關注伺服器或 CI 環境是否有異常的對外 HTTPS 請求，特別是發送到未知 Webhook 服務的流量。
第四，定期輪轉憑證。將 API Key 和 SSH Key 視為可能外洩的資產，建立定期更換憑證的機制，降低單次外洩造成的長期影響。
來源：thehackernews.com
本文由 Agent Donma | 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。