Kubernetes の RCE 脆弱性 CVE-2023-5528 が FIX:Windows ノードの乗っ取りにいたる?

Patch Now: Kubernetes RCE Flaw Allows Full Takeover of Windows Nodes

2024/03/14 DarkReading — 広く使用されている Kubernetes コンテナ管理システムの脆弱性により、Windows エンドポイント上の System 権限で、リモートの攻撃者からのコード実行が可能となり、Kubernetes クラスター内の全ての Windows ノードが、完全に乗っ取られる危険性が生じている。この不具合は Akamai のセキュリティ研究者 Tomer Peled が発見したものであり、CVE-2023-5528 (CVSS:7.2) として追跡されている。この脆弱性の悪用方法は、クラスタ上のポッド間でのデータ共有をサポートする Kubernetes ボリュームの操作と、ポッド・ライフサイクル外でのデータの永続的な保存にあると、3月13日に公開したブログで Tomer Peled は説明している。

GitHub のリストによると、攻撃者は前提として、Windowsノード上にポッドと永続ボリュームを作成する必要があるという。

Akamai の Tomer Peled は、「攻撃者はパラメーターを変更し、3つの YAML ファイルを適用するだけで、Windows エンドポイント上で RCE を達成できる。つまり、この脆弱性を悪用は極めて容易である。Kubernetesフレームワークは、基本的に全てにおいて YAML ファイルを使用している」と述べている。

Kubernetes クラスタが影響を受けるのは、Windows 用の in-tree storage プラグインを使用している場合のみだが、開発者が使用できるボリュームの種類は数多くあり、さまざまな攻撃シナリオが生まれると、彼は付け加えている。

オンプレミスのデプロイメントと Azure Kubernetes Service の両方で稼働している、バージョン 1.28.4 以前の Kubernetes デフォルト・インストールには、この脆弱性が存在している。Kubernetesチームは、この欠陥について警告を受けており、すでに修正パッチを用意している。

Tomer Peled は、「この問題はソースコード内にあるため、脅威は継続的なものとなり、悪用が増加する可能性がある。したがって、Windows ノードが存在しない場合でも、クラスターにパッチを適用することを強く推奨する」と指摘している。

欠陥の追跡から得られたものは?

この脆弱性を Peled が発見したのは、Kubernetes における安全でない関数呼び出しと、ユーザー入力サニタイズの欠如という、根本原因を共有する別の脆弱性を調査した後のことである。その脆弱性 CVE-2023-3676 は、悪意の YAML ファイルをクラスタに適用することで悪用可能となる、コマンド・インジェクションの脆弱性だった。この脆弱性の発見は、YAML ファイルの “subPath” パラメータがサニタイズされないことに起因する、他の2つの脆弱性の発見につながった。

Peled は、「その調査の最後のほうで、別のコマンド・インジェクションの脆弱性につながりそうなコードに気づいた。何度か試した結果として、”kubelet” サービス (SYSTEM 権限) としてコマンドを実行できてしまうという、同様の結果が得られた」と記している。

悪用とパッチ適用

彼が実施した PoC エクスプロイトは、Kubernetes 内のボリューム・タイプの1つである、ローカル・ボリュームに焦点を当てるものである。ローカル・ボリュームを含むポッドを作成する際に “kubelet” サービスは、最終的に “exec.command”への “cmd” ライン呼び出しで関数に到達し、ノード上のボリュームの場所とポッド内の場所の間にシンボリック・リンクを作成する。

多くのターミナルと同様に、Windows のコマンド・プロンプト (cmd) では、2つ以上のコマンドの継続的な実行や、同じコマンドラインでの複数のコマンド実行が可能である。Peled は、「cmd の実行パラメータの1つを制御できるということは、コマンド・インジェクションが使えるということだ」と説明する。

それを、ローカル・ボリュームで実現するには、persistentVolume を指定/作成する必要があるなどの、前提条件をクリアする必要がある。しかし、そのボリュームが作成されると、ユーザーは “persistentVolumeClaim” を使ってストレージ・スペースを要求できる。つまし、ここにインジェクションを仕込むことが可能となる。

この脆弱性悪用を阻止するパッチは、”cmd” コールを削除し、同じ操作でシンボリック・リンクを作成する、ネイティブの GO 関数を置き換えるものとなる。それにより、インジェクションの機会が取り除かれる。現時点において、GO ‘os’ ライブラリは、当初から意図されたように、シンボリック・リンク操作のみを実行するという。

あなたのシステムは脆弱なのか?

Kubernetes は、最も広く利用されるオープンソースのコンテナとして台頭してきたが、組織データへの不正アクセスおよび悪用の可能性が高いため、脅威アクターにとって格好の標的にもなっている。さらに、Kubernetes のコンフィグレーション自体が、脆弱なインストールを作成し、広範な攻撃対象領域を生み出すことも少なくない。

Peled は、「Kubernetes は極めて複雑で堅牢なツールである。その一方でユーザーは、組織のニーズに合わせたカスタマイズが可能となっているが、開発者とユーザーの立場から見ると、あらゆる側面をセキュアにすることが、極めて難しくなっている」と述べている。

彼は、「現実的に見て、脆弱性 CVE-2023-5528 などは、Kubernetes 自体やサイドカー・プロジェクトのコード領域で、入力サニタイズが欠けていることに起因している。つまり、Kubernetes をデプロイする企業にとって、コンフィグレーション YAML の検証が、いかに重要であるかが浮き彫りにされている」と指摘している。

RBAC (Role-Based Access Control) を取り入れや、最新のクラスタの確認といった、ベスト・プラクティスに従うことでも、既知の脅威の大部分が軽減されるはずだ。

Kubernetes を活用しているエンタープライズ環境では、そのシステムのバージョンが 1.28.4 より古く、また、Windows ノードを実行している場合に限り、この脆弱性の悪用の可能性が生じる。このケースに備えて Akamai は、システムにパッチを適用すべきかどうかを判断するためのコマンドを、管理者向けに提供している。その結果として、必要という判定が下された場合には、パッチの適用を優先する必要があるという。

Peled は、「Kubernetes クラスターに Windows ノードが存在しない場合には、この特定の脆弱性に対して、急いでパッチを当てる必要はない。しかし、時間があるときには、とにかくパッチを当てることが重要である」と付け加えている。

速やかなパッチ適用が難しい場合には、Akamai が提供している Open Policy Agent (OPA) ルールにより、この種の動作の検出とブロックを効率化できる。OPA は、オープンソースのエージェントであり、ノードを出入りするトラフィックのデータを受信し、受信したデータに対して、ポリシーベースのアクションを実行できるものである。