Megalodon GitHub供應鏈攻擊：6小時內5,700個惡意提交點樣滲入5,500個倉庫？

偽造提交資料（Commit Metadata）

提交訊息與作者資訊都被精心設計，看起來像例行的CI設定更新或workflow優化。結果就是這些惡意提交很容易混入正常開發歷史中，延遲被發現的時間。

專攻分支保護薄弱的倉庫

攻擊活動主要針對 branch protection（分支保護）不足 的倉庫。如果沒有強制Pull Request審核、或允許過多帳號直接修改workflow檔案，攻擊者就可以把變更直接推到預設分支。

注入受污染的GitHub Actions Workflow

每個惡意提交都新增一個 GitHub Actions workflow檔案，裏面包含 Base64編碼的Bash payload。當CI pipeline運行時，腳本就會在GitHub Actions runner中執行。

因此攻擊通常不會即時發作，而是等到下一次CI自動化流程被觸發時才開始偷取資料。

惡意Payload嘗試竊取咩資料？

這段Base64編碼腳本的主要目標是 CI環境中的憑證與秘密資訊，然後把資料傳送到攻擊者控制的伺服器。

研究報告指出，目標資料包括：

• CI/CD環境變數
• 雲端服務憑證（AWS、Google Cloud、Azure）
• SSH私鑰
• API Token與應用程式秘密
• GitHub Actions OIDC令牌
• runner系統內可存取的其他設定憑證

腳本會掃描runner環境變數、系統資訊甚至 /proc/*/environ 等系統路徑，收集可用的秘密資料再外傳。

由於CI pipeline通常持有部署權限，一旦被入侵，攻擊者就可能進一步進入：

• 雲端基礎設施
• 軟件套件倉庫（package registry）
• 生產環境部署流程

為何盜取OIDC令牌特別危險？

Megalodon其中一個重點目標是 GitHub Actions OIDC（OpenID Connect）令牌。

現代CI/CD系統越來越多使用 OIDC聯邦身份驗證 來登入雲端服務，而不再儲存長期API金鑰。例如GitHub Actions可以透過OIDC向雲端平台請求短期憑證。

好處是：

• 不需要在倉庫中存放長期憑證
• 憑證會自動過期

但同時也帶來新風險：

如果攻擊者在CI運行期間 偷到OIDC令牌，就可能暫時冒充該CI工作流程的身份。

由於雲端平台信任這些令牌，攻擊者有機會把它交換成 臨時雲端存取權限，而權限級別與原本CI部署流程相同。

結果可能包括：

• 存取雲端資源
• 控制部署流程
• 從雲端服務提取更多秘密資料

即使令牌有效時間很短，對攻擊者來說仍然足夠發動下一步滲透。

Megalodon與VS Code擴充套件事件有關嗎？

差不多同一時間，GitHub亦披露另一宗安全事故：

一名員工裝了 被植入惡意程式的VS Code擴充套件，導致攻擊者能夠存取約 3,800個GitHub內部倉庫。

該事件屬於開發環境被入侵，惡意擴充套件會收集憑證與token，再讓攻擊者進入GitHub內部系統。

有些安全分析指出，兩宗事件在 時間與供應鏈攻擊模式 上有某些相似之處。不過目前公開證據 未能證明VS Code事件直接導致Megalodon攻擊。

因此普遍看法是：

• 兩宗事件同樣影響開發者生態
• 但很可能是 獨立發生的供應鏈安全事件

對CI/CD安全的啟示

Megalodon顯示供應鏈攻擊策略正逐漸轉向 開發自動化基礎設施。

與其改程式碼，攻擊者更傾向：

• 入侵CI流程
• 等自動化系統自己洩露憑證

由於CI/CD pipeline通常持有大量權限，一個被修改的workflow就可能影響整個部署鏈。

安全團隊普遍建議採取以下防護措施：

• 強制branch protection
• workflow變更必須經Pull Request審核
• CI工作流程採最小權限
• 監控自動化帳號與workflow更新

隨著開發流程越來越依賴自動化，CI/CD安全已經成為軟件供應鏈防禦的核心環節。