再び脆弱性が判明：Kubernetes のログクエリーにおけるコマンドインジェクション

編集・協力：Tricia Howard

Kubernetes とコンテナは全般的に見て、セキュリティの世界では特に注目を浴びており、（当社を含む）世界中の研究者が関心を寄せる研究材料となっています。調査において、まずたどり着いたのが、CVE-2023-3676 です。これは、悪意のある YAML ファイルをクラスターに適用することで悪用される可能性のあるコマンドインジェクションの脆弱性です。この調査により、Kubernetes のソースコードには、他にもクラスターの完全な乗っ取りを成立させるいくつかの問題があることが明らかになりました。

私たちが発見した脆弱性はこれだけではありません。サイドカープロジェクトの git-sync の調査結果も注目すべきものでした。私たちは DEF CON 32 の Red Team Village でこれらの調査結果を発表しましたが、この発表の準備中に偶然見つけたのが、今回のブログ投稿のトピックです。それは、ログクエリーという、より大規模なロギングフレームワークを実現する Kubernetes のベータ版機能が、コマンドインジェクションのもう 1 つの機会になるというものです。

ログクエリーでは、CLI または curl を使用して、リモートマシンのシステムステータスの照会が可能になります。たとえば、次のコマンドを入力すると、リモートノードの kubelet サービスのステータスを照会できます。

上記のコマンドを見たとき、以前の調査を思い出しました。そして浮かんだのが、「リモートマシンに送信されたクエリーは検証されるのだろうか」という疑問です。

図 1 はログクエリーのソースコードの例で、ここには複数の PowerShell コマンドが組み込まれています。

コマンドインジェクションのさまざまな手法を試した結果、最終的にはペイロード自体には問題がないことがわかりました。この脆弱性を悪用するには、通常の klog フレームワークではなく、ETW にネイティブにステータスをロギングするサービスを指定する必要がありました。脆弱性チェックがあるのは Windows のイベントトレース（ETW）へのロギング時のみであるからです。

Calico（Kubernetes の一般的なオープンソースのネットワークインタフェース）を使用した Kubernetes 環境では、Non-sucking Service Manager（NSSM）を通じてこの脆弱性を確実に悪用することができます。

• Calico 設定では、通常、Kubernetes のサービスの状態を制御するために NSSM を使用します。他の環境や設定では、サービスの状態を処理するために異なる方法を使用します。

• Kubernetes は NSSM のロギング出力を管理することなく、ログが klog を通さずに直接 ETW に書き込まれるようにします。

これで、脆弱かどうかを簡単に判断できます。「os=windows」の部分に注目してください。Windows ノードがない場合、コマンドを実行しても何も出力されません。つまり、脆弱性はないということです。

これはベータ版機能であるため、クラスター自体もこのフレームワークを使用するように設定されている必要があります。

この機能が有効になっているかどうかは、管理者が「feature-gate」スタートアップパラメーターで「kubelet」を探せば確認できます。 詳細は、Kubernetes のサイトで確認してください。

この脆弱性を修正するために、Kubernetes は、PowerShell コマンド自体に値を渡す前に「kubelet_pattern」という名前の環境変数を使用することにしました。

こうすることで、ユーザー入力は、評価が必要な式の一部ではなくリテラル文字列であるとみなされます。

この脆弱性を緩和するために、管理者はロールベース・アクセス・コントロール（RBAC）モジュールを使用して、ログクエリーへのアクセス権を持つユーザーを制御したり、ログクエリーへのアクセスを完全に無効にしたりすることができます。RBAC は、ユーザーの操作をユーザーが誰であるかに応じてセグメント化する方法です。たとえば、各ユーザーは独自の名前空間に Pod を作成することだけ、または許可された名前空間の情報を閲覧することだけができます。これにより、RCE が実行されるリスクだけでなく、検出のリスクも軽減されます。多くの場合、ユーザーの異常なふるまいは被害の発生を示しています。 

この脆弱性は Windows ノードにのみ影響することに留意してください。Kubernetes クラスターに Windows ノードがない場合は、この脆弱性の影響はありません。ただし、できるだけ最新のパッチを適用し、他の未知の脆弱性を回避できるようにしておくことが推奨されます。 

この問題はソースコード内に潜んでいるため、この脅威に曝される危険性は依然としてあり、悪用される可能性が高まりそうです。したがって、Windows ノードがまったくないとしても、クラスターにパッチを適用することを強くお勧めします。

このブログの投稿では、クエリーの権限を持つ攻撃者がクラスター内の任意の Windows ノードでコマンドを実行する方法について説明しました。この脆弱性は、YAML ファイルの送信を必要とせず、簡単な curl コマンドによって悪用される可能性があります。このような悪用は緩和や検知が難しいため、大きなリスクが発生します。以前にも議論したように、Kubernetes のサニタイズの問題はログクエリーに限ったことではありません。

ブルーチームのメンバーは、組織内で発生する異常なふるまいに注意を払う必要があります。これらの攻撃ベクトルは、クラスターの完全な乗っ取りにつながる可能性があります。そのため、意識を向上させ、セキュリティ管理者が潜在的な危険を把握できるよう支援することが重要です。

Akamai Security Intelligence Group は、このような脅威を継続的に調査し、お客様やセキュリティコミュニティ全体に報告します。私たちの現在の取り組みに関するリアルタイムの最新情報については、X（旧 Twitter）でフォローをお願いいたします。

Kubernetes チームの対応と開示に感謝します。