CVE-2020-14386による潜在的なコンテナエスケープの検出と緩和
CVE-2020-14386による潜在的なコンテナエスケープの検出と緩和

CVE-2020-14386による潜在的なコンテナエスケープの検出と緩和

本文の内容は、2020年9月16日にKaizhe Huangが投稿したブログ(https://sysdig.com/blog/detecting-and-mitigating-potential-container-escapes-via-cve-2020-14386/)を元に日本語に翻訳・再構成した内容となっております。

9月14日、CVE-2020-14386は重大度の高い脅威として報告されました。このCVEは、権限のないローカルプロセスがシステムへのrootアクセスを取得できるようにするカーネルセキュリティの脆弱性です。

CVE-2020-14386は、Linuxカーネルのパケットソケット機能で見つかったバグの結果です。これにより、悪意のある人物がメモリの破損を引き起こし、データやリソースを乗っ取り、最も深刻なケースではシステムを完全に乗っ取ることができます。この脆弱性による最大の脅威は、データの機密性と整合性です。

さまざまなLinuxディストリビューションの4.6より新しいカーネルバージョンは、このバグの影響を受けます。

  • Ubuntu Bionic(18.04)以降
  • Debian 9
  • Debian 10
  • CentOS 8 / RHEL 8

緩和

  1. オペレーティングシステムにパッチを適用します - 実行できる最も迅速なアクションは、脆弱なホストにパッチを適用するためのメンテナンスウィンドウをスケジュールすることです。
  2. CAP_NET_RAWを無効にする – メンテナンスウィンドウのスケジュールには、常に環境を公開する時間がかかります。考慮すべき簡単な手順は、デフォルトでCAP_NET_RAWを無効にすることです。ほとんどのRed Hatシステムでは、これはすでに無効になっています – https://access.redhat.com/security/cve/cve-2020-14386
  3. Kubernetes PodSecurityPolicies – ポッドセキュリティポリシーを構成して、実行中のコンテナでCAP_NET_RAW機能を削除します。ここで提案されています – https://cloud.google.com/kubernetes-engine/docs/security-bulletins

コンテナ化された環境とKubernetesの共通の性質により、プロセスのアクセス許可を昇格させ、コンテナのエスケープをトリガーする可能性があるため、この脆弱性はさらに重要になります。 CVE-2019-5736:runcコンテナのブレークアウトは、本質的に類似した「高」重大度CVEの一例です。この脆弱性は、基礎となるライブラリを上書きすることでルート権限につながり、大きな爆発半径を生み出し、全員がパッチを適用する必要があります。

FalcoによるCVE-2020-14386の検出

この脆弱性の根本的な原因は、パケットソケットが使用する関数tpacket_recvの誤ったオフセット計算です。これは、ユーザー制御の入力により、範囲外の書き込みが発生し、攻撃者がシステムを制御できる可能性があることを意味します。

この脆弱性を悪用するには、攻撃者のネームスペースでCAP_NET_RAW機能を有効にする必要があります。 rawソケットは特定のクラスのネットワーク攻撃を許容するため、システムでのソケットの使用はすべて赤旗である必要があります。

誰もが最初にすべきことはOSの脆弱性をスキャンすることですが、ランタイムの脅威検出を実装する必要があります。オープンソースのクラウドネイティブランタイムセキュリティプロジェクトであるFalcoは、予期しないアプリケーションの動作を検出し、ランタイムに脅威を警告します。 Linuxシステムコールを介してsysdigオープンソースライブラリを利用することで、高性能の本番環境で実行できます。 Falcoはまた、Kubernetes API監査イベントを取り込み、オーケストレーションアクティビティのランタイム検出とアラートを提供します。 Kubernetesアプリケーションコンテキストを追加することで、チームは誰が何をしたかを正確に理解できます。

Falcoの利点の1つは、すぐに使えるルールを常に改善し、彼らが遭遇する実際の使用例でライブラリーを充実させているアクティブなコミュニティーです。

この画像のalt属性が入力されていません

この脆弱性は、2019年にユーザーが投稿したFalcoルールを利用して、システム内のパケットソケットを開こうとする試みを検知することができます。

rule: Packet socket created in container
desc: Detect new packet socket at the device driver (OSI Layer 2) level in a container. Packet socket could be used to do ARP Spoofing by attacker.

condition: evt.type=socket and evt.arg[0]=AF_PACKET and consider_packet_socket_communication and container and not proc.name in (user_known_packet_socket_binaries)

output: Packet socket was created in a container (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline socket_info=%evt.args container_id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)

priority: NOTICE

tags: [network, mitre_discovery] 

下記のような出力になるでしょう。

18:22:38.501982124: Notice Packet socket was created in a container (user=root command=CVE-2020-14386 socket_info=domain=17(AF_PACKET) type=3 proto=768 container_id=72a39d9aa408 container_name=gallant_buck image=cve-2020-14386_container:latest)

これは、コンテナ内の悪意のある活動を検出するFalcoエンジンの強力な能力を強調しています。

Sysdig Secure で CVE-2020-14386 を検出

Sysdig Secureには、広く使われているFalcoエンジンが組み込まれており、システムレベルで不審な動作を容易に識別できるようになっています。以下は、Sysdig SecureのUIに表示されている同じルールです。正確な条件を定義することで脅威を特定する時間を短縮し、このルールに違反したコンテナのキル、停止、一時停止などの自動修復アクションを適用することができます。

この画像のalt属性が入力されていません

Sysdig Secureで脆弱なOSのバージョンを特定

脆弱性のあるシステムを特定する最も簡単な方法は、環境全体で使用されているOSのバージョンを収集し、脆弱性の可能性のあるシステムにフラグを立てることです。

Sysdig Secureを使用する場合、システム内の各ノードから収集した豊富なデータには、アンダーラインのOSバージョンも含まれており、現在どのワークロードが実行されているかなど、脆弱性のあるホストを容易に特定し、リスクの関連付け、システムのパッチ適用の優先順位付け、ホストの環境や所有者を迅速に特定することができます。

この画像のalt属性が入力されていません

Sysdig PSP Advisorを使用したPodSecurityPoliciesの設定

Kubernetesを使用している場合、活用できる強力なメカニズムがPodSecurityPoliciesです。PodSecurityPoliciesを使用すると、実行中の環境で機能を落とすことができ、この脆弱性を悪用されるのを防ぐことができます。

現実の本番環境での課題は、グローバルな設定を適用した場合の影響を評価する能力、例えば、どのワークロードが影響を受けるかを特定する能力です。セキュリティは重要ですが、本番環境のシステムをダウンさせた場合のビジネスへの影響は常に考慮する必要があります。

Sysdig Secure PSP Advisorでは、CAP_NET_RAWをドロップするPodSecurityPolicyをシミュレートすることができます。ポリシーをシミュレートすることで、影響を受けるワークロードをリアルタイムで可視化することができ、オペレータはランタイム環境の制約に応じてルールを調整して、何も壊されないようにすることができます。

この画像のalt属性が入力されていません

まとめ

誰かがカーネルやホスト内部のハードウェアリソースへの直接アクセスを許可することは、ドアの鍵を開けたまま休暇に行くようなものです。組織がより多くのミッションクリティカルなアプリケーションをコンテナやKubernetesに移行し続ける中で、悪質な行為者はコンテナの脆弱性を見つけ出して悪用することに時間を費やすようになるでしょう。

このCVEは、コンテナやKubernetesがより優れた分離とセキュリティを提供する一方で、(Falco/Sysdig Secureのようなツールを介した)ランタイム検出と(Sysdig PSP Advisorを介した)最小特権アクセス制御を実施しなければならないことを思い出させてくれます。

リンク

Palo Alto Networks の Or Cohen 氏による脆弱性開示の投稿 - https://www.openwall.com/lists/oss-security/2020/09/03/3

Google クラウドセキュリティアドバイザー - https://cloud.google.com/kubernetes-engine/docs/security-bulletins

Falco Slack - https://kubernetes.slack.com/archives/CMWH3EH32/p1600140300113300

Sysdig ポリシーアドバイザー - https://sysdig.com/blog/psp-in-production/

Sysdig Falco ポリシー - https://docs.sysdig.com/en/policies.htm

いつも素早い和訳ありがとうございます。大変興味深い内容が多くとても助かります。Linkdinだけだと勿体ないコンテンツだと思いますが、Sysdigジャパンのページに日本語ブログ開設されたりしないのでしょうか?もしくはTwitter連携投稿するだけでもだいぶ周知性が高まると思います。

To view or add a comment, sign in

Explore topics