GitHub Actions is a trap

Tyler Cipriani

GitHub Actions 是個陷阱

原文由 Tyler Cipriani 發布,訂閱此部落格

駭客正以令人疲乏的速度入侵套件,而每一份事後檢討報告都少不了 GitHub Actions。

二月底,一個自稱為 hackerbot-claw 的 AI 駭客機器人1偷走了單一專案的發布金鑰。不到一個月內,約五十個其他專案就被植入了竊取憑證的程式。每個被感染的儲存庫都會接著竊取下一個目標的憑證。

這一波供應鏈攻擊始於一個 GitHub Actions 陷阱:一個簡單卻糟糕的預設值,而修正提案早在五年前就已提出。

GitHub Actions 及其後果

阿克巴上將警告 GitHub Actions 中的陷阱
阿克巴上將警告 GitHub Actions 中的陷阱

Trivy 是一套開源的安全掃描器。但如果你在三月底使用 Trivy,那可就倒大楣了。

3 月 19 日,駭客推送了一個試圖從任何執行環境中竊取機密資料的 Trivy 版本。Trivy 將原因歸咎於其持續整合(CI)系統 GitHub Actions 中的「設定錯誤」。

但與其說是設定錯誤,不如說這根本就是 GitHub Actions 設下的陷阱。

以下是 Trivy 被攻陷過程的簡化版本2

# INSECURE. DO NOT USE.
on:
  pull_request_target

jobs:
  check:
    steps:
      - uses: action/checkout@deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
      - uses: ./.github/actions/setup-go
      - uses: some/go-static-analysis@c0ffeec0ffeec0ffeec0ffeec0ffeec0ff

乍看之下,這段程式碼似乎沒什麼問題:

  • 沒有引用任何機密資料。
  • 第三方 Action 都已固定在不可變的雜湊值上。
  • 取出 pull request,執行靜態分析。

但這段程式碼,正是不折不扣地複製了 2021 年一篇名為「preventing pwn requests」的 GitHub 部落格文章中所列舉的反面模式:

如果 pull_request_target 工作流程只是 […] 執行不受信任的程式碼,但沒有引用任何機密資料,這樣還會有漏洞嗎?

會的

GitHub Security Lab

問題就出在 pull_request_target

  • pull_request_target —— 會把一個權限充足的 GITHUB_TOKEN 直接丟進執行環境。
  • actions/checkout —— 有一個選用參數 persist-credentials,設為 false 時會移除機密資料。但這個參數的預設值卻是 true

persist-credentials 參數設為 false 的做法,在 GitHub Actions 上從 2021 年起就一直是個未解決的 issue。

你的 $HOME 就是犯罪現場

駭客拿到 Trivy 的金鑰後,便發布了一個新版本的 Trivy 來竊取更多的金鑰。

LiteLLM 在他們的 CI 中使用了 Trivy,而他們就是用同一套 CI 將程式碼發布到 Python 套件庫 PyPI。當 LiteLLM 的 CI 執行到被植入後門的 Trivy 時,駭客就此盜走了他們的發布金鑰。

而在 3 月 24 日,當 Callum McMahon 啟動他的 IDE 時,他的 MacBook 當機了。也正是因此,他才發現了 LiteLLM 遭挾持事件

McMahon 的 MacBook 之所以當機,是因為駭客偷偷塞進 LiteLLM 的惡意程式碼正在作祟。而那段惡意程式碼試圖竊取的憑證包括:

  • ~/.netrc
  • ~/.aws/credentials
  • ~/.config/gcloud
  • ~/.config/gh
  • ~/.azure
  • ~/.docker/config.json
  • ~/.npmrc
  • ~/.git-credentials
  • ~/.kube/

這些檔案通常散落在 $HOME 目錄各處,裡面塞滿了權杖與金鑰,而且往往未經加密。

AI 與供應鏈的末日螺旋

未加密的憑證、未固定的依賴套件,以及 CI 的各種坑,我們早就處理這些問題處理到煩了。

但 AI 加速了一切,包括重蹈安全覆轍的速度。

在 Trivy 遭入侵的當天,我問了 Claude:「要如何掃描 docker registry 映像檔中的安全漏洞?」

它的部分回覆是:

CI/CD Integration Example (GitHub Actions with Trivy)

    - name: Scan image for vulnerabilities
      uses: aquasecurity/trivy-action@master

這個範例有兩個問題:

  1. 未固定的參照 —— master 是個會不斷變動的參照。如果駭客控制了這個儲存庫,我就會是第一個受害者。
  2. 現存的漏洞 —— 對於當天發布的那個 CVE 隻字未提。我沒問,Claude 就不會去查。

與此同時,Vercel 的執行長將公司近期的資料外洩歸咎於一名「受到 AI 加速」的駭客。而 Anthropic 最近的宣傳行程,則包括向美國聯準會主席簡報其前沿模型所發掘出的漏洞。

壞人有了 LLM 就獲得超能力,好人有了 LLM 卻還是栽在 2010 年代中期的 CI 問題上。

而同一個能揪出 OpenBSD 中存在 27 年之久的安全問題的工具,卻還是會叫你把 GitHub Actions 固定在 @master 上。


  1. 或者,無論如何,是某個自稱為 hackerbot-claw 的人。↩︎

  2. 我的 GitHub Actions 範例是 aquasecurity/trivy #10259 中被移除的 action 的簡化版本。↩︎

本文章由 muse-spark-1.2-contributor 進行翻譯

留言