Translated ['src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Gitblit 安全
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## 什么是 Gitblit
+
+Gitblit 是用 Java 编写的自托管 Git 服务器。它可以作为独立的 JAR 运行或部署在 servlet 容器中，并内置了一个用于 Git over SSH 的 SSH 服务（Apache MINA SSHD）。
+
+## 主题
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## 参考资料
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## 摘要
+
+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）
+
+## 根本原因（SSH 方法之间的状态 leaks）
+
+在 RFC 4252 中，public‑key authentication 分为两个阶段：服务器首先检查提供的公钥是否对该用户名可接受，只有在 challenge/response 与签名之后才真正认证用户。在 MINA SSHD 中，PublickeyAuthenticator 会被调用两次：在 key acceptance（尚无签名）时，以及在客户端返回签名之后。
+
+Gitblit 的 PublickeyAuthenticator 在第一次（前签名）调用时修改了会话上下文：将已识别的 UserModel 绑定到会话并返回 true（"key acceptable"）。当认证随后回退到密码时，PasswordAuthenticator 信任该已被修改的会话状态并直接短路，返回 true 而不验证密码。因此，在同一用户之前发生了公钥 "acceptance" 之后，任意密码（包括空密码）都会被接受。
+
+高层次的错误流程：
+
+1) 客户端提供用户名 + 公钥（尚无签名）
+2) 服务器识别该密钥属于该用户并过早将用户附加到会话，返回 true（"acceptable"）
+3) 客户端无法签名（没有私钥），因此认证回退到密码
+4) 密码认证看到会话中已存在用户并无条件返回成功
+
+## 逐步利用
+
+- 收集受害者的用户名和其中一个公钥：
+- GitHub 在 https://github.com/<username>.keys 暴露公钥
+- 公开服务器通常会暴露 authorized_keys
+- 配置 OpenSSH 仅提供公钥部分以使签名生成失败，从而强制回退到密码，同时仍触发服务器上的公钥接受路径。
+
+Example SSH client config (no private key available):
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+HostName <host-or-ip>
+User <victim-username>
+PubkeyAuthentication yes
+PreferredAuthentications publickey,password
+IdentitiesOnly yes
+IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+连接并在密码提示符处按回车（或输入任意字符串）：
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+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 命令可能会重用已认证的连接，从而增加影响范围。
+
+## 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
+
+## 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
+
+## 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
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: 如果服务器的 public‑key authenticator 在 pre‑signature "key acceptable" 阶段修改了用户/会话状态，而其他 authenticators（例如 password）信任该状态，那么可以通过以下方式绕过认证：
+
+- 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
+- Supplying any password while the password authenticator short‑circuits on leaked state
+
+Practical tips:
+
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
+- MINA SSHD integration pitfalls:
+- PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
+- PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
+
+Related protocol/design notes and literature:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting CI/CD Methodology
+# Pentesting CI/CD 方法论
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,99 +6,102 @@
 
 ## VCS
 
-VCS 代表 **版本控制系统**，该系统允许开发人员 **管理他们的源代码**。最常见的是 **git**，您通常会在以下 **平台** 中找到公司使用它：
+VCS 代表 **Version Control System**，该系统允许开发者**管理他们的源代码**。最常见的是 **git**，你通常会在以下 **platforms** 之一看到公司使用它：
 
 - Github
 - Gitlab
 - Bitbucket
 - Gitea
-- 云提供商（他们提供自己的 VCS 平台）
+- Gitblit
+- Cloud providers (they offer their own VCS platforms)
+
 
 ## CI/CD Pipelines
 
-CI/CD 管道使开发人员能够 **自动执行代码**，用于构建、测试和部署应用程序等各种目的。这些自动化工作流是通过 **特定操作** 触发的，例如代码推送、拉取请求或计划任务。它们有助于简化从开发到生产的过程。
+CI/CD pipelines 使开发者能够**自动执行代码**用于各种目的，包括构建、测试和部署应用。这些自动化工作流会由特定操作触发，例如 code pushes、pull requests 或定时任务。它们有助于简化从开发到生产的流程。
 
-然而，这些系统需要在某处 **执行**，通常需要 **特权凭据来部署代码或访问敏感信息**。
+但是，这些系统需要在某处**被执行**，通常需要**有特权的凭证来部署代码或访问敏感信息**。
 
 ## VCS Pentesting Methodology
 
 > [!NOTE]
