diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md new file mode 100644 index 000000000..a39e17601 --- /dev/null +++ b/src/pentesting-ci-cd/argocd-security.md @@ -0,0 +1,219 @@ +# Argo CD Security + +{{#include ../banners/hacktricks-training.md}} + +## 基本情報 + +[Argo CD](https://argo-cd.readthedocs.io/) は、Kubernetes 向けの GitOps 継続的デリバリープラットフォームです。Git リポジトリを監視し、Helm、Kustomize、Jsonnet、または config management plugins などのツールで Kubernetes manifests をレンダリングし、Git に保存された desired state と live cluster state を照合します。 + +攻撃者の視点では、Argo CD は Kubernetes credentials を持つ **deployment engine** として扱ってください。Argo CD の有効な compromise は、次のような結果につながる可能性があります。 + +- Private Git repositories と repository credentials へのアクセス。 +- Argo CD が使用する Kubernetes cluster secrets へのアクセス。 +- `argocd-repo-server` における manifest generation code execution。 +- trusted Git repositories、Argo CD applications、または cache manipulation を通じた unauthorized な Kubernetes object deployment。 + +## Architecture & Interesting Components + +一般的な Kubernetes objects と services: +```bash +kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd' +kubectl get applications,appprojects,applicationsets -A 2>/dev/null +kubectl get secrets,configmaps -n argocd 2>/dev/null +kubectl get networkpolicy -n argocd 2>/dev/null +``` +興味深いサービス: + +- **`argocd-server`**: public API、web UI、CLI API、authentication と authorization。 +- **`argocd-application-controller`**: desired state と live state を比較し、その後 Kubernetes に resources を適用する。 +- **`argocd-repo-server`**: repositories を clone し、Git data を cache し、Helm/Kustomize/Jsonnet/plugins を実行して manifests を生成する。デフォルトの gRPC port は **8081**。 +- **`argocd-redis`**: application、manifest、Git reference data の cache。デフォルトの Redis port は **6379**。 +- **`argocd-applicationset-controller`**: Git、SCM、clusters、pull requests などの generators から Argo CD `Application` objects を生成する。 + +compromised pod または internal network segment から、internal reachability を確認する: +```bash +nc -vz 443 +nc -vz 8081 +nc -vz 6379 +``` +## Public API / UI Attacks + +Argo CDのcredentialsまたは公開されたinstanceがあるなら、通常のAPI surfaceから始める: +```bash +argocd login +argocd account get-user-info +argocd account list +argocd proj list +argocd app list +argocd repo list +argocd cluster list +argocd admin settings rbac can +``` +有用なattack paths: + +- **Application write access**: `source.repoURL`, `source.path`, Helm values, Kustomize options, plugin settings or sync optionsを変更して、Argo CDにattacker-controlled manifestsをdeployさせる。 +- **Project misconfiguration**: `AppProject` objectsは、広い `sourceRepos`、広い `destinations`、unsafeな `clusterResourceWhitelist`、または弱いnamespace restrictionsを許可できる。 +- **Repository credential abuse**: repository secrets、GitHub App credentials、SSH keys、tokensにより、trusted reposへのpushやmalicious dependenciesの追加が可能になる。 +- **Cluster credential abuse**: cluster secretsには、Argo CDがtarget clustersへdeployするために使うbearer tokensやexec-provider configurationが含まれている場合がある。 +- **Local admin / project tokens**: 長寿命のArgo CD tokensは、revokeされるか期限切れになるまでAPI経由で再利用できる。 + +cluster read accessがある場合は、Kubernetesからconfigurationを列挙する: +```bash +kubectl get applications.argoproj.io -A -o yaml +kubectl get appprojects.argoproj.io -A -o yaml +kubectl get applicationsets.argoproj.io -A -o yaml +kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey' +kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml +``` +## Trusted Git Repository Abuse + +Argo CD が信頼している repository に push できる場合、通常は何がデプロイされるかに影響を与えられます。影響は `AppProject` の境界と、application controller が使う service account の権限に依存します。 + +一般的な payload の場所: + +- application path 配下の生の Kubernetes YAML。 +- Helm chart templates と `values.yaml`。 +- Kustomize overlays、remote bases、generators。 +- Jsonnet または config management plugin の入力。 +- `Application` objects を作成または更新する ApplicationSet generator files。 + +app が automated sync、pruning、self-heal、sync windows、または manual approvals を使っているか確認します: +```bash +kubectl get applications.argoproj.io -A \ +-o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server' +``` +## `argocd-repo-server` の直接的な悪用 + +公開されている Argo CD API だけが attack surface だと仮定しないでください。内部の Argo CD コンポーネントは `argocd-repo-server` と gRPC 経由で通信します。任意の pod が repo-server に到達できる場合、攻撃者が制御する内部リクエストによって、通常 `argocd-server` によって強制されるチェックを bypass できる可能性があります。 + +実践的な確認事項: +```bash +kubectl get svc -n argocd argocd-repo-server -o yaml +kubectl get endpoints -n argocd argocd-repo-server -o wide +nc -vz 8081 +``` +興味深い兆候: + +- repo-server の gRPC endpoint が非 Argo CD pod から到達可能。 +- NetworkPolicies が欠落しているか、deny ingress なしで allow-list egress のみになっている。 +- repo-server が custom config management plugins、decryption tools、または複数 tenant の repository content にアクセスできる。 +- Redis が非 Argo CD pod から到達可能で、credentials が利用可能、または不要な場合に cache の inspection や tampering ができる。 + +## Kustomize Options 経由の Unauthenticated Repo-Server RCE + +2026年7月、Synacktiv は、攻撃者が内部 gRPC service に到達できる場合の Argo CD の `repo-server` における unauthenticated code execution chain を公開した。攻撃は、`/repository.RepoServerService/GenerateManifest` への direct access と、攻撃者制御の `KustomizeOptions` を悪用する。 + +危険な primitive は、repo-server に攻撃者制御の repository content を clone させ、Helm support 付きで Kustomize を実行させることだ: +```bash +kustomize build --enable-helm --helm-command ./payload.sh +``` +Helm processing をトリガーするために必要な最小の悪意ある Kustomize input: +```yaml +helmCharts: +- name: pwn +version: 0.0.1 +``` +なぜこれが動くのか: + +- `argocd-repo-server` は rendering の前に repository を clone する。 +- `--helm-command ./payload.sh` は cloned repository を基準に相対解決される。 +- attacker が rendered repository と Kustomize build options を制御できるなら、code execution に shell metacharacter injection は不要。 + +Synacktiv の 2026年7月1日の disclosure 時点では、この issue には official fix も CVE もないと報告されていた。まずは network-exposure issue として扱うこと: exploitation には internal repo-server gRPC port への reachability が必要。 + +## Redis Cache Poisoning to Deploy Manifests + +`argocd-repo-server` で code execution ができた後、または valid credentials を使って Redis に direct access した後は、Redis-backed cache entries を調べる。Argo CD は一般に gzip-compressed JSON values を保存する。 + +興味深い key prefixes: +```text +mfst|... # cached rendered manifests +git-refs|... # Git branch/ref to commit mappings +app|... # application resource/cache data +cluster|... # cluster cache information +``` +Synacktiv によって説明された cache poisoning attack は、2 つの state を悪用します。 + +1. 対象の `mfst|...` manifest cache entry を変更して、attacker-controlled な Kubernetes manifest を含める。 +2. 関連する `git-refs|...` mapping を変更して、Argo CD に branch が移動したと誤認させ、その後 cached revision に再度 reconcile させる。 + +Impact: + +- Auto Sync が有効な場合、Argo CD は poisoned された cached manifest を自動的に apply する可能性があります。 +- Auto Sync が無い場合でも、ユーザーが application を手動で sync した際に payload が apply される可能性があります。 +- 最終的な impact は、target application の destination と、Argo CD に付与された Kubernetes permissions によって制限されます。 + +## ApplicationSet Attacks + +ApplicationSet は特に sensitive です。なぜなら、generator output から `Application` objects を作成または更新するからです。 + +Review: +```bash +kubectl get applicationsets.argoproj.io -A -o yaml +kubectl get appprojects.argoproj.io -A -o yaml +``` +興味深いパターン: + +- 攻撃者が書き込み可能なファイルを読み取る Git generators で、app names、paths、projects、destinations を制御できる。 +- public repositories の Pull request generators で、trusted されていない contributors が generated applications に影響を与えられる。 +- broad な destination clusters/namespaces を許可する template fields。 +- `sourceRepos: ["*"]` や broad な `destinations` を許可する AppProjects。 +- automated sync と pruning を継承する generated applications。 + +## Post-Exploitation + +Argo CD pod shell からは、次を優先: +```bash +env +cat /proc/1/environ 2>/dev/null | tr '\0' '\n' +find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null +mount | grep -E 'secret|token|config' +``` +Useful objectives: + +- `REDIS_PASSWORD` や Redis TLS/client material を盗む。 +- マウントされた secrets や Argo CD Kubernetes secrets から repository credentials を抽出する。 +- Argo CD が使用する cluster credentials を特定する。 +- 生成された manifests と、注入された secrets を含む可能性のある plugin output を読む。 +- custom plugins、SOPS、Helm secrets、Vault plugins、または cloud CLIs が decryption keys と cloud credentials を露出していないか確認する。 + +## Detection & Hardening + +Important checks: + +- NetworkPolicies で `argocd-repo-server` の port **8081** と Redis port **6379** を制限し、想定された Argo CD components だけが到達できるようにする。 +- Helm deployments では、network policies が実際に作成されることを確認する。Argo CD Helm chart values は historically、component の network policy creation を disabled にしていた。 +- `argocd-server` を authenticated entry point として維持する。内部 services は任意の workloads から到達できてはいけない。 +- 未使用の config management tools と plugins を無効化する。 +- `AppProject` の `sourceRepos`、`destinations`、namespace permissions、cluster-scoped resources を制限する。 +- 低権限の Argo CD user が再利用を引き起こせるような広い repository credentials の保存を避ける。 +- repo-server requests、Kustomize build options、plugin executions、Redis writes、そして `mfst|` / `git-refs|` keys への予期しない access を監視する。 +- compromise 後は Argo CD local users、project tokens、repository credentials、cluster credentials を rotate する。 + +Useful commands: +```bash +kubectl get networkpolicy -n argocd +kubectl get networkpolicy -A | grep -i argocd +kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null +kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null +``` +## CodeQL における Static Analysis Note: Typed API Requests + +Go services で gRPC/REST handlers を使う場合、raw input が typed request objects に unmarshal された後は、default の CodeQL remote sources では flow を見逃すことがあります。Argo CD-style の services に有用な model は次のとおりです: + +- `Server` や `Service` のような receiver type. +- First parameter は `context.Context`. +- Second parameter は typed request object. + +その second parameter を remote source として model し、`exec.Command` / `exec.CommandContext` の arguments に custom sinks を追加します。これにより、internal API request fields から command execution helpers への flow を見つけやすくなります。 + +## References + +- [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql) +- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/) +- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/) +- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/) +- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml) +- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/) +- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md) +- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md) diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index f630b9254..63c0cb27e 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,7 +6,7 @@ ## VCS -VCS は **Version Control System** の略で、このシステムは開発者が **ソースコードを管理** することを可能にします。最も一般的なのは **git** で、通常は以下の **platforms** のいずれかで使われています。 +VCS は **Version Control System** の略で、このシステムは開発者が **source code を管理**することを可能にします。最も一般的なのは **git** で、通常は次の **platforms** のいずれかで企業が使っているのを見つけるでしょう。 - Github - Gitlab @@ -18,39 +18,39 @@ VCS は **Version Control System** の略で、このシステムは開発者が ## CI/CD Pipelines -CI/CD pipelines は、開発者がビルド、テスト、デプロイなどのさまざまな目的で **コードの実行を自動化** できるようにします。これらの自動化されたワークフローは、コードの push、pull request、スケジュールされたタスクなどの特定のアクションによって **トリガー** されます。開発から本番までのプロセスを効率化するのに役立ちます。 +CI/CD pipelines により、開発者はビルド、テスト、アプリケーションのデプロイなど、さまざまな目的で **code の実行を自動化**できます。これらの自動化されたワークフローは、code の push、pull request、scheduled task などの特定のアクションによって **triggered** されます。開発から本番までのプロセスを効率化するのに役立ちます。 -ただし、これらのシステムは **どこかで実行** される必要があり、通常はコードをデプロイしたり機密情報へアクセスしたりするための **特権付き認証情報** を伴います。 +しかし、これらのシステムは **どこかで実行される必要があり**、通常は code のデプロイや機密情報へのアクセスのために **privileged credentials** が必要です。 ## VCS Pentesting Methodology > [!NOTE] -> 一部の VCS platforms ではこのセクション向けに pipeline を作成できますが、ここではソースコードの制御に対する潜在的な攻撃のみを分析します。 +> 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. -プロジェクトのソースコードを含む platforms には機密情報が含まれており、この platform 内で付与される権限には細心の注意が必要です。以下は、攻撃者が悪用できる VCS platforms に共通する問題です。 +プロジェクトの source code を含む platform には機密情報が含まれており、この platform 内で付与される権限には非常に注意する必要があります。以下は、attacker が悪用できる可能性がある VCS platform に共通する問題です。 -- **Leaks**: コミット内のコードに leak が含まれていて、攻撃者が repo にアクセスできれば（公開されている、またはアクセス権を持っているため）、その leak を見つけられる可能性があります。 -- **Access**: 攻撃者が **VCS platform 内のアカウントにアクセス** できれば、**より多くの可視性と権限** を得られる可能性があります。 -- **Register**: 一部の platforms では外部ユーザーがアカウントを作成できるだけです。 -- **SSO**: 一部の platforms ではユーザー登録はできませんが、有効な SSO があれば誰でもアクセスできます（たとえば攻撃者は自身の github アカウントで入れる）。 -- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... repo に何らかの形でアクセスするためにユーザーが盗める token にはいくつかの種類があります。 -- **Webhooks**: VCS platforms は webhook を生成できます。非公開の secret で保護されていない場合、**攻撃者が悪用できる** 可能性があります。 -- secret が設定されていなければ、攻撃者は third party platform の webhook を悪用できます -- secret が URL に含まれている場合も同様で、攻撃者は secret も入手してしまいます -- **Code compromise:** 悪意ある攻撃者が repo に対して何らかの **write** アクセスを持っている場合、**悪意あるコードを注入** しようとするかもしれません。成功するために、**branch protections を回避** する必要がある場合があります。これらの行為は、さまざまな目的で実行され得ます。 -- main branch を侵害して **production を侵害** する。 -- main（または他の branches）を侵害して **developers machines を侵害** する（通常、彼らは自身の machine 上で repo 内の test、terraform、その他の処理を実行するため）。 -- **pipeline を侵害する**（次のセクションを参照） +- **Leaks**: コミット内に code の leaks があり、attacker が repo にアクセスできる場合（公開されている、またはアクセス権があるため）、leaks を発見できる可能性があります。 +- **Access**: attacker が **VCS platform 内のアカウントに access できる**場合、**より多くの可視性と権限**を得られる可能性があります。 +- **Register**: 一部の platform は外部ユーザーによるアカウント作成をそのまま許可します。 +- **SSO**: 一部の platform はユーザー登録を許可しませんが、有効な SSO があれば誰でも access できるようにします（そのため attacker は例えば自身の github アカウントを使って侵入できます）。 +- **Credentials**: Username+Pwd、personal token、ssh key、Oauth token、cookie... repo に access するためにユーザーから steal されうる token はいくつもあります。 +- **Webhooks**: VCS platform は webhooks を生成できます。外から見えない secret で **保護されていない**場合、**attacker が悪用できる**可能性があります。 +- secret が設定されていなければ、attacker は third party platform の webhook を悪用できます +- secret が URL に含まれている場合も同様で、attacker はその secret も入手できます +- **Code compromise:** 悪意ある actor が repo に対して何らかの **write** access を持っている場合、**malicious code を注入**しようとする可能性があります。成功させるには、**branch protections を bypass** する必要があるかもしれません。これらの行為は、いくつかの目的で実行できます。 +- main branch を compromise して **production を compromise** する。 +- main（または他の branches）を compromise して **developers machines を compromise** する（通常、彼らは自身のマシン上で repo 内の test、terraform、その他の処理を実行するため）。 +- **pipeline を compromise する**（次の section を確認） ## Pipelines Pentesting Methodology -pipeline を定義する最も一般的な方法は、pipeline がビルドする repository 内にホストされた **CI configuration file** を使うことです。この file は、実行される jobs の順序、フローに影響する条件、build environment settings を記述します。\ -これらの files は通常、Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI)、および .github/workflows 配下にある GitHub Actions の YAML files など、一貫した名前と形式を持ちます。トリガーされると、pipeline job は選択された source（例: commit / branch）から **code を取得** し、その code に対して CI configuration file で指定された **commands を実行** します。 +pipeline を定義する最も一般的な方法は、pipeline が build する repo にホストされた **CI configuration file** を使うことです。この file には、実行される job の順序、flow に影響する条件、build environment の設定が記述されています。\ +これらの file は通常、Jenkinsfile (Jenkins)、.gitlab-ci.yml (GitLab)、.circleci/config.yml (CircleCI)、および .github/workflows 配下にある GitHub Actions の YAML file など、一定の name と format を持ちます。triggered されると、pipeline job は選択された source（例: commit / branch）から **code を pull** し、CI configuration file に指定された commands をその code に対して **実行**します。 -したがって、攻撃者の最終目標は、何らかの方法でそれらの **configuration files** またはそれらが実行する **commands** を **侵害** することです。 +したがって、attacker の最終目標は、何らかの方法で **それらの configuration file を compromise すること**、または **それらが実行する commands を compromise すること**です。 > [!TIP] -> 一部の hosted builders では、contributors が Docker build context と Dockerfile path を選択できます。context が attacker-controlled なら、build 中に host files を取り込んで secrets を exfiltrate するために repo 外（例: ".."）を指定できます。参照: +> 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: > >{{#ref}} >docker-build-context-abuse.md @@ -58,72 +58,73 @@ pipeline を定義する最も一般的な方法は、pipeline がビルドす ### PPE - Poisoned Pipeline Execution -Poisoned Pipeline Execution (PPE) path は、SCM repository 内の権限を悪用して CI pipeline を操作し、害のある commands を実行します。必要な権限を持つ users は、CI configuration files や pipeline job が使用する他の files を変更して malicious commands を含めることができます。これにより CI pipeline が「poison」され、これらの malicious commands が実行されます。 +Poisoned Pipeline Execution (PPE) は、SCM repository の permissions を悪用して CI pipeline を操作し、有害な commands を実行する path です。必要な permissions を持つユーザーは、CI configuration file や pipeline job で使われる他の file を変更して malicious commands を含めることができます。これにより CI pipeline が「poison」され、これらの malicious commands が実行されます。 -悪意ある actor が PPE attack を成功させるには、以下が必要です。 +attacker が PPE attack に成功するには、以下が必要です。 -- 通常、pipeline は push または pull request が行われたときにトリガーされるため、**VCS platform への write access** を持つこと。（アクセス方法の要約は VCS pentesting methodology を確認してください）。 -- 場合によっては **external PR が "write access" と見なされる** 点に注意してください。 -- write 権限があっても、**CI config file または config が依存している他の files を変更できる** ことを確認する必要があります。 -- そのために、**branch protections を回避** できる必要があるかもしれません。 +- 通常 pipeline は push や pull request が行われたときに triggered されるため、**VCS platform への write access** を持つこと。（access を得る方法の概要は VCS pentesting methodology を確認） +- 場合によっては、**external PR が "write access" と見なされる**ことに注意。 +- write 権限があっても、**CI config file または config が依存する他の file を変更できる**ことを確認する必要があります。 +- そのために、**branch protections を bypass** できる必要があるかもしれません。 -PPE には 3 つの種類があります。 +PPE には 3 種類あります。 -- **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**: 場合によっては、pipeline は repo への write access を持たない users（org の一員ですらない可能性がある）によってもトリガーされます。PR を送信できるためです。 -- **3PE Command Injection**: 通常、CI/CD pipelines は PR に関する **情報を含む environment variables** を **設定** します。その値が攻撃者によって制御可能で（たとえば PR の title など）、かつ **危険な場所**（**sh commands** の実行など）で **使用** される場合、攻撃者はそこに **commands を注入** できる可能性があります。 +- **D-PPE**: actor が実行される **CI config** file を **modifies** する場合に起こる **Direct PPE** attack。 +- **I-DDE**: actor が実行される **CI config file が依存している** **file** を **modifies** する場合に起こる **Indirect PPE** attack。（make file や terraform config など） +- **Public PPE or 3PE**: 場合によっては、pipeline は repo に write access を持たないユーザー（org の一員でさえない可能性がある）によっても **triggered** されます。PR を送信できるからです。 +- **3PE Command Injection**: 通常、CI/CD pipelines は PR に関する **情報を持つ environment variables** を **set** します。その値が attacker によって制御可能で（PR の title など）、かつ **dangerous place**（**sh commands** の実行など）で **used** される場合、attacker はそこに commands を **inject** できる可能性があります。 ### Exploitation Benefits -pipeline を poison する 3 つの種類を理解したら、攻撃者が成功した exploitation の後に何を得られるかを見ていきます。 +pipeline を poison する 3 つの種類を理解したところで、成功した exploitation の後に attacker が何を得られるかを確認しましょう。 -- **Secrets**: 前述のとおり、pipelines の jobs には（code の取得、build、deploy などのための）**特権** が必要であり、この特権は通常 **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 にアクセスできる内部 network** に到達する可能性があります。 -- **Cloud**: 攻撃者は **他の cloud 上の machines** にアクセスできるだけでなく、そこで IAM roles/service accounts **tokens** を exfiltrate して、cloud 内のさらなる access を得られる可能性があります。 -- **Platforms machine**: 場合によっては jobs が **pipelines platform machines** 内で実行されますが、通常は cloud 内にあり、**それ以上の access はありません**。 -- **Select it:** 場合によっては、**pipelines platform が複数の machines を構成している** ことがあり、CI configuration file を **変更できる** なら、悪意ある code をどこで実行するかを **指定** できます。この状況では、攻撃者はおそらく可能な各 machine 上で reverse shell を実行し、さらに exploitation を試みます。 -- **Compromise production**: あなたが pipeline 内にいて、最終版がそこから build され deploy されるなら、本番環境で実行される code を **侵害** できる可能性があります。 +- **Secrets**: 先述のとおり、pipeline の job には **privileges** が必要です（code の取得、build、deploy など）。これらの privileges は通常 **secrets に格納**されています。これらの secrets は通常、**env variables や system 内の file** からアクセスできます。そのため attacker は常に、できるだけ多くの secrets を exfiltrate しようとします。 +- pipeline platform によっては、attacker が **config に secrets を指定する必要がある**場合があります。つまり、attacker が CI configuration pipeline（例えば **I-PPE**）を変更できない場合、その pipeline が持つ secrets だけを **exfiltrate** できるということです。 +- **Computation**: code はどこかで実行されます。どこで実行されるかによっては、attacker はさらに pivot できる可能性があります。 +- **On-Premises**: pipelines が on premises で実行されている場合、attacker は **より多くの resources に access できる internal network** に到達する可能性があります。 +- **Cloud**: attacker は **cloud 内の他の machine** に access できるだけでなく、そこから IAM roles/service accounts の **tokens を exfiltrate** して、cloud 内でさらに access を得られる可能性があります。 +- **Platforms machine**: job が **pipelines platform machines** 上で実行されることがあり、通常それらは cloud 内にあるものの、**それ以上の access はありません**。 +- **Select it:** 場合によっては **pipelines platform が複数の machine を設定**しており、CI configuration file を **modify** できるなら、悪意ある code をどこで実行するかを **指定**できます。この状況では attacker は、おそらく利用可能な各 machine で reverse shell を実行して、さらに exploit しようとするでしょう。 +- **Compromise production**: pipeline 内に入り、最終版がそこから build され deploy される場合、**production で最終的に実行される code を compromise** できます。 ### Dependency & Registry Supply-Chain Abuse -CI/CD pipeline を侵害したり、そこから認証情報を盗んだりすると、dependencies や release tooling を backdoor 化することで、攻撃者は **pipeline execution** から **ecosystem-wide code execution** へ移行できる可能性があります。 +CI/CD pipeline を compromise したり、そこから credentials を steal したりすると、dependencies や release tooling を backdoor することで、attacker は **pipeline execution** から **ecosystem-wide code execution** へ移行できます。 -- **Install-time code execution via package hooks**: `preinstall`, `postinstall`, `prepare` などの hook を追加した package version を公開し、dependency installation 中に developer workstations と CI runners の両方で payload が自動実行されるようにする。 -- **Secondary execution paths**: たとえ targets が `--ignore-scripts` で install しても、悪意ある package は `bin` field に **共通の CLI name** を登録できるため、攻撃者が制御する 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 を収集し、その後一時的な branch/workflow run を削除して痕跡を減らせる。 -- **Wormable registry propagation**: 盗んだ npm tokens は **publish** permissions と 2FA を回避できるかを検証するべきです。回避できるなら、書き込み可能な packages を列挙し、それらの tarballs をダウンロードして、`setup.mjs` のような loader を注入し、`preinstall` でそれを実行するように設定し、patch version を上げて再公開します。これにより、1 回の CI compromise が他の環境での下流の auto-execution へと変わります。 +- **Install-time code execution via package hooks**: `preinstall`、`postinstall`、`prepare` などの hooks を追加した package version を publish し、dependency の install 中に developer workstation や CI runner 上で payload が自動的に実行されるようにする。 +- **Secondary execution paths**: targets が `--ignore-scripts` で install していても、malicious package は `bin` field に **common CLI name** を登録できるため、attacker-controlled wrapper が `PATH` 内に symlink され、後でその command が使われたときに実行されます。 +- **Runtime bootstrapping**: 小さな installer が install 中に second runtime や toolchain（例えば Bun や packed interpreter）を download し、それを使って main payload を起動することで、local 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**: steal した npm tokens については、**publish** 権限があるか、2FA を bypass できるかを確認すべきです。可能であれば、書き込み可能な packages を列挙し、tarball を download して、`setup.mjs` のような loader を inject し、`preinstall` でそれを実行するように設定し、patch version を上げて再 publish します。これにより、1 回の CI compromise が他の environment での downstream auto-execution に変わります。 #### 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 を書き込んだり branch/tag を作成できるか検証する。 -- 侵害された package が疑われる場合は、Git repository だけでなく公開された tarball も調査する。悪意ある loader/runtime は公開 artifact のみに存在する可能性があるため。 -- `npm install` の代わりに `npm ci` ではない、予期しない Bun のダウンロード/実行、新しい workflow artifacts が一時的な branches から生成されていないかなど、CI 内での予期しない package-manager execution を探す。 +- `package.json` に追加された package-manager hooks、予期しない `bin` entries、または release artifact だけを変更する version bump がないか release automation を確認する。 +- CI が短命な OIDC や trusted publishing ではなく、`~/.npmrc` のような plaintext file に長期的な registry credentials を保存していないか確認する。 +- CI で利用可能な GitHub tokens が workflow files を書き込めるか、branch/tag を作成できるかを検証する。 +- compromised package が疑われる場合は、Git repository だけでなく published tarball も確認すること。malicious loader/runtime は published artifact にのみ存在する可能性があるためです。 +- CI 内で `npm install` のような予期しない package-manager execution がないか、`npm ci` の代わりに使われていないか、予期しない Bun の download/execution がないか、または transient branches から新しい workflow artifacts が生成されていないかを調べる。 +- GitOps deployment engines も CI/CD targets として確認する。Argo CD 固有の enumeration、repo-server の悪用、Redis cache poisoning attacks は [Argo CD Security](argocd-security.md) に記載されています。 ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time. +- [**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 です。この auditing は SDLC process 全体に焦点を当てており、code time から deploy time までの risk を明らかにできます。 ### Top 10 CI/CD Security Risk -Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Cider による CI/CD risks のトップ 10 についての興味深い article を確認してください: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it +- ローカルで実行できる各 platform では、ローカルでの起動方法が示されており、好きなように configure して 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** is a static code analysis tool for infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** は infrastructure-as-code 向けの static code analysis tool です。 ## References