mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-04-28 12:03:08 -07:00
Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md']
This commit is contained in:
Translator
@@ -1,4 +1,4 @@
|
||||
# Pentesting CI/CD 方法論
|
||||
# Pentesting CI/CD Methodology
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,51 +6,51 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS は **Version Control System** の略で、開発者が **source code** を管理するためのシステムです。最も一般的なのは **git** で、企業では通常次のような **platforms** のいずれかで使われています:
|
||||
VCS は **Version Control System** の略で、このシステムは開発者が**ソースコードを管理**するためのものです。最も一般的なのは **git** で、通常は以下の**platforms**のいずれかを使っている会社に出会います。
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- Gitblit
|
||||
- Cloud providers (they offer their own VCS platforms)
|
||||
- Cloud providers (それぞれ独自の VCS platforms を提供しています)
|
||||
|
||||
|
||||
## CI/CD パイプライン
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines は、ビルド、テスト、デプロイなどの目的で **code** の実行を自動化するための仕組みです。これらの自動化ワークフローは、コードの push、pull request、スケジュールされたタスクなどの特定のアクションによって **trigger** されます。開発から本番までの流れを効率化するために役立ちます。
|
||||
CI/CD pipelines は、ビルド、テスト、アプリケーションのデプロイなど、さまざまな目的で**コードの実行を自動化**するためのものです。これらの自動化されたワークフローは、コードの push、pull request、スケジュールされたタスクなど、特定のアクションによって**トリガー**されます。開発から本番までの流れを効率化するのに役立ちます。
|
||||
|
||||
しかし、これらのシステムはどこかで **実行される必要** があり、通常は **privileged credentials を使って code をデプロイしたり機密情報にアクセスしたり** します。
|
||||
ただし、これらのシステムは**どこかで実行**される必要があり、通常はコードのデプロイや機密情報へのアクセスのために**特権 credential** が必要です。
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> 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 ではこのセクション向けに pipeline を作成できますが、ここではソースコードの制御に対する潜在的な攻撃のみを分析します。
|
||||
|
||||
プロジェクトの source code を含むプラットフォームには機密情報が含まれることが多く、権限の扱いには細心の注意が必要です。攻撃者が悪用できる VCS プラットフォーム全般で見られる一般的な問題をいくつか挙げます:
|
||||
プロジェクトのソースコードを含む platforms には機密情報が含まれており、その platform 内で付与される権限には非常に注意が必要です。VCS platforms 全般で、攻撃者が悪用できるよくある問題は次のとおりです。
|
||||
|
||||
- **Leaks**: repo にコミット内の leaks が含まれていて、攻撃者が repo にアクセスできる（公開されている、あるいはアクセス権を持っている）場合、leaks を発見できてしまいます。
|
||||
- **Access**: 攻撃者が VCS platform 内のアカウントに **アクセスできれば**、より多くの可視性や権限を得られます。
|
||||
- **Register**: 一部のプラットフォームでは外部ユーザがアカウントを作成できます。
|
||||
- **SSO**: 一部のプラットフォームはユーザ登録を許可しない代わりに、有効な SSO であれば誰でもアクセスできるようになっていることがあります（例: 攻撃者が自分の github アカウントでログインできるなど）。
|
||||
- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies… リポジトリにアクセスするために盗まれうるトークンの種類は多数あります。
|
||||
- **Webhooks**: VCS platforms は webhooks を生成できます。non visible 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 に対して何らかの **write** アクセスを持っている場合、**malicious code** を注入しようとする可能性があります。成功させるためには **branch protections をバイパス** する必要があるかもしれません。これらの行為はさまざまな目的で行われます:
|
||||
- main branch を破壊して **production を compromise** する。
|
||||
- main（または他のブランチ）を破壊して **developers のマシンを compromise** する（開発者は通常リポジトリ内で test、terraform 等を自分のマシンで実行するため）。
|
||||
- **Compromise the pipeline**（次のセクションを参照）
|
||||
- **Leaks**: コードの commit に leaks が含まれており、攻撃者が repo にアクセスできる場合（公開されている、またはアクセス権を持っているため）、leaks を発見できる可能性があります。
|
||||
- **Access**: 攻撃者が **VCS platform 内のアカウントにアクセス**できれば、**より多くの可視性と権限**を得られる可能性があります。
|
||||
- **Register**: 一部の platforms では外部ユーザーがそのままアカウントを作成できます。
|
||||
- **SSO**: 一部の platforms ではユーザー登録を許可しませんが、有効な SSO があれば誰でもアクセスできます（たとえば攻撃者は自分の github アカウントで入れる可能性があります）。
|
||||
- **Credentials**: Username+Pwd、personal tokens、ssh keys、Oauth tokens、cookies... repo に何らかの形でアクセスするためにユーザーが盗める token にはいくつか種類があります。
|
||||
- **Webhooks**: VCS platforms は webhooks を生成できます。非公開の secrets で保護されていない場合、**攻撃者が悪用できる**可能性があります。
|
||||
- secret が設定されていなければ、攻撃者は third party platform の webhook を悪用できます
|
||||
- secret が URL に含まれている場合も同じことが起こり、攻撃者はその secret も取得できます
|
||||
- **Code compromise:** 悪意のある actor が repos への何らかの **write** access を持っている場合、**悪意のある code を挿入**しようとするかもしれません。成功するには**branch protections を回避**する必要がある場合があります。これらの action は、さまざまな目的で実行できます。
|
||||
- main branch を侵害して **production を侵害**する。
|
||||
- main（または他の branches）を侵害して **developers machines を侵害**する（通常、彼らは自分のマシン上で repo 内の test、terraform、その他の処理を実行するため）。
|
||||
- **pipeline を侵害する**（次の section を確認）
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
パイプラインを定義する最も一般的な方法は、**repository にホストされた CI configuration file** を使うことです。このファイルは実行されるジョブの順序、フローに影響する条件、ビルド環境の設定を記述します。\
|
||||
これらのファイルは通常一貫した名前とフォーマットを持ちます（例: Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、.github/workflows 以下の GitHub Actions の YAML ファイル）。トリガーされると、パイプラインジョブは選択されたソース（例: commit / branch）から **code を pull** し、CI configuration file に指定されたコマンドをその code に対して **実行します**。
|
||||
pipeline を定義する最も一般的な方法は、pipeline がビルドする repository にホストされた **CI configuration file** を使うことです。この file には、実行される job の順序、flow に影響する conditions、build environment settings が記述されています。\
|
||||
これらの files は通常、Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、および .github/workflows 配下にある GitHub Actions の YAML files のように、一定の名前と format を持ちます。トリガーされると、pipeline job は選択された source（例: commit / branch）から code を**pull し**、その code に対して CI configuration file に指定された commands を**実行します**。
|
||||
|
||||
したがって、攻撃者の究極の目的は、これらの configuration files、あるいはそれらが実行するコマンドを何らかの形で **compromise** することです。
|
||||
したがって、攻撃者の最終目標は、何らかの方法でこれらの configuration files か、あるいはそれらが実行する commands を**侵害する**ことです。
|
||||
|
||||
> [!TIP]
|
||||
> Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:
|
||||
> 一部の hosted builders では、contributor が Docker build context と Dockerfile path を選べます。context が attacker-controlled の場合、build 時に repo の外（例: ".."）を指定して host files を取り込み、secrets を exfiltrate できる可能性があります。参照:
|
||||
>
|
||||
>{{#ref}}
|
||||
>docker-build-context-abuse.md
|
||||
@@ -58,57 +58,78 @@ CI/CD pipelines は、ビルド、テスト、デプロイなどの目的で **c
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Poisoned Pipeline Execution (PPE) パスは、SCM repository の権限を悪用して CI pipeline を操作し、悪意あるコマンドを実行させる手法です。必要な権限を持つユーザは CI configuration file や pipeline job が利用する他のファイルを修正して悪意あるコマンドを含めることができます。これにより CI pipeline が「poison」され、これらの悪意あるコマンドが実行されます。
|
||||
Poisoned Pipeline Execution (PPE) の経路は、SCM repository の permissions を悪用して CI pipeline を操作し、悪意のある commands を実行します。必要な permissions を持つユーザーは、CI configuration files や pipeline job が使用する他の files を変更して malicious commands を含めることができます。これにより CI pipeline が「poison」され、これらの malicious commands が実行されます。
|
||||
|
||||
攻撃者が PPE を成功させるには次の条件が必要です:
|
||||
悪意のある actor が PPE attack を成功させるには、次が可能である必要があります。
|
||||
|
||||
- **VCS platform への write access を持っていること**。通常パイプラインは push や pull request が行われたときにトリガーされます。（VCS pentesting methodology セクションでアクセス獲得の方法をまとめています）
|
||||
- 場合によっては **external PR が "write access" と見なされる**ことがあります。
|
||||
- 書き込み権限を持っていても、CI config file やその config が依存している他のファイルを**実際に変更できること**を確認する必要があります。
|
||||
- そのために **branch protections をバイパス**する必要があるかもしれません。
|
||||
- 通常 pipeline は push または pull request 実行時にトリガーされるため、**VCS platform への write access** を持っていること。（アクセス取得方法の概要は VCS pentesting methodology を確認）。
|
||||
- 場合によっては **external PR も "write access" と見なされる**ことに注意。
|
||||
- write permissions があっても、**CI config file または config が依存している他の files を変更できる**ことを確認する必要があります。
|
||||
- そのために、**branch protections を回避**できる必要があるかもしれません。
|
||||
|
||||
PPE には 3 つのバリエーションがあります:
|
||||
PPE には 3 つの種類があります。
|
||||
|
||||
- **D-PPE**: actor が実行される CI config file 自体を **直接変更** する場合（Direct PPE）。
|
||||
- **I-DDE**: actor が CI config file が依存する **別の file**（make file や terraform config など）を **間接的に変更**する場合（Indirect PPE）。
|
||||
- **Public PPE or 3PE**: 場合によってはパイプラインが repo に対する write access を持たないユーザ（組織のメンバーでない可能性もある）が PR を送ることで **トリガーされる**ことがあります。
|
||||
- **3PE Command Injection**: 通常、CI/CD pipelines は PR に関する情報を **environment variables** に設定します。その値が攻撃者によって制御可能（例: PR のタイトル）で、かつそれが **危険な場所**（例: **sh commands** の実行）で **使用される**場合、攻撃者はそこへ **コマンドを注入**する可能性があります。
|
||||
- **D-PPE**: **Direct PPE** attack は、実行される CI config file を actor が**変更**する場合に発生します。
|
||||
- **I-DDE**: **Indirect PPE** attack は、実行される CI config file が**依存している** **file**（make file や terraform config など）を actor が**変更**する場合に発生します。
|
||||
- **Public PPE or 3PE**: 場合によっては、repo への write access を持たないユーザー（org の一員ですらない可能性があります）でも PR を送れるため、pipeline が**トリガーされる**ことがあります。
|
||||
- **3PE Command Injection**: 通常、CI/CD pipelines は PR に関する **情報を含む environment variables** を**設定**します。その値が攻撃者によって制御可能で（PR の title など）、かつ **危険な場所**（**sh commands** の実行など）で**使用**される場合、攻撃者はそこに commands を**注入**できる可能性があります。
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
PPE の 3 種類を理解した上で、成功した場合に攻撃者が得られるものを見てみましょう:
|
||||
pipeline を poison する 3 つの種類を理解したので、侵害が成功した後に攻撃者が何を得られるかを確認しましょう。
|
||||
|
||||
- **Secrets**: 先述の通り、パイプラインのジョブは code を取得し、ビルドやデプロイを行うために **privileges** を必要とし、これらの権限は通常 **secrets** として与えられます。これらの secrets は **env variables やシステム内のファイル** を通じてアクセス可能であることが多く、したがって攻撃者は可能な限り多くの secrets を exfiltrate しようとします。
|
||||
- パイプラインプラットフォームによっては attacker が config 内で secrets を指定する必要がある場合があります。つまり、攻撃者が CI configuration を変更できない場合（例: I-PPE）、その場合は**そのパイプラインが持つ secrets のみ**を exfiltrate できるにとどまります。
|
||||
- **Computation**: code はどこかで実行されます。実行される場所次第で攻撃者はさらに pivot できる可能性があります。
|
||||
- **On-Premises**: パイプラインがオンプレミスで実行されている場合、攻撃者は **内部ネットワーク** に入り、より多くのリソースへアクセスできる可能性があります。
|
||||
- **Cloud**: 攻撃者はクラウド内の他のマシンへアクセスできるだけでなく、そこで IAM roles / service accounts の tokens を exfiltrate してクラウド内でさらに権限を拡大する可能性があります。
|
||||
- **Platforms machine**: 時にはジョブが pipelines platform のマシン内で実行されることがあり、これらは通常より限定的なアクセスしか持たないクラウド内のマシンであることが多いです。
|
||||
- **Select it:** パイプラインプラットフォームが複数のマシンを用意している場合、CI configuration file を変更できれば **どのマシンで悪意ある code を実行するかを指定できる**ことがあります。この場合、攻撃者は各マシンでリバースシェルを実行してさらなる攻撃を試みるでしょう。
|
||||
- **Compromise production**: パイプライン内に侵入し、最終版がそこからビルド・デプロイされる場合、本番で動作する code を compromise できます。
|
||||
- **Secrets**: 前述のとおり、pipelines の job には **privileges**（code の取得、ビルド、デプロイなど）が必要であり、これらの privileges は通常 **secrets に含まれて付与**されます。これらの secrets は通常、**env variables** または system 内の files 経由でアクセス可能です。そのため攻撃者は常に、可能な限り多くの secrets を exfiltrate しようとします。
|
||||
- pipeline platform によっては、攻撃者が config に secrets を明示的に指定する必要がある場合があります。つまり、攻撃者が CI configuration pipeline を変更できない（たとえば **I-PPE**）場合、**その pipeline が持つ secrets だけ**を exfiltrate できます。
|
||||
- **Computation**: code はどこかで実行されるため、実行場所によっては攻撃者がさらに pivot できる可能性があります。
|
||||
- **On-Premises**: pipelines が on premises で実行される場合、攻撃者は **より多くの resources にアクセスできる internal network** に到達する可能性があります。
|
||||
- **Cloud**: 攻撃者は **cloud 内の他の machines** にアクセスできるだけでなく、そこから IAM roles/service accounts の **tokens** を exfiltrate して、cloud 内でのさらなる access を得ることもできます。
|
||||
- **Platforms machine**: 場合によっては、job は **pipelines platform machines** 上で実行されます。通常、これらは **それ以上の access がない** cloud 内にあります。
|
||||
- **Select it:** 場合によっては、**pipelines platform に複数の machines が設定**されており、CI configuration file を**変更**できるなら、悪意のある code をどこで実行するかを**指定**できます。この状況では、攻撃者はおそらく各 machine で reverse shell を実行し、さらなる exploitation を試みます。
|
||||
- **Compromise production**: pipeline 内にいて、最終版がそこからビルド・デプロイされるなら、**production で実行される code を侵害**できる可能性があります。
|
||||
|
||||
### Dependency & Registry Supply-Chain Abuse
|
||||
|
||||
CI/CD pipeline を侵害する、またはそこから credentials を盗むことで、dependencies や release tooling を backdoor 化し、攻撃者は **pipeline execution** から **ecosystem-wide code execution** へ移行できる場合があります。
|
||||
|
||||
- **Install-time code execution via package hooks**: `preinstall`、`postinstall`、`prepare`、または同様の hooks を追加した package version を公開すると、dependency installation 中に developer workstations と CI runners の両方で payload が自動実行されます。
|
||||
- **Secondary execution paths**: 対象が `--ignore-scripts` 付きでインストールしても、悪意のある package は `bin` field に **一般的な CLI name** を登録できるため、attack-controlled wrapper が `PATH` に symlink され、後で command が使われたときに実行されます。
|
||||
- **Runtime bootstrapping**: 小さな installer が installation 中に別の runtime や toolchain（たとえば Bun や packed interpreter）をダウンロードし、それを使って main payload を起動できるため、ローカルの dependency requirements を回避できます。
|
||||
- **Credential harvesting from build environments**: code が CI 内で実行されたら、environment variables、`~/.npmrc`、`~/.git-credentials`、SSH keys、cloud CLI configs、`gh auth token` などの local tooling を確認してください。GitHub Actions では、runner-specific secrets と artifacts も確認します。
|
||||
- **Workflow injection with stolen GitHub tokens**: **`repo` + `workflow`** permissions を持つ token があれば、branch を作成し、`.github/workflows/` 内に malicious file を commit し、それを trigger して生成された artifacts/logs を収集し、最後に temporary branch/workflow run を削除して痕跡を減らせます。
|
||||
- **Wormable registry propagation**: 盗まれた npm tokens は **publish** permissions と 2FA を回避できるかを検証すべきです。可能なら、書き込み可能な packages を列挙し、それらの tarballs をダウンロードし、`setup.mjs` のような loader を注入し、`preinstall` をそれを実行するように設定し、patch version を上げて再公開します。これにより、1 回の CI compromise が downstream の他環境での自動実行へとつながります。
|
||||
|
||||
#### Practical checks during an assessment
|
||||
|
||||
- `package.json` に追加された package-manager hooks、予期しない `bin` entries、または release artifact だけを変更する version bumps がないか release automation を確認する。
|
||||
- CI が短命な OIDC や trusted publishing ではなく、`~/.npmrc` のような plaintext files に長期的な registry credentials を保存していないか確認する。
|
||||
- CI で利用可能な GitHub tokens が workflow files を書き込んだり、branches/tags を作成したりできるか確認する。
|
||||
- compromised package が疑われる場合は、Git repository だけでなく公開済み tarball も確認する。malicious loader/runtime が published artifact にのみ存在する可能性があるため。
|
||||
- CI 内で `npm ci` ではなく `npm install` が使われていないか、予期しない Bun の download/execution がないか、一時的な branches から新しい workflow artifacts が生成されていないかを探す。
|
||||
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) は、CIS Software Supply Chain benchmark に基づき、ソフトウェアサプライチェーンのセキュリティ準拠性を監査するオープンソースツールです。監査はSDLC全体に焦点を当て、code の時点からデプロイ時点までのリスクを明らかにします。
|
||||
- [**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) に基づいて software supply chain stack の security compliance を監査するための open-source tool です。この監査は SDLC 全体に焦点を当てており、code time から deploy time までの risks を明らかにできます。
|
||||
|
||||
### 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 による top 10 CI/CD risks に関する興味深い article を確認してください: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- ローカルで実行できる各プラットフォームについて、ローカル起動方法が記載されているので、自由に設定してテストできます
|
||||
- ローカルで実行できる各 platform について、ローカルでの起動方法が記載されているので、好きなように test できるよう設定できます
|
||||
- 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 向けの static code analysis ツールです。
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** は infrastructure-as-code 向けの static code analysis tool です。
|
||||
|
||||
## 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)
|
||||
- [The npm Threat Landscape: Attack Surface and Mitigations](https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/)
|
||||
- [Checkmarx Security Update: April 22, 2026](https://checkmarx.com/blog/checkmarx-security-update-april-22/?p=108469)
|
||||
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user