-> 即使某些 VCS 平台允许创建管道，在本节中我们将仅分析对源代码控制的潜在攻击。
+> 即使某些 VCS 平台允许为本节创建 pipelines，我们这里将只分析对源码控制的潜在攻击。
 
-包含您项目源代码的平台包含敏感信息，用户需要非常小心在此平台内授予的权限。这些是 VCS 平台上攻击者可能滥用的一些常见问题：
+包含项目源代码的平台承载敏感信息，人员需要非常注意在该平台中授予的权限。以下是攻击者可能滥用的一些常见问题：
 
-- **泄漏**：如果您的代码在提交中包含泄漏，并且攻击者可以访问该仓库（因为它是公开的或因为他有访问权限），他可能会发现这些泄漏。
-- **访问**：如果攻击者可以 **访问 VCS 平台内的帐户**，他可能会获得 **更多的可见性和权限**。
-- **注册**：某些平台只允许外部用户创建帐户。
-- **SSO**：某些平台不允许用户注册，但允许任何人使用有效的 SSO 访问（例如，攻击者可以使用他的 github 帐户进入）。
-- **凭据**：用户名+密码、个人令牌、ssh 密钥、Oauth 令牌、cookies……用户可以窃取多种类型的令牌以某种方式访问仓库。
-- **Webhooks**：VCS 平台允许生成 webhooks。如果它们没有用不可见的秘密 **保护**，则 **攻击者可能会滥用它们**。
-- 如果没有秘密，攻击者可能会滥用第三方平台的 webhook
-- 如果秘密在 URL 中，情况也是如此，攻击者也会拥有秘密
-- **代码妥协**：如果恶意行为者对仓库有某种 **写入** 访问权限，他可能会尝试 **注入恶意代码**。为了成功，他可能需要 **绕过分支保护**。这些操作可以以不同的目标进行：
-- 妥协主分支以 **妥协生产**。
-- 妥协主分支（或其他分支）以 **妥协开发者机器**（因为他们通常在自己的机器上执行测试、terraform 或其他操作）。
-- **妥协管道**（查看下一节）
+- **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 进行保护**，**攻击者可能滥用它们**。
+- 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)
 
 ## Pipelines Pentesting Methodology
 
-定义管道的最常见方法是使用 **托管在仓库中的 CI 配置文件**。该文件描述了执行作业的顺序、影响流程的条件和构建环境设置。\
-这些文件通常具有一致的名称和格式，例如 — Jenkinsfile（Jenkins）、.gitlab-ci.yml（GitLab）、.circleci/config.yml（CircleCI）和位于 .github/workflows 下的 GitHub Actions YAML 文件。当触发时，管道作业 **从选定的源中提取代码**（例如提交/分支），并 **根据 CI 配置文件中指定的命令** 运行该代码。
+定义 pipeline 最常见的方式是使用**托管在仓库中的 CI 配置文件**来描述要执行的作业顺序、影响流程的条件以及构建环境设置。\
+这些文件通常有一致的名称和格式，例如 — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)，以及位于 .github/workflows 下的 GitHub Actions YAML 文件。触发时，pipeline job 会**从选定的源拉取代码**（例如 commit / branch），并**对该代码运行 CI 配置文件中指定的命令**。
 
-因此，攻击者的最终目标是以某种方式 **妥协这些配置文件** 或 **它们执行的命令**。
+因此，攻击者的最终目标是以某种方式**妥协这些配置文件**或**它们执行的命令**。
 
 ### PPE - Poisoned Pipeline Execution
 
-毒化管道执行（PPE）路径利用 SCM 仓库中的权限来操纵 CI 管道并执行有害命令。具有必要权限的用户可以修改 CI 配置文件或管道作业使用的其他文件，以包含恶意命令。这会“毒化” CI 管道，导致这些恶意命令的执行。
+Poisoned Pipeline Execution (PPE) 路径利用 SCM 仓库中的权限来操纵 CI pipeline 并执行有害命令。具有必要权限的用户可以修改将被 pipeline job 执行的 CI 配置文件或 pipeline 使用的其他文件来包含恶意命令。这会“poison” CI pipeline，导致执行这些恶意命令。
 
-为了使恶意行为者成功执行 PPE 攻击，他需要能够：
+为了成功执行 PPE 攻击，恶意行为者需要能够：
 
