Pentesting CI/CD Methodology

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする

VCS

VCS は Version Control System の略で、このシステムは開発者が ソースコードを管理 することを可能にします。最も一般的なのは git で、通常は以下の platforms のいずれかで使われています。

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines は、開発者がビルド、テスト、デプロイなどのさまざまな目的で コードの実行を自動化 できるようにします。これらの自動化されたワークフローは、コードの push、pull request、スケジュールされたタスクなどの特定のアクションによって トリガー されます。開発から本番までのプロセスを効率化するのに役立ちます。

ただし、これらのシステムは どこかで実行 される必要があり、通常はコードをデプロイしたり機密情報へアクセスしたりするための 特権付き認証情報 を伴います。

VCS Pentesting Methodology

Note

一部の VCS platforms ではこのセクション向けに pipeline を作成できますが、ここではソースコードの制御に対する潜在的な攻撃のみを分析します。

プロジェクトのソースコードを含む platforms には機密情報が含まれており、この platform 内で付与される権限には細心の注意が必要です。以下は、攻撃者が悪用できる VCS platforms に共通する問題です。

  • 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 を侵害する（次のセクションを参照）

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 を実行 します。

したがって、攻撃者の最終目標は、何らかの方法でそれらの configuration files またはそれらが実行する commands を 侵害 することです。

Tip

一部の hosted builders では、contributors が Docker build context と Dockerfile path を選択できます。context が attacker-controlled なら、build 中に host files を取り込んで secrets を exfiltrate するために repo 外（例: “..”）を指定できます。参照:

{{#ref}} docker-build-context-abuse.md {{#endref}}

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 が実行されます。

悪意ある actor が 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 を回避 できる必要があるかもしれません。

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 を注入 できる可能性があります。

Exploitation Benefits

pipeline を poison する 3 つの種類を理解したら、攻撃者が成功した exploitation の後に何を得られるかを見ていきます。

  • 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 を 侵害 できる可能性があります。

Dependency & Registry Supply-Chain Abuse

CI/CD pipeline を侵害したり、そこから認証情報を盗んだりすると、dependencies や release tooling を backdoor 化することで、攻撃者は 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 へと変わります。

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 を探す。

More relevant info

Tools & CIS Benchmark

  • 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. The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.

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/

Labs

Automatic Tools

  • Checkov: Checkov is a static code analysis tool for infrastructure-as-code.

References

Tip

学んで実践する AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学んで実践する GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学んで実践する Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks をサポートする