Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,20 +1,20 @@
-# Abusing Github Actions
+# 滥用 Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## 基本信息
 
 在此页面中，您将找到：
 
 - 攻击者成功访问 Github Action 的所有影响的 **摘要**
-- 不同的 **获取访问权限** 的方式：
-- 拥有 **创建 action** 的 **权限**
-- 滥用与 **pull request** 相关的触发器
+- 获取 **访问一个 action** 的不同方式：
+- 拥有 **创建 action** 的权限
+- 滥用与 **拉取请求** 相关的触发器
 - 滥用 **其他外部访问** 技术
-- 从已被攻陷的仓库进行 **横向移动**
-- 最后，关于 **从内部滥用 action 的后期利用技术** 的一节（导致上述影响）
+- 从已经被攻陷的仓库 **进行横向渗透**
+- 最后，关于 **从内部滥用 action 的后渗透技术** 的一节（因为提到的影响）
 
-## Impacts Summary
+## 影响摘要
 
 有关 [**Github Actions 的基本信息**](../basic-github-information.md#github-actions) 的介绍。
 
@@ -23,7 +23,7 @@
 - **窃取秘密**，并 **滥用管道的权限** 以获得对外部平台（如 AWS 和 GCP）的未授权访问。
 - **破坏部署** 和其他 **工件**。
 - 如果管道部署或存储资产，您可以更改最终产品，从而启用供应链攻击。
-- **在自定义工作节点中执行代码**，以滥用计算能力并横向移动到其他系统。
+- **在自定义工作节点中执行代码**，以滥用计算能力并横向渗透到其他系统。
 - **覆盖仓库代码**，具体取决于与 `GITHUB_TOKEN` 相关的权限。
 
 ## GITHUB_TOKEN
@@ -32,20 +32,20 @@
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-此令牌与 **Github 应用程序使用的令牌相同**，因此可以访问相同的端点：[https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
+这个令牌与 **Github 应用程序使用的令牌** 相同，因此可以访问相同的端点：[https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
 
 > [!WARNING]
 > Github 应该发布一个 [**流程**](https://github.com/github/roadmap/issues/74)，**允许跨仓库** 访问 GitHub，以便一个仓库可以使用 `GITHUB_TOKEN` 访问其他内部仓库。
 
-您可以在以下链接查看此令牌的可能 **权限**：[https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
+您可以在以下位置查看此令牌的可能 **权限**：[https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
 
 请注意，令牌 **在作业完成后会过期**。\
-这些令牌的格式如下：`ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
+这些令牌看起来像这样：`ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
 
-您可以使用此令牌执行的一些有趣操作：
+您可以使用此令牌做一些有趣的事情：
 
 {{#tabs }}
-{{#tab name="Merge PR" }}
+{{#tab name="合并 PR" }}
 ```bash
 # Merge PR
 curl -X PUT \
@@ -141,9 +141,9 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ## 允许的执行
 
 > [!NOTE]
-> 这是妥协Github actions的最简单方法，因为这种情况假设您有**在组织中创建新仓库的权限**，或对**某个仓库具有写权限**。
+> 这是妥协Github actions的最简单方法，因为这种情况假设您有**在组织中创建新仓库的权限**，或对某个仓库有**写入权限**。
 >
-> 如果您处于这种情况，您可以查看[后期利用技术](./#post-exploitation-techniques-from-inside-an-action)。
+> 如果您处于这种情况，您可以查看[Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action)。
 
 ### 从仓库创建执行
 
@@ -153,7 +153,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 
 如果您可以**在已经配置了Github Action的仓库中创建新分支**，您可以**修改**它，**上传**内容，然后**从新分支执行该操作**。这样您可以**提取仓库和组织级别的秘密**（但您需要知道它们的名称）。
 
-您可以在**手动**时使修改后的操作可执行，当**创建PR时**或当**推送某些代码时**（取决于您想要多吵）：
+您可以在**手动**时使修改后的操作可执行，当**PR被创建**或当**某些代码被推送**时（具体取决于您想要多吵闹）：
 ```yaml
 on:
 workflow_dispatch: # Launch manually
@@ -181,16 +181,16 @@ 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 repositories**的拉取请求中，**`GITHUB_TOKEN`具有只读权限**。
+> 除了`GITHUB_TOKEN`，**在从**forked**仓库触发工作流时，**秘密不会传递给运行器**。在来自**forked**仓库的拉取请求中，**`GITHUB_TOKEN`具有只读权限**。
 
 攻击者可以修改Github Action的定义，以执行任意操作并附加任意操作。然而，由于上述限制，他将无法窃取秘密或覆盖仓库。
 
 > [!CAUTION]
-> **是的，如果攻击者在PR中更改将被触发的github action，他的Github Action将被使用，而不是源仓库的那个！**
+> **是的，如果攻击者在PR中更改将被触发的github action，他的Github Action将被使用，而不是来自源仓库的那个！**
 
 由于攻击者还控制着被执行的代码，即使在`GITHUB_TOKEN`上没有秘密或写权限，攻击者也可以例如**上传恶意工件**。
 
@@ -201,7 +201,7 @@ 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`**是**安全的**，但有**一些情况并非如此**。
 
 而且这个将具有**对秘密的访问**。
 
@@ -217,16 +217,16 @@ 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 }}`\
-第二个示例是 **将** 一个 **工件** 从 **不受信任** 的代码传递到 **`workflow_run`** 工作流，并以使其 **易受 RCE 攻击** 的方式使用该工件的内容。
+如果这种工作流 **依赖** 于可以通过 **`pull_request`** 或 **`pull_request_target`** 由外部用户 **触发** 的 **工作流**，则可能会受到攻击。一些脆弱的示例可以在 [**这篇博客**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**中找到。** 第一个示例是 **`workflow_run`** 触发的工作流下载攻击者的代码：`${{ github.event.pull_request.head.sha }}`\
+第二个示例是 **将** 来自 **不受信任** 代码的 **artifact** 传递给 **`workflow_run`** 工作流，并以使其 **易受 RCE 攻击** 的方式使用该 artifact 的内容。
 
 ### `workflow_call`
 
 TODO
 
-TODO：检查从 pull_request 执行时使用/下载的代码是否来自原始或分叉的 PR
+TODO：检查从 pull_request 执行时使用/下载的代码是否来自原始代码库或来自分叉的 PR
 
 ## 滥用分叉执行
 
@@ -234,9 +234,9 @@ TODO：检查从 pull_request 执行时使用/下载的代码是否来自原始
 
 ### 不受信任的检出执行
 
-在 **`pull_request`** 的情况下，工作流将在 **PR 的上下文中** 执行（因此它将执行 **恶意 PR 的代码**），但需要有人 **先授权**，并且它将运行时有一些 [限制](./#pull_request)。
+在 **`pull_request`** 的情况下，工作流将在 **PR 的上下文中** 执行（因此它将执行 **恶意 PR 的代码**），但需要有人 **首先授权**，并且它将运行时有一些 [限制](./#pull_request)。
 
-如果工作流使用 **`pull_request_target` 或 `workflow_run`**，并依赖于可以从 **`pull_request_target` 或 `pull_request`** 触发的工作流，则将执行原始仓库中的代码，因此 **攻击者无法控制执行的代码**。
+如果工作流使用 **`pull_request_target` 或 `workflow_run`**，并依赖于可以从 **`pull_request_target` 或 `pull_request`** 触发的工作流，则将执行原始代码库中的代码，因此 **攻击者无法控制执行的代码**。
 
 > [!CAUTION]
 > 但是，如果 **action** 有一个 **显式的 PR 检出**，将 **从 PR 获取代码**（而不是从基础），它将使用攻击者控制的代码。例如（检查第 12 行，其中下载了 PR 代码）：
@@ -269,14 +269,14 @@ message: |
 谢谢！
 </code></pre>
 
-潜在的 **不受信任的代码在 `npm install` 或 `npm build` 期间被运行**，因为构建脚本和引用的 **包由 PR 的作者控制**。
+潜在的 **不受信任的代码在 `npm install` 或 `npm build` 期间运行**，因为构建脚本和引用的 **包由 PR 的作者控制**。
 
 > [!WARNING]
 > 搜索脆弱 actions 的 GitHub dork 是：`event.pull_request pull_request_target extension:yml`，但是，即使 action 配置不安全，也有不同的方法可以安全地配置要执行的作业（例如，使用关于谁是生成 PR 的参与者的条件）。
 
 ### 上下文脚本注入 <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
 
-请注意，有某些 [**GitHub 上下文**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) 的值是由创建 PR 的 **用户** **控制** 的。如果 GitHub action 使用该 **数据执行任何操作**，可能会导致 **任意代码执行：**
+请注意，有某些 [**GitHub 上下文**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context)，其值由创建 PR 的 **用户** **控制**。如果 GitHub action 使用该 **数据执行任何操作**，则可能导致 **任意代码执行：**
 
 {{#ref}}
 gh-actions-context-script-injections.md
@@ -286,9 +286,9 @@ gh-actions-context-script-injections.md
 
 根据文档：您可以通过定义或更新环境变量并将其写入 **`GITHUB_ENV`** 环境文件，使 **环境变量可用于工作流作业中的任何后续步骤**。
 
-如果攻击者能够 **在此 env 变量中注入任何值**，他可以注入可以在后续步骤中执行代码的 env 变量，例如 **LD_PRELOAD** 或 **NODE_OPTIONS**。
+如果攻击者能够 **注入任何值** 到这个 **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`** 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)），想象一个工作流信任上传的 artifact 将其内容存储在 **`GITHUB_ENV`** 环境变量中。攻击者可以上传类似这样的内容来破坏它：
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
@@ -296,9 +296,9 @@ gh-actions-context-script-injections.md
 
 #### [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 允许访问来自不同工作流甚至不同代码库的 artifacts。
 
-问题在于，如果 **`path`** 参数未设置，工件将提取到当前目录，并且可能会覆盖后续在工作流中使用或执行的文件。因此，如果工件是脆弱的，攻击者可以利用这一点来破坏其他信任该工件的工作流。
+问题在于，如果 **`path`** 参数未设置，artifact 将提取到当前目录，并且可能会覆盖稍后在工作流中使用或执行的文件。因此，如果 artifact 存在漏洞，攻击者可以利用这一点来破坏其他信任该 artifact 的工作流。
 
 脆弱工作流的示例：
 ```yaml
@@ -323,7 +323,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-这可以通过以下工作流进行攻击：
+这可以通过以下工作流程进行攻击：
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -344,12 +344,12 @@ path: ./script.py
 
 ### 删除的命名空间仓库劫持
 
-如果一个账户更改了名称，其他用户在一段时间后可以注册一个相同名称的账户。如果一个仓库在更改名称之前的**星标少于100个**，Github将允许新注册的用户使用相同的名称创建一个**与被删除的仓库同名的仓库**。
+如果一个账户更改了名称，其他用户在一段时间后可以注册一个具有该名称的账户。如果一个仓库在更改名称之前的**星标少于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/)
 
 ---
 
@@ -360,7 +360,7 @@ path: ./script.py
 
 ### 缓存中毒
 
-在**同一分支的工作流运行之间**维护一个缓存。这意味着如果攻击者**妥协**了一个**包**，然后将其存储在缓存中，并被**更高权限的**工作流**下载**和执行，他将能够**妥协**该工作流。
+在**同一分支的工作流运行之间**维护一个缓存。这意味着如果攻击者**妥协**了一个**包**，然后将其存储在缓存中，并被**更高权限**的工作流**下载**和执行，他将能够**妥协**该工作流。
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -368,7 +368,7 @@ gh-actions-cache-poisoning.md
 
 ### 工件中毒
 
-工作流可以使用**来自其他工作流甚至仓库的工件**，如果攻击者设法**妥协**了上传工件的Github Action，而该工件随后被另一个工作流使用，他可以**妥协其他工作流**：
+工作流可以使用**其他工作流甚至仓库的工件**，如果攻击者设法**妥协**了上传工件的Github Action，而该工件随后被另一个工作流使用，他可以**妥协其他工作流**：
 
 {{#ref}}
 gh-actions-artifact-poisoning.md
@@ -394,7 +394,7 @@ gh-actions-artifact-poisoning.md
 
 如果您正在向脚本中注入内容，了解如何访问秘密是很有趣的：
 
-- 如果秘密或令牌被设置为**环境变量**，可以通过环境直接使用**`printenv`**访问。
+- 如果秘密或令牌被设置为**环境变量**，可以通过**`printenv`**直接通过环境访问。
 
 <details>
 
@@ -468,7 +468,7 @@ key: ${{ secrets.PUBLISH_KEY }}
 
 查找**在非 GitHub 基础设施中执行的 GitHub Actions**的方法是搜索 GitHub Action 配置 yaml 中的**`runs-on: self-hosted`**。
 
-**自托管**运行器可能访问**额外的敏感信息**，访问其他**网络系统**（网络中的脆弱端点？元数据服务？）或者，即使它是隔离和销毁的，**可能会同时运行多个操作**，恶意操作可能会**窃取其他操作的秘密**。
+**自托管**运行器可能访问**额外敏感信息**，访问其他**网络系统**（网络中的脆弱端点？元数据服务？）或者，即使它是隔离和销毁的，**可能会同时运行多个操作**，恶意操作可能会**窃取其他操作的秘密**。
 
 在自托管运行器中，还可以通过转储其内存来获取**来自 \_Runner.Listener**\_\*\* 进程\*\* 的**秘密**，该进程将在任何步骤中包含工作流的所有秘密：
 ```bash
@@ -517,7 +517,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 
 正如您在之前的代码中看到的，Github 注册表托管在 **`ghcr.io`**。
 
-具有对该仓库的读取权限的用户将能够使用个人访问令牌下载 Docker 镜像：
+具有对仓库的读取权限的用户将能够使用个人访问令牌下载 Docker 镜像：
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
@@ -530,13 +530,13 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
 
 ### 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 会被移除。