mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-14 22:03:11 -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として実行するか、サーブレットコンテナ内で動作させることができ、Git over SSH用の組み込みSSHサービス（Apache MINA SSHD）を同梱しています。
|
||||
Gitblit は Java で書かれたセルフホスト型の Git サーバーです。スタンドアロンの JAR として、または servlet containers 内で動作し、Git over SSH 用の組み込み SSH サービス (Apache MINA SSHD) を同梱しています。
|
||||
|
||||
## トピック
|
||||
|
||||
|
||||
@@ -4,34 +4,34 @@
|
||||
|
||||
## 概要
|
||||
|
||||
CVE-2024-28080 は、Apache MINA SSHD と統合する際のセッション状態ハンドリングの誤りに起因する、Gitblit の組み込み SSH サービスにおける認証バイパスです。ユーザーアカウントに少なくとも 1 つの SSH public key が登録されている場合、攻撃者が該当ユーザーの username とその public key のいずれかを知っていれば、private key や password なしで認証できます。
|
||||
CVE-2024-28080 は、Gitblit の embedded SSH サービスにおける認証バイパスで、Apache MINA SSHD と統合する際の session state の誤った取り扱いが原因です。ユーザーアカウントに少なくとも1つの SSH public key が登録されている場合、攻撃者が username とそのユーザーの public key のいずれかを知っていれば、private key も password も不要で認証できます。
|
||||
|
||||
- 影響を受けるバージョン: Gitblit < 1.10.0 (1.9.3 で確認)
|
||||
- 修正バージョン: 1.10.0
|
||||
- 悪用に必要な条件:
|
||||
- インスタンスで Git over SSH が有効になっていること
|
||||
- 被害者アカウントに少なくとも 1 つの SSH public key が Gitblit に登録されていること
|
||||
- 攻撃者が被害者の username とその public key のいずれかを知っていること（公開されていることが多い、例: 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
|
||||
- Victim account has at least one SSH public key registered in Gitblit
|
||||
- Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/<username>.keys)
|
||||
|
||||
## 根本原因 (state leaks between SSH methods)
|
||||
|
||||
RFC 4252 によれば、public‑key authentication は 2 段階で進行します: サーバは最初に提示された public key が username に対して受け入れ可能かをチェックし、クライアントが署名で応答した後にユーザーを認証します。MINA SSHD では、PublickeyAuthenticator が 2 回呼ばれます: key acceptance（まだ署名なし）時と、クライアントが署名を返した後です。
|
||||
RFC 4252 によれば public‑key authentication は2段階で進行します: サーバはまず提供された public key が username に対して受け入れられるかをチェックし、その後 challenge/response による signature が検証されて初めてユーザーを認証します。MINA SSHD では、PublickeyAuthenticator が2回呼ばれます: key acceptance（まだ signature なし）の時と、クライアントが後で signature を返した後の時です。
|
||||
|
||||
Gitblit の PublickeyAuthenticator は、署名前の最初の呼び出しでセッションコンテキストを変更し、UserModel をセッションにバインドして true（"key acceptable"）を返していました。後に認証が password にフォールバックした際、PasswordAuthenticator はその変更されたセッション状態を信頼して処理をスキップし、password の検証なしに true を返しました。その結果、同じユーザーに対して public‑key の "acceptance" が先に起きていれば、任意の password（空も含む）が受け入れられてしまいました。
|
||||
Gitblit の PublickeyAuthenticator は最初の、pre‑signature 呼び出しで session context を変更し、認証された UserModel を session にバインドして true（"key acceptable"）を返しました。認証が後で password にフォールバックしたとき、PasswordAuthenticator はその変更された session state を信頼して短絡し、password を検証せずに true を返しました。その結果、同じユーザーに対する事前の public‑key "acceptance" の後は、空を含む任意の password が受け入れられることになりました。
|
||||
|
||||
高レベルの欠陥の流れ:
|
||||
High‑level flawed flow:
|
||||
|
||||
1) クライアントが username + public key を提示（まだ署名なし）
|
||||
2) サーバがその key がユーザーに属すると認識し、ユーザーをセッションに早期に紐付けして true（"acceptable"）を返す
|
||||
1) クライアントが username + public key を提示する（no signature yet）
|
||||
2) サーバはその key がユーザーに属すると認識し、ユーザーを session に早期に紐付けして true を返す（"acceptable"）
|
||||
3) クライアントは署名できない（private key がない）ため、認証は password にフォールバックする
|
||||
4) PasswordAuthenticator はセッションに既にユーザーが存在するのを検出し、無条件に成功を返す
|
||||
4) Password auth は既に session にユーザーが存在するのを見て無条件に成功を返す
|
||||
|
||||
## ステップごとの悪用
|
||||
## ステップバイステップの悪用
|
||||
|
||||
- 被害者の username とその public key の 1 つを収集する:
|
||||
- GitHub は公開鍵を https://github.com/<username>.keys で公開している
|
||||
- 公開サーバはしばしば authorized_keys を公開している
|
||||
- OpenSSH を設定して public half のみを提示するようにし、署名生成を失敗させることで password へのフォールバックを強制しつつ、サーバ側では public‑key acceptance パスをトリガーさせる
|
||||
- 被害者の username とその public key の1つを収集する:
|
||||
- GitHub は public keys を https://github.com/<username>.keys で公開している
|
||||
- 公開サーバはしばしば authorized_keys を公開している
|
||||
- OpenSSH を設定して public half のみを提示し、signature の生成を失敗させることで、サーバ側の public‑key acceptance パスをトリガーしたまま password へのフォールバックを強制する
|
||||
|
||||
Example SSH client config (no private key available):
|
||||
```sshconfig
|
||||
@@ -44,56 +44,56 @@ PreferredAuthentications publickey,password
|
||||
IdentitiesOnly yes
|
||||
IdentityFile ~/.ssh/victim.pub # public half only (no private key present)
|
||||
```
|
||||
接続し、パスワードプロンプトで Enter キーを押してください（または任意の文字列を入力してください）:
|
||||
接続して、パスワードのプロンプトでEnterキーを押す（または任意の文字列を入力）:
|
||||
```bash
|
||||
ssh gitblit-target
|
||||
# or Git over SSH
|
||||
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
|
||||
```
|
||||
認証が成功するのは、前段の public‑key フェーズがセッションを認証済みユーザーに変更（mutated）してしまい、password auth がその状態を誤って信頼するためです。
|
||||
認証が成功するのは、先行する public‑key フェーズがセッションを認証済みユーザーに変異させ、その状態を password auth が誤って信頼してしまうためです。
|
||||
|
||||
Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
|
||||
注意: SSH 設定で ControlMaster multiplexing が有効な場合、後続の Git コマンドが認証済みの接続を再利用し、影響が拡大する可能性があります。
|
||||
|
||||
## Impact
|
||||
## 影響
|
||||
|
||||
- 少なくとも1つの登録された SSH public key を持つ任意の Gitblit ユーザーの完全ななりすまし
|
||||
- 被害者の権限に応じたリポジトリへの読み書きアクセス（source exfiltration、unauthorized pushes、supply‑chain risks）
|
||||
- admin ユーザーを狙った場合、管理者権限に対する影響の可能性
|
||||
- 純粋なネットワーク脆弱性；brute force も private key も不要
|
||||
- 少なくとも1つの登録済み SSH public key を持つ任意の Gitblit ユーザーの完全な成りすまし
|
||||
- 被害者の権限に応じたリポジトリへの読み書きアクセス（ソースの持ち出し、無許可の pushes、サプライチェーンリスク）
|
||||
- 管理者ユーザーを標的にした場合の管理上の影響の可能性
|
||||
- 純粋なネットワーク脆弱性; ブルートフォースや秘密鍵は不要
|
||||
|
||||
## Detection ideas
|
||||
## 検出のアイデア
|
||||
|
||||
- SSH ログを確認し、publickey 試行の後に空または非常に短いパスワードでの成功した password authentication が続くようなシーケンスを探す
|
||||
- フローを探す: publickey method がサポート外／不一致のキー素材を提示した後、同じユーザー名に対して即座に password が成功する流れ
|
||||
- publickey 試行の後に、空または非常に短いパスワードで成功した password 認証が続くような一連の記録を探して SSH ログを確認する
|
||||
- publickey method がサポートされない/不一致の鍵材料を提示した直後に、同じユーザー名で 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)
|
||||
## 一般: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
|
||||
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:
|
||||
パターン: サーバーの public‑key authenticator が pre‑signature の "key acceptable" フェーズ中にユーザー/セッション状態を変異させ、他の authenticators（例: password）がその状態を信頼してしまう場合、次の方法で認証をバイパスできます:
|
||||
|
||||
- 対象ユーザーの正当な public key を提示する（private key は不要）
|
||||
- クライアントに署名を失敗させてサーバが password にフォールバックするようにする
|
||||
- password authenticator が leaked state によりショートサーキットする間に任意の password を供給する
|
||||
- 対象ユーザーの正当な public key を提示する（秘密鍵は不要）
|
||||
- クライアントの署名を失敗させてサーバーを password にフォールバックさせる
|
||||
- password authenticator が 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
|
||||
- Public key を大規模に収集する: https://github.com/<username>.keys、組織のディレクトリ、チームページ、leaked authorized_keys などの一般的なソースから public key を取得する
|
||||
- 署名失敗を強制する（クライアント側）: IdentityFile を .pub のみに向け、IdentitiesOnly yes を設定し、PreferredAuthentications に publickey → password を含めたままにする
|
||||
- MINA SSHD 統合の落とし穴:
|
||||
- PublickeyAuthenticator.authenticate(...) は post‑signature の検証経路が署名を確認するまでユーザー/セッション状態を付加してはならない
|
||||
- PasswordAuthenticator.authenticate(...) は、前の未完了の認証メソッド中に変異した状態から成功を推測してはならない
|
||||
|
||||
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
|
||||
- 早期受理オラクルや認証レースに関する歴史的議論（例: OpenSSH の挙動を巡る CVE‑2016‑20012 の論争）
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD 方法論
|
||||
# Pentesting CI/CD 手法
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS は **Version Control System** の略で、このシステムは開発者が **ソースコードを管理** することを可能にします。最も一般的なのは **git** で、企業は通常次のような **platforms** のいずれかで利用しています:
|
||||
VCS は **Version Control System** の略で、開発者が **ソースコードを管理する**ためのシステムです。最も一般的なのは **git** で、企業では通常次のような **platforms** のいずれかを使っています:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -18,86 +18,86 @@ VCS は **Version Control System** の略で、このシステムは開発者が
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines は、ビルド、テスト、デプロイなどの目的でコードの実行を **自動化** することを可能にします。これらの自動化されたワークフローは、コードの push、pull request、スケジュールされたタスクなど、特定のアクションによって **トリガー** されます。開発から本番への流れを効率化するのに有用です。
|
||||
CI/CD パイプラインは、アプリケーションのビルド、テスト、デプロイなどの目的で **コードの実行を自動化**する仕組みです。これらの自動ワークフローは、コードの push、pull request、スケジュールされたタスクなどの特定のアクションによって **トリガーされます**。開発から本番へのプロセスを効率化するのに役立ちます。
|
||||
|
||||
ただし、これらのシステムはどこかで **実行される必要があり**、通常はコードをデプロイしたり機密情報にアクセスしたりするための **特権付き資格情報** が必要になります。
|
||||
しかし、これらのシステムはどこかで **実行される必要があり**、通常は**コードをデプロイしたり機密情報にアクセスするための特権的な認証情報**を必要とします。
|
||||
|
||||
## VCS Pentesting 方法論
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> 一部の VCS platforms がパイプラインを作成できる場合でも、このセクションではソースコードの制御に対する潜在的な攻撃のみを分析します。
|
||||
> 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.
|
||||
|
||||
プロジェクトのソースコードを含むプラットフォームには機密情報が含まれるため、プラットフォーム内で付与される権限には細心の注意が必要です。以下は攻撃者が悪用し得る VCS platforms に共通する問題点です:
|
||||
リポジトリにソースコードが含まれているプラットフォームには機密情報が含まれることがあり、プラットフォーム内で付与される権限に細心の注意を払う必要があります。攻撃者が悪用できる一般的な問題は次のとおりです:
|
||||
|
||||
- **Leaks**: コードのコミットに leaks が含まれていて、攻撃者がリポジトリにアクセスできる（公開リポジトリであるかアクセス権を持つ場合）と、その leaks を発見する可能性があります。
|
||||
- **Access**: 攻撃者が **VCS platform 内のアカウントにアクセスできる**場合、より多くの可視性と権限を得ることができます。
|
||||
- **Register**: 一部のプラットフォームでは外部ユーザがアカウントを作成できます。
|
||||
- **SSO**: 一部のプラットフォームはユーザ登録を許可しないが、有効な SSO であれば誰でもアクセスできる（例えば攻撃者が自分の github アカウントを使って入ることができる）。
|
||||
- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... ユーザがリポジトリにアクセスするために盗めるトークンの種類は複数あります。
|
||||
- **Webhooks**: VCS platforms は 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:** 悪意ある主体がリポジトリに対して何らかの **write** アクセスを持っている場合、**悪意あるコードを注入** しようとする可能性があります。成功するためには **branch protections をバイパス** する必要があることがあります。これらの行為は、目的に応じてさまざまな影響をもたらします:
|
||||
- メインブランチを改ざんして **compromise production**。
|
||||
- メイン（または他の）ブランチを改ざんして **compromise developers machines**（開発者は通常テスト、terraform、その他をリポジトリ内から自身のマシンで実行するため）。
|
||||
- **Compromise the pipeline**（次のセクションを参照）
|
||||
- **Leaks**: コードに commits に含まれる leaks があり、攻撃者がリポジトリにアクセスできる（公開やアクセス権がある場合）と、それらの leaks を発見する可能性があります。
|
||||
- **Access**: 攻撃者が **VCS platform 内のアカウントにアクセスできる**と、**より多くの可視性や権限**を得ることができます。
|
||||
- **Register**: 一部のプラットフォームでは外部ユーザがアカウントを作成できてしまいます。
|
||||
- **SSO**: 一部のプラットフォームはユーザ登録を許可していないが、有効な SSO であれば誰でもアクセスできる場合があります（例: 攻撃者が自分の github アカウントで入れる、など）。
|
||||
- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... ユーザがリポジトリに何らかの形でアクセスするために盗めるトークンはいくつもあります。
|
||||
- **Webhooks**: VCS プラットフォームは webhook を生成できます。これらが非表示の secret で**保護されていない**場合、**攻撃者が悪用**する可能性があります。
|
||||
- secret が設定されていない場合、攻撃者はサードパーティのプラットフォームの webhook を悪用できます。
|
||||
- secret が URL に含まれている場合も同様で、攻撃者はその secret を入手できます。
|
||||
- **Code compromise:** 悪意のある行為者がリポジトリに対して何らかの **write** 権限を持っている場合、**悪意のあるコードを注入**しようとする可能性があります。成功するには **branch protections を回避**する必要があるかもしれません。これらの行為は様々な目的で実行され得ます:
|
||||
- main ブランチを妥協して **production を侵害**する。
|
||||
- main（または他のブランチ）を妥協して **開発者のマシンを侵害**する（開発者は通常リポジトリ内で test、terraform などを実行するため）。
|
||||
- **パイプラインを妥協する**（次のセクションを参照）
|
||||
|
||||
## Pipelines Pentesting 方法論
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
パイプラインを定義する最も一般的な方法は、パイプラインが構築するリポジトリにホストされた **CI configuration file** を使用することです。このファイルは実行されるジョブの順序、フローに影響する条件、ビルド環境の設定を記述します。\
|
||||
これらのファイルは通常一貫した名前と形式を持ちます。例えば — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、および .github/workflows 配下の GitHub Actions の YAML ファイルなどです。トリガーされると、パイプラインジョブは選択されたソース（例: commit / branch）から **コードを pull** し、CI configuration file に指定されたコマンドをそのコードに対して **実行** します。
|
||||
パイプラインを定義する最も一般的な方法は、**ビルド対象のリポジトリにホストされている CI 設定ファイル**を使用することです。このファイルは実行されるジョブの順序、フローに影響する条件、ビルド環境の設定などを記述します。\
|
||||
これらのファイルは典型的に一貫した名前と形式を持ちます。例えば — Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、そして .github/workflows 以下にある GitHub Actions の YAML ファイルなどです。トリガーされると、パイプラインジョブは選択されたソース（例: commit / branch）から **コードを pull** し、そのコードに対して CI 設定ファイルで指定されたコマンドを **実行します**。
|
||||
|
||||
したがって、攻撃者の最終的な目的はこれらの設定ファイルを何らかの方法で **compromise** するか、それらが実行する **コマンドを改変** することになります。
|
||||
したがって、攻撃者の究極の目的はこれらの設定ファイルやそれらが実行するコマンドを何らかの形で **妥協すること**です。
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Poisoned Pipeline Execution (PPE) パスは、SCM リポジトリの権限を悪用して CI パイプラインを操作し、有害なコマンドを実行させる攻撃手法です。必要な権限を持つユーザは CI 設定ファイルやパイプラインジョブで使用される他のファイルを変更して悪意あるコマンドを含めることができます。これにより CI パイプラインが「汚染」され、これらの悪意あるコマンドが実行されます。
|
||||
Poisoned Pipeline Execution (PPE) パスは、SCM リポジトリ内の権限を悪用して CI パイプラインを操作し、有害なコマンドを実行させる攻撃です。必要な権限を持つユーザは CI 設定ファイルやパイプラインジョブで使用されるファイルを修正して悪意あるコマンドを含めることができます。これにより CI パイプラインが「毒され」、その悪意あるコマンドが実行されます。
|
||||
|
||||
攻撃者が PPE 攻撃を成功させるには、次のことが必要です:
|
||||
攻撃者が PPE 攻撃を成功させるために必要なもの:
|
||||
|
||||
- **write access to the VCS platform** を持っていること。通常、パイプラインは push や pull request が行われたときにトリガーされます。（アクセスを得る方法の概要は VCS pentesting methodology を参照してください）
|
||||
- 場合によっては **external PR が "write access" と見なされる**ことがある点に注意してください。
|
||||
- たとえ write 権限があっても、CI config ファイルやその設定が依存している他のファイルを **実際に変更できる**ことを確認する必要があります。
|
||||
- そのために、**branch protections をバイパス** できる必要がある場合があります。
|
||||
- **VCS platform への write access** を持っていること。通常パイプラインは push や pull request が実行されたときにトリガーされます。（VCS pentesting methodology を参照してアクセスを得る方法の概要を確認してください。）
|
||||
- 注: 場合によっては **外部の PR が "write access" と見なされる**ことがあります。
|
||||
- 書き込み権限があっても、**CI config ファイルや config が依存している他のファイルを修正できるか**を確認する必要があります。
|
||||
- そのためには branch protections を **回避できる**必要があるかもしれません。
|
||||
|
||||
PPE には 3 つのバリエーションがあります:
|
||||
|
||||
- **D-PPE**: Direct PPE。攻撃者が実行される CI 設定ファイル自体を **直接変更** する場合。
|
||||
- **I-DDE**: Indirect PPE。攻撃者がCI設定ファイルが依存している **ファイル（makefile や terraform 設定など）を変更** する場合。
|
||||
- **Public PPE or 3PE**: 場合によっては、リポジトリに対する write アクセスがないユーザ（組織のメンバーでないユーザ）が PR を送ることでパイプラインが **トリガーされる**ことがあります。
|
||||
- **3PE Command Injection**: 通常、CI/CD パイプラインは PR に関する情報を含む環境変数を **設定** します。もしその値が攻撃者により制御可能（例: PR のタイトル）で、かつ **危険な場所**（例: sh commands を実行する箇所）で **使用される**場合、攻撃者はその中にコマンドを **注入** できる可能性があります。
|
||||
- **D-PPE**: CI config ファイル自体を直接 **修正する**ことで発生する **Direct PPE** 攻撃。
|
||||
- **I-DDE**: CI config が依存している **ファイル**（Makefile や terraform 設定など）を **修正する**ことで発生する **Indirect PPE** 攻撃。
|
||||
- **Public PPE or 3PE**: 場合によってはパイプラインがリポジトリへの write access を持たないユーザ（組織外のユーザを含む）が PR を送ることで **トリガーされる**ことがあります。
|
||||
- **3PE Command Injection**: 通常、CI/CD パイプラインは **PR に関する情報を環境変数として設定**します。もしその値を攻撃者が制御でき（例: PR のタイトル）、かつそれが（sh コマンドの実行など）**危険な場所で使われている**と、攻撃者はそこに **コマンドを注入**できる可能性があります。
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
PPE の 3 種類を理解した上で、攻撃が成功した場合に攻撃者が得られるものを見ていきます:
|
||||
PPE の 3 つのバリエーションを把握した上で、攻撃者が成功した場合に得られるものを見てみましょう:
|
||||
|
||||
- **Secrets**: 前述の通り、パイプラインのジョブはコードの取得、ビルド、デプロイなどのために **特権** を必要とし、これらの特権は通常 **secrets** によって付与されます。これらの secrets は **env variables やシステム内のファイル** を通じてアクセス可能であることが多いため、攻撃者は可能な限り多くの secrets を持ち出そうとします。
|
||||
- パイプラインプラットフォームによっては、攻撃者が CI 設定を変更できない場合（例: I-PPE）、攻撃者は **そのパイプラインが持つ secrets のみ** を持ち出すことしかできない場合があります。
|
||||
- **Computation**: コードはどこかで実行されるため、実行場所によっては攻撃者がさらなるピボットを行える可能性があります。
|
||||
- **On-Premises**: パイプラインがオンプレで実行されている場合、攻撃者は内部ネットワーク内でより多くのリソースにアクセスできる立場になる可能性があります。
|
||||
- **Cloud**: 攻撃者はクラウド内の他のマシンにアクセスできるだけでなく、IAM ロールやサービスアカウントのトークンを持ち出してクラウド内でさらに権限を拡大する可能性があります。
|
||||
- **Platforms machine**: ジョブがパイプラインプラットフォームのマシン内で実行される場合、これらは通常クラウド上で他のリソースにアクセスしないように設定されていることもあります。
|
||||
- **Select it:** パイプラインプラットフォームが複数の実行マシンを用意している場合、CI 設定ファイルを変更できれば悪意あるコードをどのマシンで実行するか **指定できる**ことがあります。この場合、攻撃者は各マシンにリバースシェルを張ってさらに侵害を試みることが考えられます。
|
||||
- **Compromise production**: パイプライン内に侵入し、そのパイプラインから最終版がビルド・デプロイされる場合、本番環境で実行されるコードを改ざんすることができます。
|
||||
- **Secrets**: 前述の通り、パイプラインのジョブは（コードを取得・ビルド・デプロイするなど）**特権**を必要とし、これらの特権は通常 **secrets** として付与されます。これらの secrets は通常 **env variables やシステム内のファイル**を通じてアクセス可能です。したがって攻撃者は可能な限り多くの secrets を常に抽出しようとします。
|
||||
- パイプラインプラットフォームによっては、攻撃者が秘密情報を利用するためにそれらを config に明示する必要がある場合があります。つまり、攻撃者が CI 設定ファイルを変更できない場合（例: I-PPE の場合）、**そのパイプラインが持つ secrets のみを抽出**できる可能性があります。
|
||||
- **Computation**: コードはどこかで実行されます。実行場所によっては攻撃者がさらにピボットできる可能性があります。
|
||||
- **On-Premises**: パイプラインがオンプレミスで実行されている場合、攻撃者は **内部ネットワークに入り込み、より多くのリソースにアクセス**できる可能性があります。
|
||||
- **Cloud**: 攻撃者はクラウド内の他のマシンにアクセスできるだけでなく、IAM ロール／service account の **トークンを exfiltrate**してクラウド内でさらに権限を得ることも可能です。
|
||||
- **Platforms machine**: 場合によってはジョブが **パイプラインプラットフォームのマシン内で実行され**、これらは通常クラウド内にあり追加のアクセス権を持たないこともあります。
|
||||
- **Select it:** 時には **パイプラインプラットフォームが複数のマシンを構成している**ことがあり、CI 設定ファイルを修正できれば **悪意あるコードを実行したいマシンを指定**できます。この状況では攻撃者は各マシンでリバースシェルを実行してさらに攻撃を仕掛けようとするでしょう。
|
||||
- **Compromise 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 全体に焦点を当て、コード段階からデプロイ段階までのリスクを明らかにします。
|
||||
|
||||
### 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 のトップ10 リスクに関する興味深い記事を確認してください: [**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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user