/pulls \
{{#endtabs }}
> [!CAUTION]
-> 请注意，在多个场合中，您可能会在 **Github Actions 的环境变量或秘密中找到 github 用户令牌**。这些令牌可能会让您对仓库和组织拥有更多权限。
+> 请注意，在多个情况下，您可能会在 **Github Actions 的环境变量或秘密中找到 github 用户令牌**。这些令牌可能会让您对存储库和组织拥有更多权限。
@@ -134,7 +144,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
```
-可以通过**检查日志**来查看其他用户仓库中给予Github Token的权限：
+可以通过**检查日志**来查看其他用户仓库中Github Token的权限：
.png)
@@ -143,7 +153,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
> [!NOTE]
> 这是妥协Github actions的最简单方法，因为这种情况假设您有**在组织中创建新仓库的权限**，或对某个仓库有**写权限**。
>
-> 如果您处于这种情况，您可以直接查看[Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action)。
+> 如果您处于这种情况，您可以查看[Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action)。
### 从仓库创建执行
@@ -153,7 +163,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
如果您可以**在已经配置了Github Action的仓库中创建新分支**，您可以**修改**它，**上传**内容，然后**从新分支执行该操作**。这样您可以**提取仓库和组织级别的秘密**（但您需要知道它们的名称）。
-您可以在**手动**时使修改后的操作可执行，当**PR被创建**或**某些代码被推送**时（具体取决于您想要多吵闹）：
+您可以在**手动**、**创建PR时**或**推送某些代码时**使修改后的操作可执行（具体取决于您想要多吵）。
```yaml
on:
workflow_dispatch: # Launch manually
@@ -181,18 +191,18 @@ branches:
> [!NOTE]
> 由于**默认限制**适用于**首次**贡献者，您可以通过**修复有效的错误/拼写错误**来贡献，然后发送**其他PR以滥用您新的`pull_request`权限**。
>
-> **我测试过，这不管用**：~~另一个选项是创建一个与曾经为该项目贡献的人同名的账户，然后删除他的账户。~~
+> **我测试过，这不行**：~~另一个选项是创建一个与曾经为该项目贡献的人同名的账户，然后删除他的账户。~~
此外，默认情况下**防止写权限**和**对目标仓库的秘密访问**，如[**文档**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)中所述：
-> 除了`GITHUB_TOKEN`，**在从**forked**仓库触发工作流时，**秘密不会传递给运行器**。在**forked**仓库的拉取请求中，**`GITHUB_TOKEN`具有只读权限**。
+> 除了`GITHUB_TOKEN`，**在从**forked**仓库触发工作流时，**秘密不会传递给运行器**。在**来自forked仓库的拉取请求中，`GITHUB_TOKEN`具有只读权限**。
攻击者可以修改Github Action的定义，以执行任意操作并附加任意操作。然而，由于上述限制，他将无法窃取秘密或覆盖仓库。
> [!CAUTION]
-> **是的，如果攻击者在PR中更改将被触发的github action，他的Github Action将被使用，而不是源仓库的！**
+> **是的，如果攻击者在PR中更改将被触发的github action，他的Github Action将被使用，而不是源仓库中的那个！**
-由于攻击者还控制着被执行的代码，即使`GITHUB_TOKEN`上没有秘密或写权限，攻击者也可以例如**上传恶意工件**。
+由于攻击者还控制着被执行的代码，即使在`GITHUB_TOKEN`上没有秘密或写权限，攻击者也可以例如**上传恶意工件**。
### **`pull_request_target`**
@@ -201,13 +211,13 @@ branches:
请注意，工作流触发器**`pull_request_target`**在**基础上下文**中运行，而不是在PR提供的上下文中（以**不执行不受信任的代码**）。有关`pull_request_target`的更多信息，请[**查看文档**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)。\
此外，关于这种特定危险用法的更多信息，请查看这篇[**github博客文章**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)。
-看起来因为**执行的工作流**是定义在**基础**中的，而不是在PR中，所以使用**`pull_request_target`**是**安全的**，但有**少数情况是这样**。
+看起来因为**执行的工作流**是定义在**基础**中的而不是在PR中的，所以使用**`pull_request_target`**是**安全的**，但有**一些情况并非如此**。
-而且这个将具有**访问秘密**的权限。
+而且这个将有**访问秘密**的权限。
### `workflow_run`
-[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)触发器允许在不同的工作流`完成`、`请求`或`进行中`时运行工作流。
+[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)触发器允许在工作流`完成`、`请求`或`进行中`时从另一个工作流运行工作流。
在这个例子中，配置了一个工作流，在单独的“运行测试”工作流完成后运行：
```yaml
@@ -217,29 +227,29 @@ workflows: [Run Tests]
types:
- completed
```
-此外，根据文档：由 `workflow_run` 事件启动的工作流能够 **访问机密和写入令牌，即使之前的工作流没有**。
+此外，根据文档：由 `workflow_run` 事件启动的工作流能够 **访问秘密和写入令牌，即使之前的工作流没有**。
-如果这种工作流 **依赖** 于可以通过 **`pull_request`** 或 **`pull_request_target`** 由外部用户 **触发** 的 **工作流**，则可能会受到攻击。一些脆弱的示例可以在 [**这篇博客中找到**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** 第一个示例是 **`workflow_run`** 触发的工作流下载攻击者的代码：`${{ github.event.pull_request.head.sha }}`\
+如果这种工作流 **依赖** 于可以通过 **`pull_request`** 或 **`pull_request_target`** 由外部用户 **触发** 的 **工作流**，则可能会受到攻击。一些脆弱的示例可以在 [**这篇博客**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**中找到。** 第一个示例是 **`workflow_run`** 触发的工作流下载攻击者的代码：`${{ github.event.pull_request.head.sha }}`\
第二个示例是 **将** 一个 **工件** 从 **不受信任** 的代码传递到 **`workflow_run`** 工作流，并以使其 **易受 RCE 攻击** 的方式使用该工件的内容。
### `workflow_call`
TODO
-TODO：检查从 pull_request 执行时使用/下载的代码是否来自原始代码库或来自分叉的 PR
+TODO：检查从 pull_request 执行时使用/下载的代码是否来自原始代码或来自分叉的 PR
## 滥用分叉执行
-我们已经提到外部攻击者可以管理 GitHub 工作流执行的所有方式，现在让我们看看如果这些执行配置不当，可能会如何被滥用：
+我们已经提到外部攻击者如何设法使 GitHub 工作流执行，现在让我们看看如果这些执行配置不当，如何可能被滥用：
### 不受信任的检出执行
-在 **`pull_request`** 的情况下，工作流将在 **PR 的上下文中** 执行（因此它将执行 **恶意 PR 的代码**），但需要有人 **首先授权**，并且它将运行时有一些 [限制](#pull_request)。
+在 **`pull_request`** 的情况下，工作流将在 **PR 的上下文中** 执行（因此它将执行 **恶意 PR 的代码**），但需要有人 **先授权**，并且它将运行时有一些 [限制](#pull_request)。
在使用 **`pull_request_target` 或 `workflow_run`** 的工作流中，如果依赖于可以从 **`pull_request_target` 或 `pull_request`** 触发的工作流，则将执行原始代码库中的代码，因此 **攻击者无法控制执行的代码**。
> [!CAUTION]
-> 但是，如果 **action** 有一个 **显式的 PR 检出**，将 **从 PR 获取代码**（而不是从基础），它将使用攻击者控制的代码。例如（检查第 12 行，其中下载了 PR 代码）：
+> 但是，如果 **action** 有一个 **显式的 PR 检出**，将 **从 PR 获取代码**（而不是从基础），它将使用攻击者控制的代码。例如（查看第 12 行，其中下载了 PR 代码）：
# 不安全。仅作为示例提供。
on:
@@ -266,7 +276,7 @@ arg1: ${{ secrets.supersecret }}
- uses: fakerepo/comment-on-pr@v1
with:
message: |
-Thank you!
+谢谢！
潜在的 **不受信任的代码在 `npm install` 或 `npm build` 期间运行**，因为构建脚本和引用的 **包由 PR 的作者控制**。
@@ -288,19 +298,59 @@ gh-actions-context-script-injections.md
如果攻击者能够 **注入任何值** 到这个 **env** 变量中，他可以注入可以在后续步骤中执行代码的环境变量，例如 **LD_PRELOAD** 或 **NODE_OPTIONS**。
-例如（[**这个**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) 和 [**这个**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)），想象一个工作流信任上传的工件将其内容存储在 **`GITHUB_ENV`** 环境变量中。攻击者可以上传类似这样的内容来破坏它：
+例如 ([**这个**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) 和 [**这个**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project))，想象一个工作流信任上传的工件将其内容存储在 **`GITHUB_ENV`** 环境变量中。攻击者可以上传类似这样的内容来破坏它：
.png)
-### 脆弱的第三方 GitHub Actions
+### Dependabot 和其他受信任的机器人
+
+正如在 [**这篇博客文章**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest) 中所述，多个组织有一个 GitHub Action，可以合并来自 `dependabot[bot]` 的任何 PRR，例如：
+```yaml
+on: pull_request_target
+jobs:
+auto-merge:
+runs-on: ubuntu-latest
+if: ${ { github.actor == 'dependabot[bot]' }}
+steps:
+- run: gh pr merge $ -d -m
+```
+这是一个问题，因为 `github.actor` 字段包含了导致触发工作流的最新事件的用户。而有几种方法可以让 `dependabot[bot]` 用户修改 PR。例如：
+
+- Fork 受害者的仓库
+- 将恶意负载添加到你的副本中
+- 在你的 fork 上启用 Dependabot，添加一个过时的依赖项。Dependabot 将创建一个修复依赖项的分支，并包含恶意代码。
+- 从该分支向受害者的仓库打开一个 Pull Request（PR 将由用户创建，因此尚未发生任何事情）
+- 然后，攻击者返回到他在 fork 中打开的初始 PR，并运行 `@dependabot recreate`
+- 然后，Dependabot 在该分支上执行一些操作，修改了受害者仓库上的 PR，这使得 `dependabot[bot]` 成为触发工作流的最新事件的执行者（因此，工作流运行）。
+
+接下来，如果 Github Action 不是合并，而是像下面这样有命令注入：
+```yaml
+on: pull_request_target
+jobs:
+just-printing-stuff:
+runs-on: ubuntu-latest
+if: ${ { github.actor == 'dependabot[bot]' }}
+steps:
+- run: echo ${ { github.event.pull_request.head.ref }}
+```
+原始博客文章提出了两种利用这种行为的选项，第二个选项是：
+
+- 复制受害者的仓库并启用 Dependabot，使用一些过时的依赖项。
+- 创建一个包含恶意 shell 注入代码的新分支。
+- 将仓库的默认分支更改为该分支。
+- 从该分支向受害者仓库创建一个 PR。
+- 在 PR 中运行 `@dependabot merge`，这是 Dependabot 在他的分支中打开的。
+- Dependabot 将在你复制的仓库的默认分支中合并他的更改，更新受害者仓库中的 PR，使得 `dependabot[bot]` 成为触发工作流的最新事件的执行者，并使用恶意的分支名称。
+
+### 易受攻击的第三方 Github Actions
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
-正如在 [**这篇博客文章**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) 中提到的，这个 GitHub Action 允许访问来自不同工作流甚至不同代码库的工件。
+正如在 [**这篇博客文章**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) 中提到的，这个 Github Action 允许访问来自不同工作流甚至仓库的工件。
-问题在于，如果 **`path`** 参数未设置，工件将提取到当前目录中，并且可能会覆盖后续在工作流中使用或执行的文件。因此，如果工件存在漏洞，攻击者可以利用这一点来破坏其他信任该工件的工作流。
+问题在于，如果 **`path`** 参数未设置，工件将提取到当前目录中，并且可能会覆盖后续在工作流中使用或执行的文件。因此，如果工件存在漏洞，攻击者可以利用这一点来妥协其他信任该工件的工作流。
-脆弱工作流的示例：
+易受攻击的工作流示例：
```yaml
on:
workflow_run:
@@ -347,9 +397,9 @@ path: ./script.py
如果一个账户更改了名称，其他用户在一段时间后可以注册一个相同名称的账户。如果一个仓库在更改名称之前的**星标少于100个**，Github将允许新注册的用户使用相同的名称创建一个**与被删除的仓库同名的仓库**。
> [!CAUTION]
-> 因此，如果一个操作使用来自不存在账户的仓库，攻击者仍然有可能创建该账户并妥协该操作。
+> 因此，如果一个操作使用来自一个不存在账户的仓库，攻击者仍然有可能创建该账户并妥协该操作。
-如果其他仓库使用了**该用户仓库的依赖项**，攻击者将能够劫持它们。这里有一个更完整的解释：[https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+如果其他仓库使用了**该用户仓库的依赖项**，攻击者将能够劫持它们。这里有一个更完整的解释: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
---
@@ -392,7 +442,7 @@ gh-actions-artifact-poisoning.md
### 访问秘密
-如果您正在向脚本中注入内容，了解如何访问秘密是很有趣的：
+如果你正在向脚本中注入内容，了解如何访问秘密是很有趣的：
- 如果秘密或令牌被设置为**环境变量**，可以通过环境直接使用**`printenv`**访问。
@@ -466,7 +516,7 @@ key: ${{ secrets.PUBLISH_KEY }}
### 滥用自托管运行器
-查找**在非 GitHub 基础设施中执行的 Github Actions**的方法是搜索 Github Action 配置 yaml 中的**`runs-on: self-hosted`**。
+查找**在非 GitHub 基础设施中执行的 GitHub Actions**的方法是搜索 GitHub Action 配置 yaml 中的**`runs-on: self-hosted`**。
**自托管**运行器可能访问**额外的敏感信息**，访问其他**网络系统**（网络中的脆弱端点？元数据服务？）或者，即使它是隔离和销毁的，**可能会同时运行多个操作**，恶意操作可能会**窃取其他操作的秘密**。
@@ -530,24 +580,15 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
### Github Actions 日志中的敏感信息
-即使 **Github** 尝试 **检测日志中的秘密值** 并 **避免显示** 它们，**其他敏感数据** 在执行操作时生成的内容仍然不会被隐藏。例如，使用秘密值签名的 JWT 除非 [特别配置](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)，否则不会被隐藏。
+即使 **Github** 尝试 **检测操作日志中的秘密值** 并 **避免显示** 它们，**其他敏感数据** 在操作执行过程中生成的内容仍然不会被隐藏。例如，使用秘密值签名的 JWT 除非 [特别配置](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)，否则不会被隐藏。
## 掩盖你的痕迹
-（来自 [**这里**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) 的技术）首先，任何提出的 PR 在 Github 上对公众和目标 GitHub 账户都是明显可见的。在 GitHub 中，默认情况下，我们 **无法删除互联网上的 PR**，但有一个变数。对于被 Github **暂停** 的 GitHub 账户，所有的 **PR 会被自动删除** 并从互联网上移除。因此，为了隐藏你的活动，你需要让你的 **GitHub 账户被暂停或被标记**。这将 **隐藏你在 GitHub 上的所有活动**（基本上移除你所有的利用 PR）
+（来自 [**这里**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit) 的技术）首先，任何提出的 PR 在 Github 上对公众和目标 GitHub 账户都是明显可见的。在 GitHub 中，默认情况下，我们 **无法删除互联网上的 PR**，但有一个变数。对于被 Github **暂停** 的 GitHub 账户，所有的 **PR 会自动被删除** 并从互联网上移除。因此，为了隐藏你的活动，你需要让你的 **GitHub 账户被暂停或被标记**。这将 **隐藏你在 GitHub 上的所有活动**（基本上移除你所有的利用 PR）
-GitHub 中的一个组织非常积极地向 GitHub 举报账户。你所需要做的就是在 Issue 中分享“某些东西”，他们会确保你的账户在 12 小时内被暂停 :p 这样你就可以让你的利用在 GitHub 上变得不可见。
+GitHub 中的一个组织非常积极地向 GitHub 举报账户。你所需要做的就是在 Issue 中分享“某些内容”，他们会确保你的账户在 12 小时内被暂停 :p 这样你就可以让你的利用在 GitHub 上变得不可见。
> [!WARNING]
> 组织发现自己被针对的唯一方法是通过 SIEM 检查 GitHub 日志，因为从 GitHub UI 中 PR 会被移除。
-## 工具
-
-以下工具对于查找 GitHub Action 工作流甚至找到易受攻击的工作流非常有用：
-
-- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
-- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
-- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
-- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-
{{#include ../../../banners/hacktricks-training.md}}
.png)