Basic Jenkins Information

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 subscription plans!

加入 💬 Discord group 或者 telegram group 或关注我们的 Twitter 🐦 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud github 仓库提交 PRs 来分享 hacking tricks。

Access

Username + Password

在 Jenkins 中最常见的登录方式是使用用户名或密码

如果一个 authorized cookie gets stolen，它可以用来访问该用户的会话。该 cookie 通常称为 JSESSIONID.*。（用户可以终止他所有的会话，但他首先需要发现 cookie 被盗。）

SSO/Plugins

Jenkins 可以通过 plugins 配置为 通过第三方 SSO 访问。

Tokens

Users can generate tokens 来允许应用以他们的身份通过 CLI 或 REST API 访问。

SSH Keys

该组件为 Jenkins 提供了内置的 SSH server。它是 Jenkins CLI 的一种替代接口，可以使用任意 SSH 客户端以这种方式调用命令。（摘自 docs）

Authorization

在 /configureSecurity 中可以 配置 Jenkins 的授权方法。有几种选项：

Anyone can do anything：即使是 anonymous 访问也可以管理服务器
Legacy mode：与 Jenkins <1.164 相同。如果你有 “admin” role，你将被授予对系统的 full control，否则（包括 anonymous 用户）你将只有 read 访问权限。
Logged-in users can do anything：在此模式下，所有 已登录用户都获得 Jenkins 的 full control。唯一不会拥有 full control 的用户是 anonymous user，其仅具有 read access。
Matrix-based security：你可以在一个表格中配置 谁可以做什么。每一列代表一个 permission。每一行代表一个 user 或 group/role。这包括一个特殊用户 ‘anonymous’，代表 未认证用户，以及 ‘authenticated’，代表 所有已认证用户。

Project-based Matrix Authorization Strategy: 此模式是对 “Matrix-based security” 的扩展，允许为每个项目单独 定义额外的 ACL 矩阵。
Role-Based Strategy: 允许使用 基于角色的策略 来定义授权。在 /role-strategy 管理这些角色。

Security Realm

在 /configureSecurity 中可以 配置 security realm。 默认情况下 Jenkins 支持几种不同的 Security Realms：

Delegate to servlet container：用于 将认证委托给运行 Jenkins controller 的 servlet container，例如 Jetty。
Jenkins’ own user database: 使用 Jenkins 内置的用户数据存储 进行认证，而不是委托给外部系统。此项默认启用。
LDAP：将所有认证委托给已配置的 LDAP server，包括用户和组。
Unix user/group database：将认证委托给 Jenkins controller 所在主机的底层 Unix 操作系统级别用户数据库。此模式还允许重用 Unix 组来做授权。

Plugins 可以提供额外的 security realms，对于将 Jenkins 整合进现有身份系统可能很有用，例如：

Jenkins Nodes, Agents & Executors

Definitions from the docs:

Nodes 是运行 build agents 的机器。Jenkins 监控每个已连接节点的磁盘空间、可用临时空间、可用 swap、时钟时间/同步和响应时间。如果这些值中的任何一个超出配置阈值，则节点会被下线。

Agents 通过 使用 executors 代表 Jenkins controller 管理任务执行。agent 可以使用任何支持 Java 的操作系统。构建和测试所需的工具安装在 agent 运行的节点上；它们可以 直接安装或在容器中（Docker 或 Kubernetes）。每个 agent 在宿主机上本质上是一个具有自己 PID 的进程。

executor 是用于执行任务的槽位；本质上，它是 agent 中的一个线程。一个节点上的 executor 数量 定义了该节点一次可以并发执行的 任务数量。换句话说，这决定了在该节点上一次可以并发执行的 Pipeline stages 的数量。

Definition from the docs: Jenkins 使用 AES 来加密和保护 secrets、credentials 及其各自的加密密钥。这些加密密钥与用于保护这些密钥的 master key 一起存储在 $JENKINS_HOME/secrets/。应该配置该目录，使得只有运行 Jenkins controller 的操作系统用户对该目录具有读写权限（即 chmod 值为 0700 或使用适当的文件属性）。master key（在加密术语中有时称为 “key encryption key”）以未加密形式存储在 Jenkins controller 的文件系统中，位于 $JENKINS_HOME/secrets/master.key，这并不能防止直接访问该文件的攻击者。大多数用户和开发者会通过 Secret API 来间接使用这些加密密钥以加密通用 secret 数据，或通过 credentials API。对于喜欢研究加密的读者，Jenkins 使用 AES 在 cipher block chaining (CBC) 模式下，带 PKCS#5 padding 和随机 IVs，加密存储在 $JENKINS_HOME/secrets/ 中的 CryptoConfidentialKey 实例，文件名对应其 CryptoConfidentialKey id。常见的 key ids 包括：

hudson.util.Secret: 用于通用 secrets；
com.cloudbees.plugins.credentials.SecretBytes.KEY: 用于某些类型的 credentials；
jenkins.model.Jenkins.crumbSalt: 被 CSRF protection mechanism 使用；以及

Credentials Access

Credentials 可以 作用域到 global providers（/credentials/），任何配置的项目都可以访问，或者可以作用域到 特定项目（/job/<project-name>/configure），因此仅能从该特定项目访问。

根据 the docs：处于作用域内的 credentials 会在 pipeline 中不受限制地可用。为了 防止在构建日志中意外泄露，credentials 会在常规输出中被掩码，因此对 env（Linux）或 set（Windows）的调用，或打印其环境或参数的程序不会在构建日志中向本不应访问这些 credentials 的用户泄露它们。

这就是为什么为了 exfiltrate credentials 攻击者需要例如对其进行 base64 编码。

Secrets in plugin/job configs on disk

不要假定 secrets 只存在于 credentials.xml。许多插件在 $JENKINS_HOME/*.xml 下以 自己的全局 XML 持久化 secrets，或在每个 job 的 $JENKINS_HOME/jobs/<JOB>/config.xml 中，有时甚至以明文形式存放（UI 掩码并不保证加密存储）。如果你获得了文件系统的读取权限，请枚举这些 XML 并搜索明显的 secret 标签。

# Global plugin configs
ls -l /var/lib/jenkins/*.xml
grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml

# Per-job configs
find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;

参考资料