Jenkinsの基本情報

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

アクセス

ユーザー名 + パスワード

Jenkinsにログインする最も一般的な方法は、ユーザー名とパスワードによる認証です。

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).

SSO/Plugins

Jenkinsはプラグインを使ってサードパーティのSSOでアクセス可能に設定できます。

トークン

Users can generate tokens to give access to applications to impersonate them via CLI or REST API.

SSH Keys

このコンポーネントはJenkins用の組み込みSSHサーバを提供します。これはJenkins CLIの代替インターフェースであり、任意のSSHクライアントを使ってこの方法でコマンドを実行できます。（docs より）

認可

In /configureSecurity it’s possible to configure the authorization method of Jenkins. There are several options:

  • Anyone can do anything: 匿名アクセスでもサーバを管理できます
  • Legacy mode: Jenkins <1.164 と同じ動作です。“admin” role を持つ場合はシステムに対する完全な管理権限が与えられ、それ以外のユーザ（anonymous を含む）は読み取り権限のみになります。
  • Logged-in users can do anything: このモードでは、ログインしているすべてのユーザーに対してJenkinsの完全な管理権限が与えられます。唯一完全な管理権限を持たないのはanonymous userで、読み取り権限のみ持ちます。
  • Matrix-based security: テーブル形式で誰が何をできるかを設定できます。各列はpermissionを表し、各行はユーザまたはグループ/ロールを表します。ここには認証されていないユーザを表す特殊ユーザ ‘anonymous’ や、認証済みのすべてのユーザを表す ‘authenticated’ も含まれます。

  • Project-based Matrix Authorization Strategy: これは “Matrix-based security” の拡張で、各プロジェクトごとに追加のACLマトリクスを個別に定義できるようにします。
  • Role-Based Strategy: ロールベースの戦略を使って認可を定義できるようにします。ロールは /role-strategy で管理します。

Security Realm

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: Jenkinsコントローラを実行しているサーブレットコンテナ（例：Jetty）に認証を委譲します。
  • Jenkins’ own user database: 外部システムに委譲する代わりに、Jenkinsの組み込みユーザデータストアで認証を行います。これはデフォルトで有効です。
  • LDAP: ユーザやグループを含め、構成されたLDAPサーバにすべての認証を委譲します。
  • Unix user/group database: Jenkinsコントローラ上の基盤となるUnix OSレベルのユーザデータベースに認証を委譲します。このモードではUnixグループを認可に再利用することも可能です。

Plugins can provide additional security realms which may be useful for incorporating Jenkins into existing identity systems, such as:

Jenkins Nodes, Agents & Executors

Definitions from the docs:

Nodes はビルド agents が動作するマシン です。Jenkinsは各接続ノードのディスク空き容量、一時領域の空き、スワップの空き、クロック時間/同期、応答時間を監視します。これらの値が設定閾値を超えた場合、ノードはオフラインになります。

Agents は executors を使って Jenkinsコントローラの代わりにタスク実行を管理します。エージェントはJavaをサポートする任意のOSを利用できます。ビルドやテストに必要なツールはエージェントが動作するノード上にインストールされます；直接インストールするか、コンテナ（DockerやKubernetes）内にインストールできます。各agent はホスト上で独自の PID を持つプロセスとして実行されます。

executor はタスク実行のスロットであり、実質的にはエージェント内のスレッドです。ノード上のexecutorの数は、そのノードで同時に実行できる並列タスク数を定義します。言い換えれば、同じノードで同時に実行できるPipelineの stages の並列数を決定します。

Jenkins Secrets

シークレットと認証情報の暗号化

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 Access

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.

プラグイン/ジョブ設定ファイル上のシークレット

Do not assume secrets are only in credentials.xml. Many plugins persist secrets in their own global XML under $JENKINS_HOME/*.xml or in per-job $JENKINS_HOME/jobs/<JOB>/config.xml, sometimes even in plaintext (UI masking does not guarantee encrypted storage). If you gain filesystem read access, enumerate those XMLs and search for obvious secret tags.

# 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" {} \\;

参考文献

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする