SUSEはRancherにおける深刻な権限昇格の脆弱性を修正しました。この脆弱性を悪用すると、権限の低い認証済みユーザーであっても、Rancherの管理プレーンとその配下にあるすべてのKubernetesクラスターに対して管理者権限を奪取できる可能性がありました。
この問題はCVE-2026-44945として追跡されており、GitHubアドバイザリのGHSA-v584-7w32-jwpqでも報告されています。CVSS v3.1のスコアは9.1で、CWE-441(意図しないプロキシ、いわゆるconfused deputy問題)に分類されます。
脆弱性の原因はRancherのなりすまし(impersonation)処理を担うミドルウェア、具体的にはpkg/auth/requests/impersonate.goにあります。RancherはKubernetes APIのなりすまし機能をサポートしており、Impersonate-User、Impersonate-Group、Impersonate-Extra-*といったヘッダーを処理する仕組みになっています。
ところが、脆弱性のある実装では、あるKubernetesクラスターで認可チェックを行いながら、最終的には別のクラスター、すなわちRancherのローカル管理クラスターにリクエストを送信していました。
これにより、クラスターをまたいだ認可の不整合が生じます。リクエストを受け取ると、RancherはURLからクラスター識別子を解析し、指定されたその下流クラスターに対してKubernetesのSubjectAccessReview(SAR)を実行していました。
その後、リクエストはRancherの管理APIによって処理されます。この管理APIは、特権を持つscaledContextサービスアカウントを使ってローカルのRancherクラスターに対して操作を行います。そしてNormanプロキシストアが、なりすましヘッダーをそのローカルKubernetes APIへと転送していました。
この仕組みにより、攻撃者は自らRBAC権限を持つ下流クラスターを選んで認可判定をコントロールしつつ、実際の操作対象としてはるかに機密性の高いローカルのRancher管理クラスターを狙うことが可能でした。
具体的には、攻撃者が自身の管理下にある下流クラスターを用意し、system:mastersのような特権アイデンティティへのなりすましを承認させることができます。Rancherの管理プレーンAPIは、ローカルでリクエストを処理する際に、このなりすましコンテキストをそのまま受け入れてしまいます。
この攻撃には、本番クラスターへの既存のアクセス権も、Rancher管理者ロールも、ユーザーの操作も必要ありません。悪用に必要なのは、認証済みのRancherセッションと、登録済みの下流クラスターのうち少なくとも1つに対するRBAC権限のコントロールだけです。
Rancherのデフォルトのグローバルロールであるuserを割り当てられたユーザーは、一般的にクラスターをインポートできるため、攻撃者は使い捨てのk3d、kind、minikube環境を登録し、これを権限昇格のための「認可オラクル」として利用できてしまいます。
この脆弱性を悪用されると、Rancherの中でも特に機密性の高いコントロールプレーン資産が危険にさらされます。攻撃者がローカルクラスターの管理者権限を得た場合、下流のkubeconfig、認証プロバイダーの資格情報、LDAPバインドパスワード、OIDCクライアントシークレット、SAML署名鍵などを保持するシークレットを読み取れてしまう可能性があります。
さらに攻撃者はGlobalRoleBindingsを作成・改変して永続的な管理者アクセスを確立し、Rancherの一元管理機能を悪用して、登録済みの下流クラスターすべてを侵害することも可能です。SUSEによれば、この脆弱性はコントロールプレーン、管理下のクラスター、保存されているシークレットの乗っ取りを可能にするとしています。
今回のパッチでは認可の境界が変更され、SARベースのなりすましチェックは、リクエストURLから選択されたクライアントではなく、ローカルのRancher管理クラスター用に固定されたクライアントを使って評価されるようになりました。
また、SARミドルウェアは、提供されたなりすましヘッダーをそのまま信頼するのではなく、リクエストコンテキストから認証済みのアイデンティティを取得するように変更されています。SUSEのセキュリティアドバイザリに記載されている通り、組織はRancher 2.14.4、2.13.8、2.12.12、または2.11.16へ直ちにアップグレードすべきです。
すぐにパッチを適用できないチームは、クラスターのインポート権限を制限し、GlobalRoleBindingの変更を確認し、特権API操作の監査を行い、漏えいの可能性がある認証情報をローテーションし、Rancher管理プレーンへの不審なアクセスがあれば警戒すべきです。
ANY.RUNのブラウザ内データ検査で、検知・調査・対応をより迅速に。フィッシングの可視性を完全に確保し、SOCを強化してMTTRを削減しましょう
翻訳元: https://cyberpress.org/critical-rancher-flaw-managed-kubernetes-clusters/
