谷歌Flank潛藏3年的Github Action供應鏈攻擊

?簡? 介

Flank?[1]?是谷歌 Firebase Test lab 開源在 Github 的一個項目，用于同時對多個安卓和IOS設備進行測試。2024年4月15號 AWS 安全工程師 Adnan Khan 公布了關于該項目代碼倉庫 Github Action CI/CD 存在漏洞的細節[2]，漏洞在2020年于此代碼合并請求[3]?引入，3年多一直沒人發現（這個倉庫谷歌一直有賞金計劃），谷歌把該漏洞歸屬為供應鏈漏洞，并給予該漏洞賞金 $7500 美刀（約 5w+ 人民幣）。

利用該漏洞可以獲得 Flank Github 代碼倉庫的寫權限的 GITHUB_TOKEN 和谷歌云的賬戶密鑰（看給的賞金大概能想到該密鑰能進一步獲取到的權限），該漏洞于2024年4月11號修復。

漏洞整體利用鏈圖解（文章后面會附上復現環境和步驟～）：

另外，具有寫權限的?GITHUB_TOKEN?可以用來發布 GitHub Release 以及 Release 附件，從而發布惡意的編譯后二進制軟件來達到供應鏈攻擊的效果，原文作者由于是 Bug Bounty，滲透講究點到為止，不過本文也會涉及這部分利用手段。

?背? 景

Github Action

Github Action?[4]用于在 Github 代碼倉庫中自動化、自定義和執行軟件開發工作流程，也可用于持續集成持續部署流程（即 CI/CD），十分便于開發者使用，而不用專門去部署一套 Jenkins 之類的用于 CICD。具體表現在 Github 上，就是在代碼倉庫根目錄建一個?.github?目錄，里面放著一些定義自動化任務的 yaml/yml 文件，稱之為?workflow?（工作流），

關于?.github?目錄大家應該挺眼熟的，但一般我們都會忽略不太起眼的它，因為一般它不會存在什么特別的安全漏洞，但本文的重點就是里面的?workflow?。

?workflow?觸發的方式很多，比如在?git push?代碼到倉庫時觸發，亦或是在創建代碼合并請求（Pull Request，下文簡稱?PR?）觸發等，觸發后通過 Github Runner（執行器）去執行相應的?workflow?，觸發等方式多種多樣，觸發方式寫法一般如下：

上下?workflow?即是在代碼 push 到 main 分支或者是 PR 入 main 時觸發，運行結果輸出?Hello World?

在本漏洞中，通過在?PR?評論區回復特定關鍵字觸發存在漏洞的?workflow?。

Github Action Secrets

關于 Github Action secrets?[6]，比如我們給代碼跑完單元測試后想要自動部署，那部署到相關環境需要的SSH或其他密鑰肯定是不想明文放出來的，比如硬編碼在倉庫代碼中，或者直接寫在倉庫配置文件中，這樣大家就都能在 Github 倉庫文件中看到了。

使用 secrets 的好處是，可以把這類密鑰在跑 workflow 時，通過 Runner 環境變量的形式帶進去。這樣就解決剛剛說的問題了。此外，就算相關代碼不小心把某個上下文變量日志給打了出來，secret 恰好包含在其中，Github Runner 顯示的日志，也會把 secrets 脫敏顯示，也就是說，就算我們主動?print($secret)?，他在 Runner 日志中顯示的也是脫敏數據，如?******?。

以?GITHUB_?開頭的為 Github Runner 內置的一些環境變量或Secret?[5]，在 Action 中的 yaml 通過?${{ secrets.GITHUB_TOKEN }}?即可引入，非常方便。

先獻上存在漏洞的 workflow

https://github.com/Flank/flank/blob/v23.10.1/.github/workflows/run_integration_tests.yml

直接看漏洞存在和利用點可能沒那么明顯，下面來分析一下

?漏洞發現和利用

其實這類由 PR 引發漏洞，并且是有賞金計劃的，一般在數日內就會被發現。因為多數賞金獵人，基本都是通過自動化的工具對?.github?目錄里的文件進行批量檢測，相關的工具有?gato?[7]?和 gh-workflow-auditor?[8]，其中 gato 是原文作者是通過在上一家公司工作開源的自研工具。該漏洞是他對 gato 不斷優化的 gato-x 版發現的，目前優化版 gato-x 還沒開源出來，原作者還在盡可能的優化，然后在不久的將來放出來。

至于這個漏洞為啥一直沒被發現的原因，他和普通的 Action 注入不太一樣，例如下面這個流水線[9]

如果攻擊者在這個項目 Github 上新建一個 issue 的標題為?test" && ls / && echo "?，會直接造成流水線 runner 里的命令注入

即，這種 Action 注入是執行命令時直接拼接了外部可控的變量。

而 Flank 觸發流水線時并沒有直接拼接可控變量，只是獲取了 PR 的序號，

然后通過?gh?命令切換到我們 PR 的代碼上，這時才出現我們可控的部分

即此時會切換到我們 PR 的代碼，但此時它仍然沒有拼接任何東西。特別是對于自動化工具而言，這里根本就不會檢測出來，因為沒有拼接可控的東西。由于 Github 上的 workflow 太多，一個個找和看，其實是不好找出來的。就像我們看存在問題的 workflow，一下子我們也沒能太看出來存在什么問題，這就是為啥這個漏洞存在這么久才被發現。

原作者檢測工具的設計目的就不太一樣，他是掃描存在觸發風險點的地方，然后在回過頭來看是不是誤報，盡管有接近70%的是誤報。

