Glassworm 捲土重來:新一波不可見 Unicode 攻擊席捲數百個程式庫
Glassworm 威脅行為者發起了一場大規模的跨生態系統攻擊,利用不可見的 Unicode 字元將惡意負載隱藏在 GitHub、npm 和 VS Code 程式庫中。這些攻擊利用 AI 生成的提交內容來混入合法的程式碼變更,使人眼審核幾乎無法察覺。
背景
近期網路安全研究人員發現名為 Glassworm 的威脅參與者再次活躍,針對 GitHub、npm 以及 VS Code 擴充功能市場發動大規模供應鏈攻擊。該攻擊利用肉眼無法察覺的 Unicode 隱形字元,將惡意負載隱藏在看似空白的字串中,並透過 JavaScript 的執行環境進行解碼與執行,目前已有超過 150 個儲存庫受害。
社群觀點
針對這類隱形 Unicode 攻擊,Hacker News 社群展開了熱烈討論,核心爭議點在於防禦這類威脅是否真的需要複雜的 AI 技術。許多開發者認為,這類攻擊的特徵其實非常明顯,最直接的警訊就是程式碼中出現 eval 函式。社群成員指出,任何 eval 的使用都應該被視為極高風險的信號,如同處理未爆彈一般謹慎。此外,針對不可見字元的檢測,開發者認為透過簡單的 Lint 規則或 Shell 腳本就能達成,例如強制要求所有非 ASCII 字元必須以轉義序列表示,而非直接插入原始字元,這樣就能在不依賴 AI 的情況下解決大部分問題。
然而,也有部分討論聚焦於平台方的責任。有觀點認為,既然 GitHub 等平台提供了 PR 提交機制,就應該承擔起保護生態系的責任,主動針對異常的零寬度字元跨度進行掃描與警示,而不應將防禦責任完全推給個別開發者或第三方付費服務。儘管市面上已有如 Aikido 等公司提供專門的檢測工具,但部分開發者對於為了尋找漏洞而必須安裝另一個大型 JavaScript 工具包感到遲疑。
在實務經驗分享方面,有開發者提到他們在儲存庫中實施了嚴格的 Unicode 限制規則,最初是為了避免位元組順序標記導致的編譯錯誤,現在則成為防禦此類攻擊的有效手段。雖然這類規則可能會影響到表情符號或特殊語言符號的使用,但透過建立白名單,可以平衡開發便利性與安全性。整體而言,社群傾向於認為這是一個可以透過基礎工程手段解決的問題,而非必須仰賴高階安全產品的技術難題。
延伸閱讀
- Aikido Safe Chain:一個開源的工具,用於封裝 npm、yarn 等套件管理員,旨在於惡意軟體進入開發環境前進行攔截。
- GitHub Secret Scanning:GitHub 官方提供的機敏資訊掃描功能,社群認為類似機制應擴展至 Unicode 異常檢測。