ビジネスシナリオに基づくコンテナ脱出技術

導入

近年、コンテナは、あらゆる環境で実行できること、オーバーヘッドが低いこと、数秒で起動できること、イメージ使用量が少ないことなどの利点から、世界中のさまざまな業界で人気が高まっています。たとえば、Gmail から YouTube、Google 検索まで、Google のほぼすべての製品はコンテナ内で実行されており、毎週 20 億を超えるコンテナが起動されています。 JD.com は世界最大のコンテナ クラスターを構築しており、内部コンポーネントの 99% がコンテナ化されており、現在、コンテナ クラスターのサイズは 200,000 に達し、JD.com の 618 および Double 11 プロモーションを確実に実現しています。

しかし、コンテナの初期の開発では、セキュリティが十分に考慮されずに、使いやすさや機能実装が主に考慮され、あらゆる面でセキュリティ上のリスクがありました。コンテナ化の重要性が高まるにつれて、コンテナのセキュリティの重要性も高まります。まだ開発段階にある新しい技術であるため、コンテナのセキュリティは絶えず向上していますが、同時に常に課題にも直面しています。直面するすべてのセキュリティ問題の中で、エスケープ問題が最も重要であり、コンテナをホストする基盤となるインフラストラクチャの機密性、整合性、可用性に直接影響を及ぼし、基盤となるホスト マシンとクラウド コンピューティング システム全体のセキュリティを危険にさらします。この記事では、コンテナ脱出技術について包括的に説明します。

1.コンテナのセキュリティリスク

コンテナ時代において、セキュリティは新しい脅威と古い脅威という二重の課題に直面しています。一方で、脆弱性の挿入、ブルートフォースクラッキング、権限昇格などの従来の攻撃方法は依然として有効です。一方で、コンテナエスケープ、ポイズニングイメージ、クラスタ管理の脆弱性など、新たな攻撃手法が次々と登場し、防御が困難になっています。

1.1軽量仮想化技術としてのコンテナが直面する主なセキュリティリスク

図 1 仮想マシンとコンテナ

図からわかるように:

• コンテナにはハイパーバイザーがないため、そのセキュリティはホスト OS カーネルに大きく依存しており、カーネルの脆弱性の影響を受ける可能性があります。
  
  
• コンテナ技術は、OS レベルでコンピュータ システムの仮想化を実現します。オペレーティング システムでは、CPU、メモリ、ファイル システムなどのリソースを分離、分割、制御するために名前空間テクノロジが使用され、プロセス間の透過的なリソース使用が実現されます。そのセキュリティは、カーネル分離テクノロジの成熟度に大きく関係しています。
  
  
• 仮想マシンからホストや他の仮想マシンに侵入するには、まずハイパーバイザー層に侵入する必要がありますが、これは非常に困難です。 Docker コンテナはカーネル、ファイル システム、その他のリソースをホスト マシンと共有するため、他のコンテナやホスト マシンに影響を与える可能性が高くなります。コンテナでは分離レベルが少なく、攻撃パスが短く、攻撃対象領域が広いため、システム全体のセキュリティが危険にさらされます。

1.2コンテナライフサイクルの観点から見たコンテナの主なセキュリティリスク

図2 Dockerコンテナの典型的な使用プロセス

Dockerはコンテナエンジンの代表です。コンテナの使用プロセスから、コンテナのセキュリティリスクは、コンテナの構築、展開、運用のライフサイクル全体にわたって発生することがわかります。たとえば、ビルドフェーズでは、ベースイメージの汚染、CI ツール攻撃、アーティファクト ライブラリの脆弱性攻撃などのソフトウェア サプライ チェーン攻撃が発生する可能性があります。デプロイメント フェーズでは、オープン ソース コンポーネント オーケストレーション ツール、セキュリティ コンプライアンス チェックなど、クラウド ネイティブ インフラストラクチャ プラットフォームに対する攻撃に直面する可能性もあります。ランタイム フェーズでは、クラウド ネイティブ アプリケーションが、エスケープ攻撃、セキュリティ分離、インジェクション脆弱性、弱いパスワードなどの攻撃に直面する可能性もあります。

