對於許多開發者來說，安裝 VS Code 擴充功能（Extensions）已經變成一種直覺反應，只要看到功能符合需求且名稱看起來像官方或知名工具，就傾向於直接安裝。然而，近期在 Open VSX（一個開源的 VS Code 擴充功能套件庫）發現的一起安全事件，提醒我們這種習慣潛藏著巨大的風險。
這次的攻擊採取了一種稱為 Evil Twin（邪惡雙生）的手法。簡單來說，攻擊者會複製現有合法擴充功能的名稱、命名空間（Namespace）以及功能描述，然後將這些偽裝成知名工具的惡意套件上傳到 Open VSX。
為什麼這種手法有效？因為開發者在搜尋工具時，很容易被熟悉的名稱誤導，而忽略了發行者帳號是否正確，或是版本號是否異常地低（例如 0.0.1）。
惡意擴充功能的運作機制
這些惡意套件完全不提供它們所宣稱的功能。安裝後，它們只會在狀態列顯示一個簡單的訊息告知已啟動，而真正的目的則隱藏在 bundled extension.js 檔案中。
攻擊者將資料竊取行為偽裝成匿名使用量統計（Anonymous usage metrics），以此降低開發者的警覺心。根據安全研究人員的分析，這 77 個惡意套件可分為兩類：
第一類是輕量級工具。這類套件主要收集基本的系統資訊，例如主機名稱（Hostname）、工作區資料夾名稱或編輯器版本。
第二類是深度偵察工具。這類套件會收集極其詳細的開發環境資訊，包括作業系統使用者名稱、機器 ID、時區、完整的檔案系統路徑，甚至會掃描 .git 目錄以獲取 Git 遠端主機、組織名稱、開發者電子郵件域名以及目前的分支與 Commit SHA hash。
更危險的是，這些偵察工具會偵測開發者是否處於 CI（持續整合，Continuous Integration）環境中。它們會嘗試提取 GITHUB_REPOSITORY、Azure DevOps URI 或 CircleCI 專案名稱等環境變數。這意味著攻擊者的目標不僅是個人電腦，還包括企業的自動化構建管線。
對抗防禦的持久化策略
這次攻擊最值得關注的是其高度的持久性與對抗性。惡意代碼內建了多重備案：
首先是 DNS 備援機制。如果主伺服器被封鎖，套件會查詢 DNS TXT 紀錄以獲取新的資料傳輸網址。
其次是重試機制。如果機器處於離線狀態或被防火牆擋住，套件不會放棄，而是在 15 分鐘、50 分鐘、3.5 小時後再次嘗試，隨後每 7 到 8 小時嘗試一次，直到安裝後的一週為止。
最後，它會檢查 devcontainer.json 或 extensions.json 檔案。這讓攻擊者能區分該套件是由開發者手動安裝，還是透過專案配置自動安裝。這對於攻擊者分析其散佈路徑（Distribution Path）至關重要。
軟體供應鏈攻擊的整體趨勢
這次 Open VSX 的事件並非孤立現象，而是更廣泛的軟體供應鏈攻擊（Software Supply Chain Attack）的一部分。與此同時，npm 生態系也遭遇了名為 ChainDrop 的攻擊，大量套件被植入 Mini Shai-Hulud 變種蠕蟲，利用 preinstall 鉤子（Hook）在安裝完成前就執行惡意代碼，甚至透過竊取的 GitHub 憑證將惡意配置注入到其他儲存庫中。
這顯示出目前的開發生態系存在一個核心漏洞：我們過度信任套件管理器的安裝過程。目前的 npm 或擴充功能安裝機制，往往在缺乏細粒度權限控制（Granular Permission Control）的情況下，就賦予了套件存取環境變數、讀取檔案系統或發送網路請求的權限。
給開發者的實務建議
面對這類攻擊，僅僅依賴二階段驗證（2FA）或封鎖安裝腳本是不夠的。建議採取以下習慣：
核對發行者資訊。安裝擴充功能前，請務必確認發行者的身分，而非僅看名稱。
警惕低版本號。如果一個知名工具的版本號突然變回 0.0.1，這是一個強烈的危險信號。
最小化權限環境。在 CI/CD 環境中，應嚴格限制環境變數的暴露範圍，避免將敏感的 Token 或金鑰直接放置在容易被讀取的全局環境中。
監控異常網路流量。對於開發機而言，不應有大量未知的對外連線，特別是向陌生域名傳送系統資訊的行為。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。