在看整個 workflow 文件，在項目 PR 評論區回復?@flank-it?會觸發?should_run_it??job，這個 job env 帶有?GITHUB_TOKEN?secret，并且該 token 有該項目的寫權限（如果沒有該項目的寫權限，這個在評論區加個眼睛 👀?的 emoji 是加不上的）

然后?should_run_it?運行結果?run_integration_tests?為?true?會觸發?env?帶有 GCLOUD_KEY?secret ?的 job

到這里，還沒講到，Action 注入的，我們可控的惡意代碼在哪呢？目前我們向此倉庫發 PR，然后流水線中?gh checkout 我們的PR?切換到我們的代碼。其實對于一般的流水線，都會有構建操作，即打包代碼之類的，這里用的是?gradle?

然后?gradle?DSL（領域定義語言）是基于 Groovy的[10]！Gradle 5.0 后，還支持了 Kotlin 語言，也就是說我們可以執行通過任意代碼執行，從而達到任意命令執行！從而達到就可以把這兩個 secret 通過?curl?命令外帶即可（非項目成員記得是看不到流水線運行結果的，所以不能像下面漏洞復現那樣編碼輸出）。

惡意 PR

https://github.com/Flank/flank/pull/2481/files#diff-5625e3601fa0ad3a6a2824239e5a2fde71c149597d31394f9224a08c24be7b9d

然后作者為了規避 harden-runner [11]安全檢測機制，只改了原倉庫的 gradle，其他都是改 fork 到自己倉庫的，因為在自己 fork 的倉庫改，在原倉庫也會留有 commit 信息（雖然最后還是告警了，原文還是有提到其他規避方法的）

由于執行 gradle 沒有代入 secret 環境變量，這里需要用個 trick，即讀取進程內存來獲取 runner 里的 secret。因為就算是不同階段的 job，一般都是在一個容器里執行。

?漏洞復現

環境搭建（可跳過）

搭建好的復現環境：https://github.com/tarihub/hack-flank-cicd

復現環境的項目配置（自己搭建就需要注意下，免得踩坑）：

https://github.com/tarihub/hack-flank-cicd/settings/actions 需要在這里勾上 Workflow permissions 的 Read and write permissions 權限，不然小眼睛👀交互打不上（其實主要是模擬原項目給了 GITHUB_TOKEN 的寫權限）

secret 記得 base64編碼一下，不然解碼會失敗

復現步驟

先fork https://github.com/tarihub/hack-flank-cicd 項目過來，然后把?settings.gradle.kts?改為

PS：這里的 pastebin 內容就是上面的讀取進程內存處，用來讀取 Runner 進程內存中存的 secret

commit 并 push 后發送 PR 到原倉庫，在 PR 評論區留言?@flank-it?觸發 Github Action

運行過程，這里為了方查看所以直接輸出

正常情況下利用，由于非項目成員，看不到運行結果，所以需要用 curl 外帶

就得到 GCLOUD_KEY 和 GITHUB_TOKEN

base64解碼得?flag{GCLOUD_KEY}?

接下來，我們拿到具有寫權限的 Github_TOKEN 就可以發布 release 附件了，一般項目都會有 release，所以我們先創建一個 release，創建好標簽命名完標題保存即可

https://github.com/tarihub/hack-flank-cicd/releases/new

這里注意，獲取到的?GITHUB_TOKEN?要在流水線運行結束前使用，否則 token 會失效，因此我們可以通過 sleep 等各種方式阻塞流水線的運行

根據 Github 文檔[12]，然后要獲取 RELEASE_ID

然后通過接口增加/修改 release 附件即可

來到 Github Release 頁面就看到我們的惡意附件就上傳上去了

至于?GCLOUD_KEY?的進一步利用，網上有很多文章介紹，這里就不進一步深入了

?總? 結

該漏洞的修復，官方去除了在 PR 評論區留言觸發流水線的方式，并且不會切換到 PR 部分對代碼，只保留了定期觸發流水線，這樣攻擊者就無法觸發可控的攻擊代碼了。

https://github.com/Flank/flank/pull/2482

縱觀漏洞從發現到利用整條利用鏈還是相當精彩的，原來 Github Action CI/CD 還能這樣利用，平常審計代碼都是直接跳過 Github Action 的… 又一次感受到公有云的安全難做，有時候這些密鑰真不知道怎么就泄漏出去了。

因此，廣大開發者使用 Github Action 時也請注意，當 workflow 帶有 secret 時，注意避免各種形式讓未授權人員在 Github runner 中執行外部可控的代碼或邏輯，也應該部署 harden-runner?[11]等相關工具，防止以及監測可能的異常 workflow，從而保障開源代碼的安全。

?參考鏈接

[1] https://github.com/Flank/flank

[2] https://adnanthekhan.com/2024/04/15/an-obscure-actions-workflow-vulnerability-in-googles-flank

[3] https://github.com/Flank/flank/pull/1409

[4] https://docs.github.com/zh/actions

[5] https://docs.github.com/zh/actions/security-guides/using-secrets-in-github-actions

[6] https://docs.github.com/zh/enterprise-cloud@latest/actions/security-guides/automatic-token-authentication#about-the-github_token-secret

[7] https://github.com/praetorian-inc/gato

[8] https://github.com/TinderSec/gh-workflow-auditor

[9] https://cycode.com/blog/github-actions-vulnerabilities/

[10] https://docs.gradle.org/current/dsl/index.html

[11] https://github.com/step-security/harden-runner