Basic Jenkins Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The most common way to login in Jenkins if with a username or a password
If an authorized cookie gets stolen, it ca be used to access the session of the user. The cookie is usually called JSESSIONID.*. (A user can terminate all his sessions, but he would need to find out first that a cookie was stolen).
Jenkins can be configured using plugins to be accessible via third party SSO.
Users can generate tokens to give access to applications to impersonate them via CLI or REST API.
This component provides a built-in SSH server for Jenkins. It’s an alternative interface for the Jenkins CLI, and commands can be invoked this way using any SSH client. (From the docs)
In /configureSecurity it's possible to configure the authorization method of Jenkins. There are several options:
Anyone can do anything: Even anonymous access can administrate the server
Legacy mode: Same as Jenkins <1.164. If you have the "admin" role, you'll be granted full control over the system, and otherwise (including anonymous users) you'll have read access.
Logged-in users can do anything: In this mode, every logged-in user gets full control of Jenkins. The only user who won't have full control is anonymous user, who only gets read access.
Matrix-based security: You can configure who can do what in a table. Each column represents a permission. Each row represents a user or a group/role. This includes a special user 'anonymous', which represents unauthenticated users, as well as 'authenticated', which represents all authenticated users.
Project-based Matrix Authorization Strategy: This mode is an extension to "Matrix-based security" that allows additional ACL matrix to be defined for each project separately.
Role-Based Strategy: Enables defining authorizations using a role-based strategy. Manage the roles in /role-strategy.
In /configureSecurity it's possible to configure the security realm. By default Jenkins includes support for a few different Security Realms:
Delegate to servlet container: For delegating authentication a servlet container running the Jenkins controller, such as Jetty.
Jenkins’ own user database: Use Jenkins’s own built-in user data store for authentication instead of delegating to an external system. This is enabled by default.
LDAP: Delegate all authentication to a configured LDAP server, including both users and groups.
Unix user/group database: Delegates the authentication to the underlying Unix OS-level user database on the Jenkins controller. This mode will also allow re-use of Unix groups for authorization.
Plugins can provide additional security realms which may be useful for incorporating Jenkins into existing identity systems, such as:
Definitions from the docs:
Nodes are the machines on which build agents run. Jenkins monitors each attached node for disk space, free temp space, free swap, clock time/sync and response time. A node is taken offline if any of these values go outside the configured threshold.
Agents manage the task execution on behalf of the Jenkins controller by using executors. An agent can use any operating system that supports Java. Tools required for builds and tests are installed on the node where the agent runs; they can be installed directly or in a container (Docker or Kubernetes). Each agent is effectively a process with its own PID on the host machine.
An executor is a slot for execution of tasks; effectively, it is a thread in the agent. The number of executors on a node defines the number of concurrent tasks that can be executed on that node at one time. In other words, this determines the number of concurrent Pipeline stages that can execute on that node at one time.
Definition from the docs: Jenkins uses AES to encrypt and protect secrets, credentials, and their respective encryption keys. These encryption keys are stored in $JENKINS_HOME/secrets/ along with the master key used to protect said keys. This directory should be configured so that only the operating system user the Jenkins controller is running as has read and write access to this directory (i.e., a chmod value of 0700 or using appropriate file attributes). The master key (sometimes referred to as a "key encryption key" in cryptojargon) is stored _unencrypted_ on the Jenkins controller filesystem in $JENKINS_HOME/secrets/master.key which does not protect against attackers with direct access to that file. Most users and developers will use these encryption keys indirectly via either the Secret API for encrypting generic secret data or through the credentials API. For the cryptocurious, Jenkins uses AES in cipher block chaining (CBC) mode with PKCS#5 padding and random IVs to encrypt instances of CryptoConfidentialKey which are stored in $JENKINS_HOME/secrets/ with a filename corresponding to their CryptoConfidentialKey id. Common key ids include:
hudson.util.Secret: used for generic secrets;
com.cloudbees.plugins.credentials.SecretBytes.KEY: used for some credentials types;
jenkins.model.Jenkins.crumbSalt: used by the CSRF protection mechanism; and
Credentials can be scoped to global providers (/credentials/) that can be accessed by any project configured, or can be scoped to specific projects (/job/<project-name>/configure) and therefore only accessible from the specific project.
According to the docs: Credentials that are in scope are made available to the pipeline without limitation. To prevent accidental exposure in the build log, credentials are masked from regular output, so an invocation of env (Linux) or set (Windows), or programs printing their environment or parameters would not reveal them in the build log to users who would not otherwise have access to the credentials.
That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
