This post is also available in: English (英語)
Unit 42の最新のクラウド脅威レポートには、弊社のあるお客様（SaaSプロバイダ）のCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインに対して実施されたレッドチーム演習の概要が含まれています。このお客様からのご依頼は、弊社リサーチャーに攻撃者の考えにならってSaaSプロバイダの開発運用(DevOps)プロセスに潜む脆弱性と設定ミスをあぶりだしてほしい、ということでした。レッドチーム演習では、現実の脅威を模倣し、既知の攻撃手法に対するセキュリティ能力を評価するため、SolarWindsのOrionサプライチェーン攻撃で使用された戦略と手法を手本としました。リサーチャーがインサイダー脅威役を演じます。目標はCI/CDパイプラインのコンポーネントを改変するに足るアクセス権を取得し、最終的にサプライチェーン攻撃を行える状況を作り出すことです。
演習でこのリサーチャーは組織のクラウド環境で管理者アクセス権（いわゆる「God Mode」）の取得に成功しました。その要因は社内のGitLabリポジトリに保存されていた、ハードコードされた26個のIAM (IDとアクセスの管理)キーペアです。(IAMキーペアとは、セキュリティ資格情報のセット(公開鍵と秘密鍵)であり、パブリック クラウド インスタンスに接続する際の身元証明に使用できます。IAMキーペアは文字通りクラウド環境への鍵であるため、キーペアへのアクセスは保護が必要です。特に、特権を持つロールに関連するキーペアは厳重に保護する必要があります。)
このSaaSプロバイダの場合、組織の開発者アカウントであれば誰でもGitLab環境の全リポジトリにアクセスできる状態でした。リサーチャーは、GitLabリポジトリに保存されていたいくつかのキーペアを使用して、組織のクラウド環境での権限を昇格させ、CI/CDパイプラインの侵害が可能なレベルの権限を得ることに成功しています。これにより、数百どころか数千の下流の顧客が影響を受ける可能性がありました。
リサーチャーが特定した50件以上のAWSアカウントのうち、Amazon GuardDuty (構成したAWSアカウントを絶えず監視して有害な活動を検出するAWSセキュリティツール)とPrisma Cloudプラットフォームの監視対象になっていたアカウントは1件だけでした。他の49件以上のAWSアカウントでは、こうしたセキュリティ対策が有効化されていなかったのです。幸運にも、組織のセキュリティ オペレーション センター(SOC)は、監視していた1件のAWSクラウドアカウントを通じて、リサーチャーの活動の一部を検出することに成功しています。
弊社では、近年現実に発生しているサプライチェーン攻撃を注意深く警戒しています。たとえば、「SolarStorm」と呼ばれるSolarWindsへの攻撃では、SaaSプロバイダのCI/CDパイプラインが標的となり、数千の下流の顧客が侵害を受けています。この種の重大な攻撃が実際に発生していることを考えると、今回のレッドチーム演習から得られた知見は重要であり、CI/CDアーキテクチャを運用するすべての組織に広めるべきものです。
以下のセクションではクラウドベースのSaaSプロバイダをターゲットとしたサプライチェーン攻撃がどのように進行するのかについての知見を提供します。解説には今回のレッドチーム演習でUnit 42のリサーチャーが使用した戦略と手法(クラウド脅威レポートでも解説)の概要が含まれます。また、演習自体がSolarWindsサプライチェーン攻撃の一部をモデルとしたものです。こうした情報を提供することで、いかにしてパイプラインが標的となり、機密情報が盗まれ、環境の侵害に発展する状況が生じるかについての展望を、読者やクラウドベースのCI/CDパイプラインのアーキテクトに提供できれば幸いです。攻撃について説明したら、最後のセクションでCI/CDパイプラインへの攻撃の被害を軽減する方法について助言を行います。
CI/CDパイプラインの侵害
レッドチーム演習において、リサーチャーはSaaSプロバイダのCI/CDパイプラインを侵害できることを実証しました。ですが、これは具体的に何を意味するのでしょうか。ベンダのサプライチェーン、あるいはそのCI/CDパイプラインが侵害された時、裏側では何が起こっているのでしょうか。この疑問に答えるため、まずはCI/CDパイプラインによる開発チャネルが業界標準とみなされている理由を解説します。
SaaSベンダはCI/CDパイプラインを使用することで、サービスやアプリケーションを迅速に開発する能力を実現しています。CI/CDパイプラインのおかげで、ベンダは最先端のプラットフォームを短時間で刷新・構築できるだけでなく、万が一脆弱性や設定ミスが発見された場合に、アプリケーションのコンポーネントの修正やパッチ適用を短時間で実施できるのです。また、他のモジュラーコンポーネントと連携して機能する、小型でモジュール化の度合いが高いコンポーネントを構築し、より大規模で堅牢なアプリケーションエコシステムを形成することも可能です。さらに、ベンダのエンジニアチームがモジュール方式を採用し、CI/CDパイプラインワークフローを利用すると、モノリシックなアプリケーション全体を再ビルドする必要がなくなり、アプリケーションの単一コンポーネントに対するビルド、更新、パッチ適用を短時間で行えるようになります。
顧客がアプリケーションを自社のニーズに合わせて扱えるように、ベンダ企業はしばしば製品/アプリケーションをコンテナ化されたエンティティのセットとして提供します。各コンテナは大規模なアプリケーションを構成する単一のコンポーネントを保持しており、コンテナを組み合わせることでアプリケーション機能のエコシステムを生み出すのです。また、アプリケーションがサポートするインフラについても、ベンダによるコンテナ化が一般的です。例としては、ネットワーク メッシュ インフラの構成やユーザー、ロール、ポリシーのIAM構成などで、時にはUIオプションもコンテナ化されます。こうしたコンテナ化された個別のアプリケーションプラグインは、パッケージ化されてから外部リポジトリにアップロードされます。顧客は必要なアプリケーション本体と関連プラグインをこのリポジトリからダウンロードして、自分のクラウド環境でカスタマイズ可能なアプリケーションを構築できます。
ここで、悪意ある攻撃者が登場します。攻撃者の中には、ベンダのCI/CDパイプラインを侵害し、アプリケーションのコンテナ化されたエコシステムの中に悪意あるコードを挿入するという明確な目標の下で、計画的にSaaSベンダを狙う者も存在します。図1は、SaaSベンダのCI/CDパイプラインの侵害に使用される可能性がある8段階の活動を示したものです。攻撃者の最終目標はベンダのクラウド環境に足掛かりを築いた上で、ベンダの環境を利用して悪意あるコードを挿入したアプリケーションやプラグインを下流の組織に配信することにあります。こうなると、SolarWinds攻撃の影響が広範囲に及んだように、セキュリティ侵害を受ける環境の数は劇的に増加します。
ステップ1 – 偵察
まず、攻撃者は組織の活動状況を確認する必要があります。確認後、組織の従業員と顧客に関係する既知のIaC (コードとしてのインフラストラクチャ)リポジトリをすべてスキャンします。良く使われるIaCリポジトリとしては、GitLab/GitHub、ArtifactHub、Docker Hub、Quay、Google Container Registry (GCR)、Amazon Elastic Container Registry (ECR)があります。こうしたサービスの外部/内部レジストリには、攻撃活動に利用できる情報が含まれることがあります。Unit 42のリサーチャーが実施したレッドチーム演習では、ハードコードされたAWS IAMアクセスID 26個と、関連するキーペアまたはセッショントークンの発見に成功しています。ほとんどのキーペアは非アクティブ状態でしたが、一部のキーペアはクラウド環境へのアクセス権の取得に利用できるものでした。IAM資格情報の適切な保護は組織にとって重要な課題です。Unit 42による別の調査で、安全なIAM設定を導入していないクラウド環境の著しい増加が確認されていることも、その重要性を裏付けます。
ステップ2 – 初期アクセス
攻撃者は、ベンダのクラウドインフラへのアクセス権の取得を試みます。そしてその手段として、ベンダの既知のクラウドインフラの弱点を悪用します。あるいは、今回のレッドチーム演習で実演したように、もっと簡単な手法が使用される可能性もあります。今回の演習では、偵察フェーズで発見した、ハードコードされたIAMアクセスキーペアを使用することで、クラウド環境に造作もなくログインできました。この他にも初期アクセスには、ベンダのIaCテンプレートの設定ミスを利用する方法や、クラウドでホストされているアプリケーションやコンテナの脆弱性を利用する方法が以前から使用されています。
ステップ3 – ラテラルムーブ
攻撃者がクラウドでホストされているシステムへのアクセス権を取得すると、次に、組織のCIパイプラインを突き止めようとして、アクセスを拡大するプロセスが始まります。クラウド環境でのラテラルムーブは、従来のオンプレミスインフラでのラテラルムーブと同様ですが、コンテナエスケープ活動の存在だけが異なります。この活動で攻撃者は物理的に分離されたシステムへ水平移動するのではなく、仮想システムと、その仮想システムをホストしている物理システムの間を移動します。
コンテナエスケープの際に攻撃者はコンテナプロセスからコンテナのホストシステムへのラテラルムーブを試みます。そのため、攻撃者に追加の権限を与えてしまうと、その後の活動を許すばかりか、活動を容易にしてしまいます。コンテナエスケープは、たとえば、Kubernetes (k8s)クラスタで稼働している公開Webサーバープロセス「から」、当該k8sコンテナをホスト中のシステム「への」移動を指します。使用されるエスケープ手法は、k8sクラスタ上の設定ミスや脆弱性といった複数の要因によって変わりますが、ホストとコンテナが共有するボリューム、ライブラリ、名前空間を利用する場合や、コンテナに付与された過剰な権限の利用を伴う場合があります。さらに、コンテナそのものがIAMキーペアをホストしている場合、クラウドシステムをホストしているクラウドプラットフォームへの直接ログインを攻撃者に許してしまう可能性があります。コンテナエスケープ、IAMキーペアの探索、同じホストマシンの他のコンテナへの接続のいずかの手段によって、攻撃者はラテラルムーブと新しいクラウドインフラの探索を実現します。
このプロセスを通じて、攻撃者にCIパイプラインの所在を突き止められる可能性があります。
ステップ4 - CIパイプラインを標的とする
攻撃者が組織のCIパイプラインの所在を突き止めたら、次は、CIパイプラインの管理サービスへのアクセス権を取得する必要があります。ステップ3のラテラルムーブと同様、次のいずれかのアプローチが必要です。
- CI管理サービスの脆弱性または設定ミスを悪用する。
- 前段の活動(ステップ1～3)で侵害または窃盗によって取得した資格情報を使用して、CIプラットフォームへのアクセス権を持つ正規ユーザーになりすます能力。
ステップ5 - CIパイプラインのポイズニング
攻撃者がCIパイプラインへのアクセス権を取得したことで、さまざまな方法でCIパイプラインを攻撃できるようになりました。代表例がSaaSアプリケーションのコンポーネントの「ポイズニング」です。ポイズニングしたコンポーネントを使用して、アプリケーションのコンポーネントにバックドア機能を組み込むなどの悪意ある活動を行うことで、攻撃者は下流の顧客環境に侵入できるようになります。SolarWinds攻撃の事例では、Orionアプリケーション用のネットワーキング プラグイン モジュールに有害なバックドアが組み込まれていました。ネットワーク接続機能をアプリケーションのコンポーネントに組み込むことで、攻撃者は悪意あるコードをベンダの公式アプリケーションパッケージに紛れ込ませることに成功したのです。さらにこの攻撃では、悪意あるパッケージに正規の電子署名を行うことにも成功したため、有害なコンテンツがさらに厳重に隠ぺいされることになりました。その後、ベンダの顧客基盤がポイズニングされたパッケージを利用できる状態になれば、攻撃者は待つだけです。
ステップ6 - クライアントがポイズニングされたパッケージをダウンロード
ポイズニングされたパッケージをクライアントがダウンロードします。顧客はこのパッケージを正規のパッケージだと認識するでしょうから、クラウドやオンプレミスのインフラにパッケージを組み込んでしまい、攻撃目標への不正アクセスを許すことになります。
ステップ7 - C2インフラへの有害なビーコン
ポイズニングされたパッケージがインストールされると、攻撃者の悪意あるコードがコマンド&コントロール(C2)インフラにビーコンを送信するとともに、顧客の侵害されたクラウドインフラ上でバックドアを開きます。
ステップ8 - 攻撃者がキーボードアクセスを取得
サプライチェーン攻撃の新たな犠牲者の存在を、ビーコンが攻撃者に通知します。攻撃者はバックドアから侵害されたクラウドインスタンスやコンテナに侵入します。ここから、攻撃者は偵察、ラテラルムーブ、権限昇格の第二ラウンドを開始しますが、ここまでの活動との違いは、顧客の侵害されたインフラの内部を対象とする点です。目標に応じて、攻撃者は好きなだけ活動を行います。具体的には、知的財産の窃盗、恐喝(ランサムウェアなどを利用)、データ破壊などです。
以上、8つのステップを通じて、IAMキーペアを安全性の低い方法で保管する等の一見ささいなミスを糸口として、多数の組織のクラウドインフラに広範な被害をもたらす攻撃が起こりうることを説明しました。
SolarWinds – ビルド環境のセキュリティ対策の失敗
Unit 42のリサーチャーはレッドチーム演習を立案する際に、SolarWinds Orionのセキュリティ侵害を手本としました。この攻撃を成功に導いた要因を学び、リサーチャーが演習を実施する上での知見を得てから、SaaSベンダのCI/CDパイプラインがどのように侵害される可能性があるかを実演したのです。最終的にこの種のセキュリティ侵害は、下流に存在する無数の組織が自社環境に有害なバックドアを意図せず受け入れてしまうことにつながります。
1社のSaaSベンダのセキュリティ侵害から始まり、最低でも18,000社が侵害された可能性がある攻撃の流れを図2に示します。この図は急激な増加パターンのモデルを図示したもので、先述の攻撃ステップに従っています。攻撃者の一連の活動を通じて、1社のSaaSベンダに対する悪意ある改ざんが、下流の組織に拡散するおそれがあることが分かります。
SolarWindsに対する攻撃も、このモデルを通して見ることができます。2020年12月13日、FireEyeはUNC2452と名付けた未知の攻撃者による侵害とデータ流出に関する情報を公開しました。Unit 42のリサーチャーはこのイベントと関連する活動を追跡し、攻撃グループをSolarStormと名付けました。そして、確認された手口、セキュリティ侵害インジケーター(IOC)、適切な行動指針をUnit 42 ATOM Viewerで公開しています。FireEyeによると、SolarStormが世界各国の組織の侵害に用いた手口はサプライチェーン攻撃であり、トロイの木馬化したSolarWinds Orion Platform用の更新ファイルが使用されていました(図3)。
SolarStormはSolarWinds Orionプロジェクト向けのサプライチェーン業務だけをターゲットとし、ITのパフォーマンスと統計情報を監視するソフトウェアに狙いを定めました。そして、デジタル署名された正規の.dllファイルである「SolarWinds.Orion.Core.BusinessLayer.dll」を改ざんしたのです。この.dllファイルは、SolarWindsのプロセス「SolarWinds.BusinessLayerHost(x64).exe」に開かれるSolarWinds Orionプラグインとして動作するファイルです。その後、デジタル署名された.dllファイルが、SolarWinds Orion用の正規ホットフィックス#5のパッケージに追加されます(CORE-2019.4.5220.20574-SolarWinds-Core-v2019.4.5220-Hotfix5.msp)。要するに、組み込まれた「正規の」.dllファイルが、ソフトウェアサプライチェーンをトロイの木馬化する手段になったのです。サプライチェーンの感染がSolarWindの顧客に広がると、感染した環境にバックドアからアクセスできるようになります。ホットフィックスが最初にリリースされた2020年3月以降、バックドア活動はほとんど気づかれませんでした。その理由はC2トラフックが正規のOrion Improvement Programトラフィックに偽装されていたためです。
CI/CDパイプラインに対する攻撃の被害を軽減するには
各組織が今回のレッドチーム演習で行った活動に対処して被害を軽減できるように、Unit 42は以下の手順を推奨します。
開発者のアクセス権の制限: 開発者のアクセス権をCIリポジトリの内部から、CIリポジトリでの作業で開発者が直接使用するリポジトリだけに制限します。
- 開発者アカウントのアクセス権を、各人の業務に必要なリポジトリだけに制限することで、機密データ漏えい対策が容易になります。アクセスを制限していれば、IAMキーペアの設定ミスをレッドチーム担当者に発見されなかったかもしれません。
コンテナとIaCテンプレートのスキャン: 開発サイクル全体でコンテナとIaCテンプレートをスキャンして設定ミスと脆弱性の有無をチェックします。
- Prisma CloudのBridgeCrewやオープンソースのCheckovなどのツールでコンテナとIaCテンプレートを漏れなくスキャンして、設定ミスと脆弱性を発見することで、セキュアなクラウドインフラの構築を支援できます。また、悪意ある攻撃者が自社環境に足場を築くことを阻止する上でも効果的です。
ドリフト検出の導入: すべてのIaCとコンテナイメージを対象としたドリフト検出を導入します。
- ドリフト検出とは、時間の経過に伴うコンテナやIaCテンプレートの改変をセキュリティチームに警告するプロセスです。Prisma Cloudの場合、BridgeCrewのスキャン機能にドリフト機能が追加されています。
CI/CDインフラを監視して挙動の変化を検出: 開発者とネットワークトラフィックのパターンから、CI/CDインフラを監視して挙動の変化を検出します。
- レッドチーム演習では、Amazon GuardDutyとPrisma Cloudが設定された1件のアカウントのおかげで、SaaSベンダのSOCがリサーチャーの活動の一部を突き止めることに成功しました。しかしながら、全アカウントで保護を有効化する以外にも、リサーチャーの活動の捕捉に使用できる検出メカニズムは他にも複数あったはずです。たとえば、Prisma Cloudの異常検出機能を使用していれば、ネットワーク上の偵察活動や異常なユーザーアクティビティに関するアラートをセキュリティチームが受け取れていたでしょう。
レッドチーム演習で明らかになった知見と、クラウドインフラを保護する方法の詳細は、「Unit 42クラウド脅威レポート2021年2H」をご覧ください。