コンテナのライフサイクルは短く、急速に変化します。コンテナの 50% 以上は、起動から削除までのライフサイクル全体が 1 日以内です。コンテナ侵入インシデントを迅速に検出して対応し、損失を最小限に抑えることが、セキュリティ上の大きな課題となっています。

1.3コンテナのセキュリティ脆弱性は長年にわたり、コンテナからの脱出が最も大きな割合を占め、最も大きな影響を及ぼしていることが示されています。

コンテナ クラスターでは、コンテナが侵害された場合、他のコンテナに水平に移動するか、永続性のためにノードに逃げてノード全体を制御できます。次に、攻撃者は脆弱性を悪用したり、API SERVER を呼び出したりすることで、クラスター全体を制御することもできます。コンテナは攻撃価値が高く、攻撃者にとって格好の標的となっています。

下図の長年にわたるコンテナ セキュリティ問題の分布とコンテナ ランタイム侵入イベントの統計分布から、コンテナ エスケープはユーザーが最も懸念しているセキュリティ問題であり、ビジネス シナリオで遭遇する最も一般的なセキュリティ問題でもあることがわかります。

図3 コンテナセキュリティ問題の分布

図4 2021年のコンテナランタイム侵入インシデントの統計分布

2.コンテナ脱出技術と原理

コンテナ エスケープとは、不正なコンテナが通常の分離環境の制限を突破し、何らかの手段を使用して、コンテナが配置されている直接のホスト マシン、ホスト マシン上の他のコンテナ、またはクラスター内の他のホストやコンテナの特定の権限でコマンド実行機能を取得し、悪意のある攻撃を実行したり、不正アクセスを実行したりしようとすることを指します。下の図に示すように、コンテナ エスケープ脆弱性はコンテナ ノードまたはクラスタ全体に侵入する可能性があります。

図5: 攻撃者の視点から見たコンテナ脱出攻撃経路

コンテナ エスケープの前提は、コンテナ内で特定の権限でコマンドを実行する能力を獲得し、分離を突破することです。コンテナ分離技術は新しい発明ではありません。これは、Linux リソース分離のコア技術である名前空間を利用して実装されます。

図6 アプリケーション層コンテナエスケープ原理の分析

図 6 に示すように、Linux カーネルは本質的に単独では不十分です。名前空間は現在、PID、マウント、ネットワーク、UTS、IPC、ユーザーなどの多くのリソース分離タイプを提供していますが、システムのいくつかの主要なディレクトリ（/sys、/proc など）を含む、名前空間以外のカーネル リソースは分離されていないか、分離が不十分です。これらのキー ディレクトリによってホスト上の重要な情報が漏洩する可能性があり、攻撃者がこの情報を使用してホストを攻撃し、コンテナーをホストに逃がす可能性があります。

特権モードは Docker バージョン 6.0 で導入されました。その主な機能は、コンテナ内のルートにホスト マシンのルート権限を与えることです。コンテナを特権モード（docker run --privileged）で起動すると、Docker コンテナはホスト上のすべてのデバイスにアクセスし、多数のデバイス ファイルへのアクセス権を取得し、マウント コマンドを実行してマウントできるようになります。 Docker 管理者が mount コマンドを使用してホスト ディスク デバイスをコンテナーにマウントできる場合、ホスト ファイル全体の読み取りおよび書き込み権限を取得できます。また、スケジュールされたタスクを書き込むことでホスト上でコマンドを実行し、正常に脱出することもできます。

Linux カーネルはバージョン 2.2 以降、従来の root ユーザーの権限を 30 を超える異なる単位に分割して管理を洗練させる Capabilities メカニズムを導入しました。ただし、機能が正しく設定されていない場合、攻撃者が権限を昇格できる可能性があります。たとえば、コンテナが --cap-add=SYSADMIN で起動されると、コンテナ プロセスは mount や umount などの一連のシステム管理コマンドを実行できるようになります。このとき、攻撃者がコンテナ内に外部デバイスディレクトリをマウントすると、Docker エスケープが発生します。機能の不適切な制御もコンテナのエスケープにつながる可能性があることがわかります。現在、業界では、SYSADMIN、DAC_READ_SEARCH、SYS_MODULE、および SYS_PTRACE がエスケープ脆弱性をもたらすものとして特定されています。

3.ビジネスベースのコンテナ脱出シナリオの分析

