11 KiB
Pentesting CI/CD 方法論
{{#include ../banners/hacktricks-training.md}}
VCS
VCS は Version Control System の略で、開発者が source code を管理するためのシステムです。最も一般的なのは git で、企業では通常次のような platforms のいずれかで使われています:
- Github
- Gitlab
- Bitbucket
- Gitea
- Gitblit
- Cloud providers (they offer their own VCS platforms)
CI/CD パイプライン
CI/CD pipelines は、ビルド、テスト、デプロイなどの目的で code の実行を自動化するための仕組みです。これらの自動化ワークフローは、コードの push、pull request、スケジュールされたタスクなどの特定のアクションによって trigger されます。開発から本番までの流れを効率化するために役立ちます。
しかし、これらのシステムはどこかで 実行される必要 があり、通常は privileged credentials を使って code をデプロイしたり機密情報にアクセスしたり します。
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.
プロジェクトの source code を含むプラットフォームには機密情報が含まれることが多く、権限の扱いには細心の注意が必要です。攻撃者が悪用できる VCS プラットフォーム全般で見られる一般的な問題をいくつか挙げます:
- 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（次のセクションを参照）
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 に対して 実行します。
したがって、攻撃者の究極の目的は、これらの configuration files、あるいはそれらが実行するコマンドを何らかの形で compromise することです。
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:
{{#ref}} docker-build-context-abuse.md {{#endref}}
PPE - Poisoned Pipeline Execution
Poisoned Pipeline Execution (PPE) パスは、SCM repository の権限を悪用して CI pipeline を操作し、悪意あるコマンドを実行させる手法です。必要な権限を持つユーザは CI configuration file や pipeline job が利用する他のファイルを修正して悪意あるコマンドを含めることができます。これにより CI pipeline が「poison」され、これらの悪意あるコマンドが実行されます。
攻撃者が PPE を成功させるには次の条件が必要です:
- VCS platform への write access を持っていること。通常パイプラインは push や pull request が行われたときにトリガーされます。（VCS pentesting methodology セクションでアクセス獲得の方法をまとめています）
- 場合によっては external PR が "write access" と見なされることがあります。
- 書き込み権限を持っていても、CI config file やその config が依存している他のファイルを実際に変更できることを確認する必要があります。
- そのために branch protections をバイパスする必要があるかもしれません。
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 の実行）で 使用される場合、攻撃者はそこへ コマンドを注入する可能性があります。
Exploitation Benefits
PPE の 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 できます。
More relevant info
Tools & CIS Benchmark
- Chain-bench は、CIS Software Supply Chain benchmark に基づき、ソフトウェアサプライチェーンのセキュリティ準拠性を監査するオープンソースツールです。監査はSDLC全体に焦点を当て、code の時点からデプロイ時点までのリスクを明らかにします。
Top 10 CI/CD Security Risk
Cider による CI/CD の上位 10 のリスクに関する興味深い記事を参照してください: https://www.cidersecurity.io/top-10-cicd-security-risks/
Labs
- ローカルで実行できる各プラットフォームについて、ローカル起動方法が記載されているので、自由に設定してテストできます
- Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat
Automatic Tools
- Checkov: Checkov は infrastructure-as-code 向けの static code analysis ツールです。
References
{{#include ../banners/hacktricks-training.md}}