ChainDrop 蠕蟲踩入 npm 供應鏈：刪走 keyv 未代表清得乾淨

iThome 報道，ChainDrop 喺 8 月 4 日由 keyv 相關套件開始擴散，短時間內牽連數百個 npm 套件。呢件事值得開發團隊即刻處理，原因好直接：中招條件可以只係執行過一次 npm install。惡意程式掛喺 preinstall lifecycle hook，測試、code review 甚至安裝完成前已經有機會執行，之後先更新去安全版都唔會自動收返已經外洩嘅 token。

點解一個 dependency 可以一路擴散

Aikido 指攻擊者先攞到 keyv 維護者嘅 GitHub 帳戶權限，再改動套件內容同用 GitHub Actions 發布新版本。惡意套件內加入 setup.mjs 同經混淆處理嘅 JavaScript payload；開發者電腦安裝後，程式會轉到背景繼續行，喺 CI runner 就留喺當次 job 入面，讀取環境變數、設定檔、shell history、SSH key 同 runner RAM。跟住佢會試用搵到嘅身份登入 npm、GitHub、AWS、Kubernetes 同 HashiCorp Vault，再將有權存取嘅 secrets 一併搜走。

攞到 npm 發布 token 後，蠕蟲會列出該身份有權管理嘅套件，下載最新 tarball、插入 payload、推高 patch 版本再發布。GitHub token 亦可能俾佢用嚟修改 repo 分支，加入 .claude 或 .vscode 設定，製造另一條重新啟動惡意程式嘅路。一次受污染安裝，影響範圍可以由某部 notebook 延伸到公司 repo、CI workflow、雲端帳戶，甚至團隊自己發布嘅套件。

圖片：Aikido Security

先查版本，唔好見到 keyv 就當中招

所有 keyv 用家唔係自動受害者，判斷要睇 lockfile 鎖住咩版本、幾時安裝、當時有冇容許 lifecycle script，同個環境擺咗咩 credentials。Aikido 最初確認嘅核心版本包括 [email protected]、[email protected]、[email protected]、[email protected]、[email protected]、@cacheable/[email protected]、[email protected]、@cacheable/[email protected]、@cacheable/[email protected]、@cacheable/[email protected] 同 [email protected]。不過名單仍有更新，實際排查要對照研究機構維護緊嘅完整 IOC 清單。

各方公布嘅數目亦唔一致：iThome 報道提到 444 個套件同 2,212 個惡意版本，Microsoft 就採用「超過 400 個套件」呢個較保守講法，其他研究團隊亦按確認時間同統計方法得出唔同數字。與其追住一個總數，工程團隊應該先跑 npm ls keyv cacheable flat-cache file-entry-cache cacheable-request cache-manager --all，再搜 package-lock.json、yarn.lock 或 pnpm-lock.yaml，因為真正拉入惡意版本嘅可能係 transitive dependency，未必寫喺頂層 package.json。

CI 紀錄先講到套件有冇真係執行過

搵到受影響版本後，要對返 8 月 4 日起嘅 CI job、開發者安裝紀錄、artifact repository 同共用 cache，查看有冇執行 node setup.mjs、下載或啟動 Bun，亦要搜尋 Math_Symbol.js、Math_init.js、math_<guid>.js 呢類檔案。網上紀錄方面，可對照 Microsoft 公布嘅 hashes，同檢查有冇連去 npm-cache[.]com、pypi-get[.]com 或 js-mirror[.]com。如果 runner 拉過惡意版本，但個 job 喺 preinstall 前已經停咗，風險會低過完整執行過惡意程式；實際時間線要靠紀錄確認。

撤銷 token 前先隔離受影響環境

確認執行過惡意版本，就應該先隔離工作站或 runner、停用相關 workflow 同發布程序，再由一部已知乾淨嘅機器處理 credentials。Microsoft 仲發現某條 fallback 路徑會裝入 token-monitor，撤銷 token 時可能觸發破壞動作，所以唔好喺仍然受感染嘅電腦上逐個換 key。隔離後按服務商指引撤銷 GitHub PAT、GitHub App／OAuth token、npm token、AWS access key、SSH key、Kubernetes credentials、Vault token，同輪換 CI secrets；同時查看登入、API、套件發布同 repo audit log，追查有冇未授權活動。

淨係刪除套件或更新版本都唔夠。 Microsoft 建議清走 npm、Yarn 同 CI cache，以可信 lockfile 重建專案，再重建受影響 runner、共用 base image 同由佢哋產生嘅 artifacts。團隊亦要檢查有冇無對應 commit、PR 或 tag 嘅 npm 發布，repo 入面有冇陌生 workflow、.claude、.vscode 設定或新分支。曾經由受影響 runner build 出嚟嘅 container、網站 bundle 同套件，亦應該重新產生，唔好直接沿用。

有 provenance 都未必代表內容安全

今次另一個麻煩位，係攻擊者用正常嘅 GitHub Actions 身份發布部分惡意版本，所以一樣可以帶住有效 provenance。簽署資料只能證明「邊個 workflow 發布」，如果 workflow、維護者帳戶或 runner 本身已失守，個章依然可以係真。長遠可以升級至 npm v12，善用 dependency scripts 預設關閉呢項改動，再用 npm approve-scripts 維護 allowlist；同時設 min-release-age、固定已知安全版本、限制發布身份權限，同避免長效雲端 key 常駐 CI。呢輪事件仍在更新，用 Node.js／npm 嘅團隊應該持續對照最新 IOC 同重新檢查 build 紀錄。

參考來源

• iThome — 【資安日報】8月7日，微軟剖析NPM套件keyv供應鏈攻擊事件ChainDrop，揭露惡意程式完整運作流程 — original report
• Microsoft Security Research：ChainDrop supply chain compromise — 攻擊鏈、IOC、持久化手法、偵測方法同處理指引嘅主要來源。
• Aikido Security：Keyv and friends compromised — 最初受影響套件版本、惡意檔案、發布方式同事件更新。
• Wiz Research：Keyv packages IOC 清單 — 持續更新嘅受影響套件同版本清單，適合核對 lockfile。
• GitHub Changelog：npm v12 安裝安全改動 — 確認 npm v12 嘅 dependency script 預設政策同 approve-scripts 做法。
• npm Docs：撤銷 access token — npm 官方 token 撤銷步驟同注意事項。
• GitHub Docs：撤銷 credentials — GitHub 官方大量撤銷 token、SSH key 同重新授權指引。
• AWS Security Hub：處理 IAM credentials 暴露 — AWS 官方 access key 輪換同收窄 IAM 權限建議。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。