本文作者：

tari，首批 CSA CCPTP 认证专家、CSA 大中华区云渗透测试工作组成员

审校：

李鑫，CSA大中华区云渗透测试工作组组长

梁嘉荣，CSA大中华区研究协调员

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 目录大家应该挺眼熟的，但一般我们都会忽略不太起眼的它，因为一般它不会存在什么特别的安全漏洞，但本文的重点就是里面的 workflow 。

 workflow 触发的方式很多，比如在 git push 代码到仓库时触发，亦或是在创建代码合并请求（Pull Request，下文简称 PR ）触发等，触发后通过 Github Runner（执行器） 去执行相应的 workflow ，触发等方式多种多样，触发方式写法一般如下：

上下 workflow 即是在代码 push 到 main 分支或者是 PR 入 main 时触发，运行结果输出 Hello World 

在本漏洞中，通过在 PR 评论区回复特定关键字触发存在漏洞的 workflow 。

关于 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 的序号，

即此时会切换到我们 PR 的代码，但此时它仍然没有拼接任何东西。特别是对于自动化工具而言，这里根本就不会检测出来，因为没有拼接可控的东西。由于 Github 上的 workflow 太多，一个个找和看，其实是不好找出来的。就像我们看存在问题的 workflow，一下子我们也没能太看出来存在什么问题，这就是为啥这个漏洞存在这么久才被发现。

原作者检测工具的设计目的就不太一样，他是扫描存在触发风险点的地方，然后在回过头来看是不是误报，尽管有接近70%的是误报。

在看整个 workflow 文件，在项目 PR 评论区回复 @flank-it 会触发 should_run_it  job，这个 job env 带有 GITHUB_TOKEN secret，并且该 token 有该项目的写权限（如果没有该项目的写权限，这个在评论区加个眼睛 👀 的 emoji 是加不上的）

然后 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

复现环境的项目配置（自己搭建就需要注意下，免得踩坑）：

• secret 记得 base64编码一下，不然解码会失败

正常情况下利用，由于非项目成员，看不到运行结果，所以需要用 curl 外带

就得到 GCLOUD_KEY 和 GITHUB_TOKEN

base64解码得 flag{GCLOUD_KEY} 

接下来，我们拿到具有写权限的 Github_TOKEN 就可以发布 release 附件了，一般项目都会有 release，所以我们先创建一个 release，创建好标签命名完标题保存即可

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

该漏洞的修复，官方去除了在 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

[12] https://docs.github.com/zh/rest?apiVersion=2022-11-28

CSA CCPTP云渗透课程详情介绍

CCPTP（Certifified Cloud Penetration Test Professional）云渗透测试认证专家，旨在提供针对云计算渗透测试所需的专业实操技能，弥补云渗透测试认知的差距和技能人才培养的空白，提升专业人员能力及提供认证证书，为云计算产业发展提供渗透人才队伍保障。认证课程包含了云渗透测试知识体系、测试流程、实践技术、法律法规、渗透测试人员道德规范、渗透测试方法论 以及实操技术等内容。

课程对象：适用于渗透测试人员、安全评估人员、信息安全管理人员和其他对云计算安全有兴趣的人员等，需具备一定的云计算、云安全或渗透测试的基础知识。

课程目标：通过CCPTP课程学习，要求学员系统掌握如何开展云计算下的渗透测试工作，在云上授权目标系统中寻找弱点和漏洞，并以合法的方式评估目标系统的安全状态，同时针对相关的弱点和漏洞要能提供有效的安全改进或加固建议。

>01

熟练掌握常见云服务模型（IaaS、PaaS、SaaS）测试方法及主流云平台在租户视角的最佳安全实践，包括但不限于租户上云的安全架构设计、租户安全基线配置、安全加固知识，例如合理规划账号IAM规划设计、VPC规划、安全组设计、镜像安全、云存储安全、安全组策略等。

>02

要求熟练掌握针对主流云平台云租户视角的渗透测试。基于攻击面的暴露程度，按照从云上资产发现与信息收集阶段开始，依照云上租户应用层至云底层基础设施层的层级顺序，学习相关的渗透测试方法、测试工具，并具备渗透测试的实操能力。

>03

 根据渗透测试的情况撰写专业的云渗透测试报告（报告内容包括但不限于漏洞证明过程、修复或安全加固建议）。