AsyncAPI 五個 npm 毒版中招點算？由 lockfile 查到全面換憑證
惡意碼等到 import 先郁手，停用 install script 都擋唔住
7 月 14 日，AsyncAPI 有四個 npm 套件俾人加咗惡意碼，再由項目本身嘅 GitHub Actions 發布。毒版只喺 npm 活躍咗約四個鐘，不過 @asyncapi/specs 可以經其他工具間接裝入項目，淨係靠記憶去諗有冇用過 AsyncAPI，根本查唔清實際影響。今次最麻煩係惡意碼等到 import 或 require 先執行，npm install --ignore-scripts 都擋唔住。
先對清楚五個有問題版本
受影響清單係 @asyncapi/[email protected]、@asyncapi/[email protected]、@asyncapi/[email protected]，同 @asyncapi/[email protected]、6.11.2-alpha.1。AsyncAPI 官方話呢五個版本已經由 npm 清走；事故時列出嘅上一個安全版本，就分別係 3.3.0、1.1.0、0.7.0 同 6.11.1。團隊亦要查內部 registry、npm／Yarn cache、container image 同長期保存嘅 build artifact，因為公開 registry 清走套件，唔會順手清埋公司內部副本。
第一輪可以用 npm ls @asyncapi/specs @asyncapi/generator @asyncapi/generator-helpers @asyncapi/generator-components --all 睇現有 dependency tree，再喺 package-lock.json、npm-shrinkwrap.json、yarn.lock 同 pnpm-lock.yaml 搜版本號。lockfile 出現毒版只證明套件曾經俾 dependency resolver 揀中，未足以證明惡意碼已經行過。 不過呢個結果已經值得保留相關 cache、runner 同紀錄，唔好急住淨係刪 node_modules 當處理完。
圖片：Microsoft Security
CI 有跑 build、test 或文件生成，就要再查深一層
今次套件冇用 preinstall、install 或 postinstall hook。Microsoft、Socket 同 JFrog 嘅分析都指出，loader 藏喺正常匯出路徑，程式、測試、CLI、文件生成器或 build script 載入模組嗰刻先開一個隱藏 Node.js process，再由 IPFS 下載 sync.js。換句話講，CI log 淨係見到 npm ci 成功，未代表 payload 已經啟動；同一個 job 跟住有冇跑 generator、測試、build 或啟動 app，先係判斷重點。
要逐個查 7 月 14 日起曾經解出上述版本嘅 GitHub Actions run、self-hosted runner、開發機同 container build。可疑痕跡包括背景 node -e process、指向 IPFS 嘅連線、85.137.53[.]71 嘅 8080／8081／8091 連線，同藏喺假 NodeJS 目錄入面嘅 sync.js。Linux 亦可查 ~/.config/systemd/user/miasma-monitor.service，macOS 查 shell 設定檔有冇 ### Node Auto-Update Script ###，Windows 就查使用者 Run key 入面嘅 miasma-monitor。
圖片：Microsoft Security
真係載入過，就當部機已經失守處理
一旦 log、endpoint telemetry 或網絡紀錄顯示受污染模組行過，先隔離主機同保留證據，再由可信環境重建 runner、開發機同相關 image。清走毒版、重建 lockfile 同清 cache 只係移除入口；payload 有持續存取同遠端 shell，刪除依賴未必會停低已經行緊嘅後門。若果 CI 紀錄太短、runner 已回收，根本判斷唔到有冇 import 過，保守做法都係按已執行處理。
跟住要喺乾淨主機撤銷及更換嗰個環境接觸到嘅 npm token、GitHub PAT／App token、SSH key、AWS 同其他雲端憑證、簽署金鑰、部署 secret、container registry token 同 CI secret。研究人員發現今次樣本內置嘅自動收集功能處於停用狀態，但遠端 shell 本身仍可讀取受感染帳戶有權見到嘅資料，所以唔可以據此假設憑證安全。亦要翻查中招時段之後推出嘅 package、image 同部署，確認攻擊者冇借 CI 身份改過下游產物。
合法 provenance 都可以簽住惡意碼
事故源頭方面，AsyncAPI 官方交代，攻擊者利用配置危險嘅 pull_request_target workflow 處理外來 PR 程式碼，之後以高權限 asyncapi-bot 憑證直接推送惡意 commit；正常 OIDC 發布流程再替毒版產生有效 provenance。Microsoft 對公開紀錄嘅判斷較審慎：時間線證明高權限 workflow 先運行、bot 身份其後推 code，但公開 log 未能單獨證實憑證點樣外洩。可以肯定嘅係，provenance 證明產物由指定 workflow 建出，唔會替 source commit 做安全審批。
iThome 報道提到 payload 內有 M-RED-TEAM v6.4 標記，同 Miasma 共用部分命名及設計。各間研究機構嘅講法仍有差異：JFrog 稱佢為 Miasma v3，AsyncAPI 官方就話同較廣泛嘅 Miasma 家族只有有限關聯。公開工具同字串可以俾其他攻擊者重用，現階段未夠證據把事故穩陣歸到某個團體。開發團隊眼前要做嘅，仍然係查清五個版本有冇真係載入過，再按結果重建環境同換走可能曝光嘅憑證。
參考來源
- iThome — 針對AsyncAPI供應鏈攻擊事故，攻擊者使用Miasma框架散布惡意軟體 — original report
- AsyncAPI 官方事故報告 — 核對受影響版本、事故時序、GitHub Actions 問題、官方處置同根因分析
- Microsoft：AsyncAPI npm 供應鏈攻擊技術分析 — 核對 import-time 執行方式、IOC、憑證風險同修復建議
- Socket：AsyncAPI 套件散播多階段 loader — 交叉核對惡意版本、注入檔案、執行條件同偵測線索
- JFrog：Miasma Worm Returns to npm — 補充跨平台持續存取痕跡、受感染環境分流方式同憑證更換建議
- Unit 42：npm 威脅形勢與緩解方法 — 交叉核對攻擊活動背景，亦說明公開工具令可靠歸因變得困難
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