業界における多数のコンテナ セキュリティ CVE 脆弱性の調査に基づいて、製品ビジネス シナリオでの運用におけるコンテナ セキュリティの弱点が分類され、コンテナ エスケープは主にアプリケーション層、サービス層、システム層に分散していることが判明しました。

図7 製品ビジネスシナリオで特定されたコンテナエスケープの問題

アプリケーション層でのエスケープは、特権モードを悪用してエスケープしたり、Capability を利用してエスケープしたりするなど、主に特権モードと不適切な構成に反映されます。コンテナとホスト間のデータ交換を容易にするために、ほとんどすべての主流のソリューションは、ホスト ディレクトリをコンテナにマウントする機能を提供しています。その結果、コンテナからの逃走問題が増加しています。コンテナが、docker.sock やホストの procfs などの機密ファイルやディレクトリをホスト上に読み取り/書き込み形式でマウントすると、コンテナから簡単に脱出でき、脱出する方法も多数あります。

アプリケーション自体の脆弱性によってもたらされる攻撃に加えて、サービス層クラスターやコンテナ ランタイム自体の脆弱性も無視できません。たとえば、攻撃者は k8s のポート 8080 と 6443 への不正アクセスを利用して、コンテナ経由で K8S マスター API にアクセスし、悪意のある呼び出しを行う可能性があります。 runc や Containerd コンポーネントの脆弱性など、コンテナ エコシステムに含まれるサーバー プログラムとクライアント プログラムの脆弱性も、コンテナによって悪用され、ホスト マシンの制御権を握られる可能性があります。

また、システムレベルの観点から見ると、Docker はホストカーネルを直接共有するため、ホストカーネルにセキュリティ上の脆弱性がある場合、Docker のセキュリティにも影響が及び、Docker が逃げてしまう可能性があります。たとえば、有名な Dirty COW の脆弱性 CVE-2016-5195 は、Linux カーネルの権限昇格の脆弱性であり、これを利用すると Docker コンテナから脱出し、ルート権限を持つシェルを取得できます。

4.コンテナ脱出の解決策

4.1 Docker独自のセキュリティ改善

コンテナ開発の初期には、コンテナ内のルートはホストマシン上のルートと同等でした。コンテナが侵害されたり、コンテナ自体に悪意のあるプログラムがあったりすると、コンテナ内でホストマシンのルート権限が取得される可能性があります。 Docker バージョン 1.10 では、ユーザー分離のためのユーザー名前空間テクノロジが導入されました。これにより、コンテナ内の root ユーザーをホスト上の非 root ユーザーにマッピングできるため、コンテナ エスケープが発生するリスクが大幅に軽減されます。コンテナ コミュニティは、多層防御や最小権限などの概念と原則を実装するために懸命に取り組み続けているため、可能な限り最新バージョンの Docker を使用することをお勧めします。また、最新バージョンの Docker を使用すると、既知の CVE 脆弱性が修正されます。たとえば、Docker バージョンを 19.03.1 以降に更新すると、CVE-2019-14271 や CVE-2019-5736 などの脆弱性の影響を受けなくなります。

4.2 セキュリティ構成とマウント

アプリケーション層におけるコンテナ関連の脆弱性のほとんどは、安全でない構成またはマウントによって発生します。きめ細かい権限制御であろうと、その他のセキュリティ メカニズムであろうと、ユーザーはコンテナー環境の設定を変更したり、コンテナーの実行時にパラメーターを指定したりすることで、それらを調整できます。 Docker コンテナまたは k8s ポッドを起動するときは、次の操作を実行することをお勧めします。

• Docker サービスをルート権限で実行しないでください。
• ホスト上の機密ディレクトリをコンテナ ディレクトリにマウントしないでください。
• 特権モードを有効にしないでください。対応する権限を追加する必要がある場合は、-cap-add パラメータを使用できます。
• -cap-add=SYSADMIN、-cap-add=DAC_READ_SEARCH、-cap-add=SYS_MODULE、-cap-add=SYS_PTRACE などの高い権限でコンテナを起動しないでください。たとえば、攻撃者はコンテナの CAP_DAC_READ_SEARCH 権限と有名な Shocker 攻撃手法を使用してコンテナから脱出し、ホストの /etc/shadow ファイルを読み取ることができます。

4.3 カーネルのセキュリティと管理の強化

