Pentesting CI/CD Methodology

Reading time: 15 minutes

VCS

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

• Github
• Gitlab
• Bitbucket
• Gitea
• クラウドプロバイダー（独自のVCSプラットフォームを提供）

CI/CD Pipelines

CI/CDパイプラインは、開発者がコードの実行を自動化することを可能にし、アプリケーションのビルド、テスト、デプロイなどのさまざまな目的に使用されます。これらの自動化されたワークフローは、コードのプッシュ、プルリクエスト、またはスケジュールされたタスクなどの特定のアクションによってトリガーされます。これにより、開発から本番環境へのプロセスが効率化されます。

ただし、これらのシステムはどこかで実行される必要があり、通常はコードをデプロイしたり、機密情報にアクセスするための特権的な資格情報が必要です。

VCS Pentesting Methodology

プロジェクトのソースコードを含むプラットフォームは機密情報を含んでおり、人々はこのプラットフォーム内で付与された権限に非常に注意する必要があります。攻撃者が悪用できるVCSプラットフォーム全体での一般的な問題は以下の通りです：

• Leaks: コードにコミット内の漏洩が含まれており、攻撃者がリポジトリにアクセスできる場合（公開されているか、アクセス権を持っている場合）、漏洩を発見する可能性があります。
• Access: 攻撃者がVCSプラットフォーム内のアカウントにアクセスできる場合、より多くの可視性と権限を得ることができます。
• Register: 一部のプラットフォームでは、外部ユーザーがアカウントを作成することを許可します。
• SSO: 一部のプラットフォームではユーザーの登録を許可しませんが、有効なSSOでアクセスすることは許可します（例えば、攻撃者が自分のgithubアカウントを使用して入ることができます）。
• Credentials: ユーザー名+パスワード、個人トークン、sshキー、Oauthトークン、クッキー... ユーザーがリポジトリにアクセスするために盗むことができるトークンの種類はさまざまです。
• Webhooks: VCSプラットフォームはウェブフックを生成することを許可します。これらが見えない秘密で保護されていない場合、攻撃者がそれを悪用する可能性があります。
• 秘密が設定されていない場合、攻撃者はサードパーティプラットフォームのウェブフックを悪用する可能性があります。
• 秘密がURLに含まれている場合も同様で、攻撃者は秘密を持っています。
• Code compromise: 悪意のある行為者がリポジトリに対して書き込みアクセスを持っている場合、悪意のあるコードを注入しようとする可能性があります。成功するためには、ブランチ保護を回避する必要があるかもしれません。これらの行動は、さまざまな目的を持って実行される可能性があります：
• メインブランチを妥協して本番環境を妥協する。
• メイン（または他のブランチ）を妥協して開発者のマシンを妥協する（彼らは通常、テスト、terraform、または他の作業を自分のマシン内のリポジトリで実行します）。
• パイプラインを妥協する（次のセクションを確認）。

Pipelines Pentesting Methodology

パイプラインを定義する最も一般的な方法は、パイプラインがビルドするリポジトリにホストされたCI構成ファイルを使用することです。このファイルは、実行されるジョブの順序、フローに影響を与える条件、およびビルド環境の設定を記述します。
これらのファイルは通常、一貫した名前と形式を持ち、例えば — Jenkinsfile（Jenkins）、.gitlab-ci.yml（GitLab）、.circleci/config.yml（CircleCI）、および.github/workflowsの下にあるGitHub Actions YAMLファイルです。トリガーされると、パイプラインジョブは選択されたソースからコードをプルし、そのコードに対してCI構成ファイルに指定されたコマンドを実行します。

したがって、攻撃者の最終的な目標は、何らかの方法でこれらの構成ファイルまたはそれらが実行するコマンドを妥協することです。

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution（PPE）パスは、SCMリポジトリ内の権限を悪用してCIパイプラインを操作し、有害なコマンドを実行します。必要な権限を持つユーザーは、CI構成ファイルやパイプラインジョブで使用される他のファイルを変更して悪意のあるコマンドを含めることができます。これにより、CIパイプラインが「汚染」され、これらの悪意のあるコマンドが実行されます。

