SleeperGem 專攻開發者電腦：三批 RubyGems 惡意版本要即查
多年冇更新嘅套件突然出新版，舊信任反而成為攻擊入口
RubyGems 平時冇 npm 咁多供應鏈事故新聞，但今次 SleeperGem 幾值得開發團隊即刻停一停手檢查。攻擊者借多年冇活動嘅維護者帳號發布新版本，再將惡意 dependency 塞入原本有人使用嘅 gem。仲麻煩嘅係，惡意程式會偵測 CI 環境，一見係 CI 就停手。正常 pipeline 表面上照樣乾淨，payload 反而會喺開發者部電腦執行。
邊幾個版本要查
Aikido Security 最初披露同 StepSecurity 後續分析列出三組受影響版本：git_credential_manager 2.8.0、2.8.1、2.8.2、2.8.3；Dendreo 1.1.3、1.1.4；fastlane-plugin-run_tests_firebase_testlab 0.3.2。最後嗰個 Fastlane plugin 過往累積超過 57 萬次下載，本身用嚟配合 Firebase Test Lab 跑 Android 測試，所以流動 app 團隊都要查，唔好以為 Ruby 網站先有關。
截至 2026 年 7 月 30 日，RubyGems 嘅 git_credential_manager 頁面已顯示套件唔再託管；Dendreo公開版本清單回復至 1.1.2，而 Fastlane plugin最新只列 0.3.1，即係上述惡意版本已經唔喺公開清單。不過 RubyGems 暫時未見另發完整事故報告，帳號點樣失守亦未有公開證據。密碼重用、釣魚或者 API key 外洩都只可以當可能性，唔可以當成已確認原因。
多年冇活動，反而更易收埋異常
Aikido 指兩個互不相關、靜咗六至七年嘅維護者帳號，喺相近時間發布帶有同一惡意 dependency 嘅版本。呢類舊套件有現成下載量、專案又可能仲留喺公司 lockfile，但日常已經冇乜人望住。突然多一個 patch 版本，好容易俾人當成普通維護更新。另一個明顯警號係 RubyGems 有新版，原始碼 repository 卻搵唔到對應 commit 或 tag；團隊如果只信套件庫版本號，呢層異常就會直接漏過。
git_credential_manager 個名亦有混淆作用，望落似 Microsoft 官方 Git Credential Manager，但今次出事嘅係第三方 Ruby gem。攻擊者再經 Dendreo 同 Fastlane plugin 加入依賴，開發者即使冇主動揀呢個新 gem，更新舊 dependency 時一樣可能拉咗入嚟。合理推斷係，沉睡帳號嘅價值來自多年累積落嚟嘅信任同依賴關係，加上發布活動少，異常較遲先有人察覺。
點解避開 CI 特別危險
StepSecurity 喺受控環境觀察到，程式會檢查約 30 個常見 CI 變數，認出 GitHub Actions、GitLab CI、CircleCI、Jenkins 等環境就停手。開發者電腦通常長期登入 GitHub、雲端平台同 RubyGems，亦可能擺有 SSH key、環境檔、Firebase service account 同 app 簽署材料；CI runner 多數用完即棄，監察亦密過個人工作站。惡意程式集中攻開發者電腦，就有較長時間維持存取權，亦較易繞過只盯住 pipeline 嘅保安措施。
StepSecurity 確認 loader 會下載 native daemon，嘗試加入自動啟動機制，同埋尋找提升權限嘅機會。不過佢哋亦講明，daemon 本身點樣收集同傳走資料仍要獨立分析。所以現階段可以確認持久化風險，未可以斷言每部受影響電腦嘅所有 credentials 都已經外洩；處理上仍然要當成可能失守，因為等到證實邊條 key 真係俾人攞走先換，通常已經太遲。
團隊而家可以點做
先查所有 Gemfile.lock 同 dependency inventory。 搜尋上述完整套件名及版本，連舊分支、release repository、Fastlane 專案、開發者電腦同內部 gem cache 都要計。只睇而家 production 用緊邊版唔夠，因為有人曾經喺工作站載入惡意版本，之後再更新 lockfile，受感染痕跡仍可能留喺部機。
搵到版本就先隔離相關電腦，再處理套件。 git_credential_manager 冇可回退嘅正常 Ruby gem 版本，應直接移除；Dendreo 可回到公開清單上原有嘅 1.1.2，Fastlane plugin 則係 0.3.1。lockfile 最好喺乾淨環境重新產生。曾經載入惡意 gem 嘅電腦仲要按 StepSecurity 公布嘅 indicators 檢查 daemon、自動啟動項目同可疑權限；高風險環境直接重建系統會穩陣過逐件清。
清理完成後先輪換 credentials。 範圍要包 RubyGems API key、GitHub token、SSH key、雲端 access key、Firebase service account、Fastlane 使用嘅發布及簽署資料，同埋電腦上可讀到嘅環境變數。相關 browser session、CI secret 同 deploy key亦要逐項檢視，舊 credentials 要撤銷，唔好淨係新增一份繼續留住舊 key。
重審帳號同發布權限。 RubyGems 嘅 Ownership 頁面可以睇邊啲人仍有發布或撤回版本嘅權限，離隊成員同無人管理嘅帳號要移除；所有維護者應開 MFA。API key 改用最少權限、限制至指定 gem、設定到期日，舊 legacy key 就撤銷。日後每次依賴多年冇更新嘅套件突然出新版，亦應核對 repository commit、tag、發布者同 dependency 變化，先好更新 lockfile。
呢次事件反映，開發者電腦同套件發布帳號都要納入正式保安管理。用緊 Ruby、Bundler 或 Fastlane 嘅團隊，先完成版本盤點；任何工作站曾經載入上述版本，就按受感染電腦處理。
參考來源
- iThome — 供應鏈攻擊SleeperGem鎖定RubyGems用戶，入侵多年未活動的維護者帳號而得逞 — original report
- Aikido Security：SleeperGem RubyGems supply chain attack — 最初披露套件異常、帳號活動同惡意版本演變
- StepSecurity：SleeperGem persistent backdoor analysis — 受控環境分析、受影響版本、CI 迴避、持久化同復原建議
- RubyGems：git_credential_manager — 核對套件而家已經唔再託管
- RubyGems：Dendreo — 核對公開清單最新版本已回復至 1.1.2
- RubyGems：fastlane-plugin-run_tests_firebase_testlab — 核對公開清單最新版本係 0.3.1
- RubyGems Guides：API key scopes — 最少權限、指定 gem、到期日同撤銷 legacy key 指引
- RubyGems Guides：管理套件擁有者 — 核對維護者角色、MFA 狀態同移除權限方法
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