CVE-2016-5195 (Dirty Cow) を解決するには Linux カーネル バージョン >= 2.6.22、CVE-2017–1000405 (Big Dirty Cow) を解決するには Linux カーネル バージョン >= 4.14 など、最新のパッチが適用されたホスト カーネル バージョンをインストールしてください。

4.4 セキュリティ強化コンポーネントの使用

Linux の SELinux、AppArmor、GRSecurity コンポーネントはすべて、Docker によって公式に推奨されているセキュリティ強化コンポーネントです。これら 3 つのコンポーネントは、ホストのカーネルまたはその他のリソースに対するコンテナのアクセス制御権限を制限できます。これらのセキュリティ強化コンポーネントについては、以下で説明します。

• SELinux: 安全なアクセスのためのポリシー メカニズムを提供する Linux のカーネル セキュリティ モジュールです。 SELinux ポリシーを設定することで、特定のプロセスが特定のファイルにアクセスできるようにするために厳密なチェックまたは緩いチェックを実行する方法を指定できます。
• AppArmor: SELinux と同様に、Linux カーネル セキュリティ モジュールです。通常のアクセス制御ではユーザーのアクセス権しか制御できませんが、AppArmor ではユーザー プログラムのアクセス権を制御できるほか、0day 脆弱性や未知のアプリケーションの脆弱性による攻撃も識別できます。
• GRSecurity: インテリジェントなアクセス制御によるメモリ破損防御やファイル システム強化などの複数の防御形式を提供するカーネルのセキュリティ拡張機能です。ユーザーがこれらのセキュリティ機能を構成および使用するためのツールを提供します。

4.5 安全なコンテナの使用

コンテナには軽量で起動が速いという利点があり、仮想マシンには安全な分離という利点があります。セキュア コンテナーは両方の利点を考慮できるため、軽量かつ安全です。

セキュア コンテナと通常のコンテナの主な違いは、セキュア コンテナ内の各コンテナが個別のマイクロ仮想マシンで実行され、独立したオペレーティング システムとカーネルを持ち、仮想マシンと同じセキュリティ分離を備えていることです。

安全なコンテナに現在推奨されている主流の技術ソリューションは Kata Containers です。これには完全なオペレーティング システムは含まれておらず、コンテナ独自のアプリケーションを実行するゲスト カーネルの簡素化されたバージョンのみが含まれています。共有メモリを使用することで、メモリのオーバーヘッドをさらに削減できます。さらに、OCI 仕様も実装しており、Docker イメージを直接使用して Kata コンテナを起動できるため、オーバーヘッドの低減、数秒での起動、安全な分離など、多くの利点があります。

図8 一般的なコンテナとセキュアコンテナの比較

5.追記

前述のように、コンテナはハッカーの主要なターゲットとなっており、アプリケーション層におけるコンテナエスケープ脆弱性が最も大きな割合を占めています。アプリケーション層でのコンテナのセキュリティは、その構成のセキュリティに大きく依存します。ビジネス シナリオでは、機能を付与することが特に重要です。権限を最小限に抑え、使用されていない特権を破棄する必要があります。能力の助けを借りて脱出することは氷山の一角に過ぎず、さらなる研究が必要な脱出シナリオがまだたくさんあります。一部の機能は今のところ悪用されていませんが、将来的に攻撃者の逃げ道にならないという保証はありません。したがって、ビジネス運営を維持するために必要な最小限の権限を使用することが不可欠です。

権限が強すぎると怠慢につながる可能性があります。権限を最小限に抑える一方で、業界のベスト プラクティスも参照する必要があります。つまり、ユーザー分離のためにユーザー名前空間を有効にし、非ルートとして実行します。これは、プリコンパイルされたステートメントを使用して SQL インジェクションを防御し、根本から防御してすべての攻撃パスを遮断するようなものです。このソリューションは既存のビジネス展開計画に多くの変更を加える可能性がありますが、それでもコンテナ防御の最終的な目標の 1 つとなるはずです。

現在、Docker の分離は仮想マシンのレベルには程遠いです。 Docker コンテナを仮想マシンとして使用することは避けてください。仮想マシンにコンテナをデプロイしない限り、信頼できるアプリケーションのみを Docker コンテナで実行することをお勧めします。