悪意のある行為者がPPE攻撃を成功させるためには、以下のことができる必要があります：

• VCSプラットフォームへの書き込みアクセスを持つ必要があります。通常、パイプラインはプッシュまたはプルリクエストが行われたときにトリガーされます。（アクセスを得る方法の概要についてはVCSペンテスティング方法論を確認してください）。
• 時には外部PRが「書き込みアクセス」としてカウントされることに注意してください。
• 書き込み権限があっても、CI構成ファイルや構成が依存している他のファイルを変更できることを確認する必要があります。
• そのためには、ブランチ保護を回避する必要があるかもしれません。

PPEには3つのフレーバーがあります：

• D-PPE: Direct PPE攻撃は、行為者が実行されるCI構成ファイルを変更するときに発生します。
• I-DDE: Indirect PPE攻撃は、行為者が実行されるCI構成ファイルが依存しているファイル（makeファイルやterraform構成など）を変更するときに発生します。
• Public PPEまたは3PE: 場合によっては、パイプラインはリポジトリに書き込みアクセスを持たないユーザーによってトリガーされることがあります（彼らは組織の一部でない可能性もあります）なぜなら、彼らはPRを送信できるからです。
• 3PE Command Injection: 通常、CI/CDパイプラインはPRに関する情報を持つ環境変数を設定します。その値が攻撃者によって制御でき（PRのタイトルのように）、危険な場所で使用される場合（shコマンドを実行するなど）、攻撃者はそこにコマンドを注入する可能性があります。

Exploitation Benefits

パイプラインを汚染する3つのフレーバーを知ることで、攻撃者が成功した悪用の後に得られるものを確認しましょう：

• Secrets: 前述のように、パイプラインはそのジョブに特権を必要とします（コードを取得し、ビルドし、デプロイする...）これらの特権は通常秘密に付与されます。これらの秘密は通常、環境変数やシステム内のファイルを介してアクセス可能です。したがって、攻撃者は常にできるだけ多くの秘密を流出させようとします。
• パイプラインプラットフォームによっては、攻撃者が構成内で秘密を指定する必要がある場合があります。これは、攻撃者がCI構成パイプラインを変更できない場合（例えばI-PPE）、そのパイプラインが持つ秘密のみを流出させることができることを意味します。
• Computation: コードはどこかで実行され、実行される場所によっては、攻撃者がさらにピボットできる可能性があります。
• On-Premises: パイプラインがオンプレミスで実行される場合、攻撃者はより多くのリソースにアクセスできる内部ネットワークに到達する可能性があります。
• Cloud: 攻撃者はクラウド内の他のマシンにアクセスすることができるだけでなく、IAMロール/サービスアカウントのトークンを流出させて、クラウド内でさらにアクセスを得ることができます。
• Platforms machine: 時には、ジョブがパイプラインプラットフォームのマシン内で実行されることがあり、通常は他のアクセスがないクラウド内にあります。
• Select it: 時には、パイプラインプラットフォームが複数のマシンを構成していることがあり、CI構成ファイルを変更できれば、悪意のあるコードを実行したい場所を指定できます。この状況では、攻撃者はおそらく各可能なマシンでリバースシェルを実行して、さらに悪用しようとします。
• Compromise production: パイプライン内にいて、最終バージョンがそこからビルドされてデプロイされる場合、本番環境で実行されるコードを妥協することができます。

More relevant info

Tools & CIS Benchmark

• Chain-benchは、セキュリティコンプライアンスのためにソフトウェアサプライチェーンスタックを監査するオープンソースツールです。新しいCIS Software Supply Chain benchmarkに基づいています。監査は、コードのタイミングからデプロイのタイミングまでのリスクを明らかにするSDLCプロセス全体に焦点を当てています。

Top 10 CI/CD Security Risk

Ciderによるトップ10のCI/CDリスクに関する興味深い記事を確認してください：https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• 各プラットフォームでローカルに実行できるものには、テストするために構成できるようにローカルで起動する方法が記載されています。
• Gitea + Jenkinsラボ：https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkovは、インフラストラクチャコードの静的コード分析ツールです。

References

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422