-- 拥有 **对 VCS 平台的写入访问权限**，因为通常在执行推送或拉取请求时会触发管道。（查看 VCS 渗透测试方法以获取获取访问权限的摘要）。
-- 注意，有时 **外部 PR 计入“写入访问”**。
-- 即使他拥有写入权限，他也需要确保他可以 **修改 CI 配置文件或其他配置所依赖的文件**。
-- 为此，他可能需要能够 **绕过分支保护**。
+- 拥有 **write access to the VCS platform**，因为通常 pipeline 在 push 或 pull request 时被触发。（有关获取访问的方式，请查看 VCS pentesting methodology 的总结）。
+- 注意有时一个 **external PR** 也算作“write access”。
+- 即使拥有写权限，他还需要确保能**修改 CI config 文件或配置所依赖的其他文件**。
+- 为此，他可能需要能够**绕过分支保护**。
 
-有 3 种 PPE 风格：
+PPE 有 3 种变体：
 
-- **D-PPE**：**直接 PPE** 攻击发生在行为者 **修改将要执行的 CI 配置** 文件时。
-- **I-DDE**：**间接 PPE** 攻击发生在行为者 **修改** CI 配置文件所 **依赖的** **文件**（如 make 文件或 terraform 配置）时。
-- **公共 PPE 或 3PE**：在某些情况下，管道可以 **由没有写入访问权限的用户触发**（而且可能甚至不是组织的一部分），因为他们可以发送 PR。
-- **3PE 命令注入**：通常，CI/CD 管道会 **设置环境变量**，其中包含 **有关 PR 的信息**。如果该值可以被攻击者控制（如 PR 的标题），并且在 **危险位置**（如执行 **sh 命令**）中 **使用**，攻击者可能会 **在其中注入命令**。
+- **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**），攻击者可能会在其中**注入命令**。
 
 ### Exploitation Benefits
 
-了解毒化管道的 3 种风格后，让我们检查攻击者在成功利用后可能获得的内容：
+了解了三种 poison pipeline 的变体后，我们来看看攻击者在成功利用后可以获得什么：
 
-- **秘密**：如前所述，管道的作业需要 **特权**（检索代码、构建、部署等……），这些特权通常在秘密中 **授予**。这些秘密通常可以通过 **环境变量或系统内部的文件** 访问。因此，攻击者总是会尝试提取尽可能多的秘密。
-- 根据管道平台，攻击者 **可能需要在配置中指定秘密**。这意味着如果攻击者无法修改 CI 配置管道（例如 **I-PPE**），他可能 **只能提取该管道拥有的秘密**。
-- **计算**：代码在某处执行，具体取决于执行的位置，攻击者可能能够进一步转移。
-- **本地**：如果管道在本地执行，攻击者可能会进入 **内部网络，访问更多资源**。
-- **云**：攻击者可以访问 **云中的其他机器**，还可以 **提取** IAM 角色/服务帐户 **令牌** 以获得 **进一步的云内部访问**。
-- **平台机器**：有时作业将在 **管道平台机器** 内执行，这些机器通常位于没有更多访问权限的云中。
-- **选择它**：有时 **管道平台将配置多个机器**，如果您可以 **修改 CI 配置文件**，则可以 **指示要运行恶意代码的位置**。在这种情况下，攻击者可能会在每台可能的机器上运行反向 shell，以尝试进一步利用。
-- **妥协生产**：如果您在管道内部，并且最终版本是从中构建和部署的，您可能会 **妥协即将在生产中运行的代码**。
+- **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 中运行的代码**。
 
 ## More relevant info
 
 ### Tools & CIS Benchmark
 
-- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) 是一个开源工具，用于审计您的软件供应链堆栈的安全合规性，基于新的 [**CIS 软件供应链基准**](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 流程，可揭示从代码到部署阶段的风险。
 
 ### Top 10 CI/CD Security Risk
 
-查看这篇关于 Cider 的前 10 大 CI/CD 风险的有趣文章：[**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
+查看这篇关于 Cider 所列 CI/CD 前 10 大风险的有趣文章: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
 
 ### Labs
 
-- 在每个平台上，您可以本地运行，您将找到如何本地启动它，以便您可以根据需要进行配置以进行测试
-- Gitea + Jenkins 实验室：[https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
+- 在每个可以本地运行的平台，你会找到如何在本地启动它的说明，这样你可以按需配置以进行测试
+- 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** 是一个用于基础设施即代码的静态代码分析工具。
+- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** 是一个用于 infrastructure-as-code 的静态代码分析工具。
 
 ## References
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
+
 {{#include ../banners/hacktricks-training.md}}