Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains

2026-02-05 19:32:24 -08:00 · 2025-01-11 19:15:25 +00:00
parent ff0b5cc7b1
commit ac2302610e
44 changed files with 1984 additions and 408 deletions
--- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
+++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md
@@ -11,7 +11,7 @@
 - 拥有 **创建 action** 的权限
 - 滥用与 **拉取请求** 相关的触发器
 - 滥用 **其他外部访问** 技术
- 从已经被攻陷的仓库 **进行横向渗透**
+- 从已被攻陷的仓库 **进行横向渗透**
 - 最后，关于 **从内部滥用 action 的后渗透技术** 的一节（因为提到的影响）

 ## 影响摘要
@@ -28,11 +28,11 @@

 ## GITHUB_TOKEN

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

 <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` 访问其他内部仓库。
@@ -56,7 +56,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
 -d "{\"commit_title\":\"commit_title\"}"
 ```
 {{#endtab }}
-{{#tab name="批准 PR" }}
+{{#tab name="Approve PR" }}
 ```bash
 # Approve a PR
 curl -X POST \
@@ -81,7 +81,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
 {{#endtabs }}

 > [!CAUTION]
-> 请注意，在多个情况下，您将能够在 **Github Actions 环境或秘密中找到 github 用户令牌**。这些令牌可能会让您对存储库和组织拥有更多权限。
+> 请注意，在多个场合中，您可能会在 **Github Actions 的环境变量或秘密中找到 github 用户令牌**。这些令牌可能会让您对仓库和组织拥有更多权限。

 <details>

@@ -134,16 +134,16 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 ```
 </details>

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

 <figure><img src="../../../images/image (286).png" alt="" width="269"><figcaption></figcaption></figure>

 ## 允许的执行

 > [!NOTE]
-> 这是妥协Github actions的最简单方法，因为这种情况假设您有**在组织中创建新仓库的权限**，或对某个仓库有**写入权限**。
+> 这是妥协Github actions的最简单方法，因为这种情况假设您有**在组织中创建新仓库的权限**，或对某个仓库有**写权限**。
 >
-> 如果您处于这种情况，您可以查看[Post Exploitation techniques](./#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,33 +181,33 @@ 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`**

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

-请注意，工作流触发器**`pull_request_target`**在基础上下文中运行，而不是在PR提供的上下文中（以**不执行不受信任的代码**）。有关`pull_request_target`的更多信息，请[**查看文档**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)。\
+请注意，工作流触发器**`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,10 +217,10 @@ 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 }}`\
-第二个示例是 **将** 来自 **不受信任** 代码的 **artifact** 传递给 **`workflow_run`** 工作流，并以使其 **易受 RCE 攻击** 的方式使用该 artifact 的内容。
+如果这种工作流 **依赖** 于可以通过 **`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`

@@ -230,13 +230,13 @@ TODO：检查从 pull_request 执行时使用/下载的代码是否来自原始

 ## 滥用分叉执行

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

 ### 不受信任的检出执行

-在 **`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 代码）：
@@ -266,7 +266,7 @@ arg1: ${{ secrets.supersecret }}
 - uses: fakerepo/comment-on-pr@v1
 with:
 message: |
-谢谢！
+Thank you!
 </code></pre>

 潜在的 **不受信任的代码在 `npm install` 或 `npm build` 期间运行**，因为构建脚本和引用的 **包由 PR 的作者控制**。
@@ -276,7 +276,7 @@ message: |

 ### 上下文脚本注入 <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
@@ -288,7 +288,7 @@ 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)），想象一个工作流信任上传的 artifact 将其内容存储在 **`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`** 环境变量中。攻击者可以上传类似这样的内容来破坏它：

 <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 允许访问来自不同工作流甚至不同代码库的 artifacts。
+正如在 [**这篇博客文章**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) 中提到的，这个 GitHub Action 允许访问来自不同工作流甚至不同代码库的工件。

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

 脆弱工作流的示例：
 ```yaml
@@ -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/)

 ---

@@ -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>

@@ -466,9 +466,9 @@ key: ${{ secrets.PUBLISH_KEY }}

 ### 滥用自托管运行器

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

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

 在自托管运行器中，还可以通过转储其内存来获取**来自 \_Runner.Listener**\_\*\* 进程\*\* 的**秘密**，该进程将在任何步骤中包含工作流的所有秘密：
 ```bash
@@ -484,7 +484,7 @@ sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ prin

 <details>

-<summary>Github Action 构建 &#x26; 推送 Docker 镜像</summary>
+<summary>Github Action 构建和推送 Docker 镜像</summary>
 ```yaml
 [...]

@@ -525,12 +525,12 @@ docker pull ghcr.io/<org-name>/<repo_name>:<tag>
 然后，用户可以搜索 **Docker 镜像层中的泄露秘密：**

 {{#ref}}
-https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
 {{#endref}}

 ### 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)，否则不会被隐藏。

 ## 掩盖你的痕迹

@@ -543,7 +543,7 @@ GitHub 中的一个组织非常积极地向 GitHub 举报账户。你所需要

 ## 工具

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

 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)