ポイズンド・パイプライン:CI/CD 環境における攻撃メソッドについて

Poisoned pipelines: Security researcher explores attack methods in CI environments

2022/02/16 DailySwig — あるセキュリティ研究者が、Source Code Management (SCM) リポジトリのパーミッションを悪用することで、CI ポイズニング攻撃 (Poisoned Pipeline Attacks) につながることを解説している。Continuous Integration (CI)/Continuous Delivery (CD) プラットフォームを含む開発者のための環境は、コードのマージ/ソフトウェアビルドの自動化/テスト/DevOps プロジェクトへのコード提供のための、基本的なビルディング・ブロックである。

Cider Security の Head of Research である Omer Gil は、2月8日付のテクニカル・ブログで、CI/CD 環境は重要な機能を果たすが故に、組織の機密情報や認証情報が含まれていることが多く、今日の攻撃対象の主要な部分でもあると述べている。

CI/CD環境に侵入した攻撃者は、生産現場だけではなく、より広範囲なサプライチェーン攻撃のための配信メカニズムにアクセスできる可能性がある。最近の例では、SolarWinds や Codecov から配信されたポイズンド・ソフトウェア・アップデートや、Kaseya への侵入などがある。

ポイズンド・パイプラインの実行

2021年7月に European Union Agency for Cybersecurity (ENISA) は、2020年〜2021年のサプライチェーン・インシデントを調査した。そして、サイバー攻撃のおよそ 50% が Advanced Persistent Threat (APT) グループに起因するものであるが、インシデントの 42% は未知の攻撃によるものであると、そのレポートで述べている。

また ENISA は、サプライチェーン攻撃の 60% 以上が、サプライヤーに対する顧客の信頼を利用しており、サイバー攻撃の 66% が、ターゲットとなる顧客を危険にさらすために、サプライヤーのコードを標的にしていたと付け加えている。

Continuous Integration (CI) にアクセスしてサプライチェーンを攻撃するための最も簡単な方法は、そこにダイレクトにアクセスすることだ。しかし、Omer Gil によると、CI 環境に直接アクセスしなくても、ローカルな手法でプロダクション・パイプラインを改ざんすることも可能だという。

この PPE (Poisoned Pipeline Execution) と名付けられた手法は、パイプライン・リポジトリでホストされている CI コンフィグレーション・ファイルを使用してパイプラインを定義するという、一般的な方法にフォーカスしている。

これらのファイルは、Jenkinsfile/.gitlab-ci.yml/.circleci/config.yml/GitHub Actions YAML などの標準的なフォーマットで提供されており、パイプライン・ジョブが開発者のソースからコードを引き出す際に、起動されるコマンドを含んでいる。

攻撃者がコマンド・リストを改ざんできるなら、CI 内でコードを実行される可能性が生じる。したがって、ここで PPE が登場してくる。

CI パイプラインへの攻撃

ポイズンド ・パイプラインの攻撃ベクターでは、脅威アクターはユーザー認証やアクセス・トークンなどの SCM 権限を持つ必要があり、それにより、CI コンフィグレーション・ファイルなどのコンテンツを操作し、パイプラインのアクティビティを実行することになる。

また、攻撃者は、レビューをトリガーすることなく、これらのファイルを改ざんする必要がある。したがって、レビューされていないコードを実行するパイプラインは、PPE 攻撃の影響を受けやすいと、Omer Gil は述べている。

PPE は、いくつかのカテゴリーに分類される。

  • Direct (D-PPE) – ターゲット・プロジェクトと同じロケーションにある CI コンフィグレーション・ファイルの変更。
  • Indirect (I-PPE) – パイプラインのコンフィグレーション・ファイルから間接的に呼び出されるファイルに悪意のコードを注入。
  • Public (P-PPE/3PE) – 認証情報や許可を得た攻撃者が、パイプライン・コンフィグレーション・ファイルをホストするリポ ジトリに不正アクセス。また、公開されているプロジェクトでは、プルリクエストにより未審査のコードが受け入れられ、実行されることがある。

    コード実行の環境を確立した攻撃者は、CI に関連する機密情報へのアクセス、および、悪意のジョブのプッシュ、悪意のコードの提供、ジョブノードが権限を持つ外部リソースへのアクセス、追加のホストやリソースへのアクセスなどを行う可能性がある。

    Omer Gil は、「Source Code Management (SCM) の組織やリポジトリへのアクセスは、常に攻撃者により取得されていると考えるべきだ。クレデンシャル/アクセス・トークン/SSH キーなどは、フィッシング・クレデンシャル・スタッフィング/企業内ネットワークでの横移動などの、古典的な攻撃方法のいずれかにより盗まれる」とコメントしている。

    彼は、「PPE は、そのアクセスを活用する攻撃者が、CI パイプラインで悪意のコード実行を可能にするベクターであり、数分から数秒でプロダクション環境にアクセスできる道を開いている」とも述べている。

    Reddit においては、この攻撃ベクターについて、何か新しいことがあるかという質問や、アクセス許可の前提条件により PPE の全体的なリスクが否定されるのかという質問を行う人もいた。

    Synopsys Software Integrity Group の Principal Security Consultant である TravisBiehn は、「Omer Gil は、よく理解されていない攻撃ベクターに対して、彼の見解を提供している。それは、人騒がせなものではなく、誇張もされていない。おそらく、Omer にとってはそうなのだろう。しかし、攻撃者たちが選択するとは思えず、便利なシナリオではないだろう」と、DailySwig に語っている。

    AT&T Business の head of cybersecurity evangelism である Theresa Lanowitz は、 「すべての企業は、ソフトウェア企業であると言われている。デジタル・エクスペリエンスを構成するアプリケーションが、セキュリティ・ファーストのアプローチで構築されていない場合、脆弱性はプロダクション環境へと移行し、最終的には収益と信頼を損ない、一般的なセキュリティの観点からもビジネスに問題を引き起こす。したがって、現時点で開発され、また、将来に開発されるアプリケーションやアプレット (モノリシックなバックオフィス・アプリケーションは時代遅れ) は、よりコンパクトで目的に基づいたものであり、さらに、セキュリティを念頭に置いて構築される必要がある」と、付け加えている。

なぜ、SolarWindsCodecovKaseya への攻撃が生じたのか? それらの攻撃ベクターを明らかにする記事はみたことがありません。もちろん、判明していても、伏せておかれるという展開もあり得るので、なんとも言えませんが、不思議といえば不思議です。それが、Source Code Management (SCM) リポジトリのパーミッションを悪用する、CI ポイズニング攻撃 (Poisoned Pipeline Attacks) ではないかという見解ですが、反論もあるようです。議論が深まると良いですね。

%d bloggers like this: