独占 Googleが提供するKubernetesオペレーターに、攻撃者がGoogle Cloud Platform（GCP）のアイデンティティおよびアクセス保護をバイパスし、組織のクラウド環境を完全に掌握できるセキュリティホールが存在します。あるいは、バグバウンティプログラムにおけるコミュニケーションと透明性に深刻な問題を抱えているのかもしれません。
おそらく、その両方でしょう。
クラウド環境のバグ探しを得意とする研究者Justin O’Leary氏は、Kubernetesのネームスペースユーザーであれば誰でもGCPのIAM（Identity and Access Management）コントロールをバイパスし、組織のクラウドリソース管理においてrootアクセスを取得できる重大な欠陥を発見してGoogleに報告したと本紙に語りました。
Googleは当初、このバグを高優先度・高深刻度と評価し、担当者はO’Leary氏に「ナイスキャッチ！」と伝えました。しかしその後、クラウドの巨人は方針を転換。O’Leary氏とThe Registerに対して「脆弱性は存在しない」と通告し、修正も報奨金の支払いも行わないとしました。
ところが、バグレポートは今なお「高優先度・受理済み」のステータスのままです。
O’Leary氏は「ConfigConfusion」と名付けたこの脆弱性について、3月8日にGoogleへ報告してから現在に至るまでの経緯を、The Registerに独占的に語りました。また、詳細をまとめたブログ記事も公開しています。
問題の発端は、KubernetesからGoogle Cloudリソースを管理できるオープンソースのKubernetesアドオン「Config Connector」にあります。
O’Leary氏によると、Config Connectorは認可チェックを実行しておらず、組織レベルの権限を持つConfig Connectorサービスアカウントであれば誰でも、IAM認可をバイパスしてGCP組織全体—Google Cloud内における企業のすべてのリソースのルートノード—に対する最高レベルの制御権限（roles/owner）を獲得できるといいます。
3月27日、GoogleのセキュリティエンジニアがO’Leary氏のレポートを受理し、「ナイスキャッチ！」と伝えました。
そのエンジニアは、O’Leary氏のレポートを基に関連プロダクトチームへバグを報告したと述べ、Googleのセキュリティチームが関係するGoogle Cloudの担当者と連携してこの問題を修正すると請け合いました。
「プロダクトチームと連携してこの問題に対処します。修正が完了したらお知らせします」とエンジニアは述べ、「それまでの間、bughunters.google.comのプロフィールで選択した支払い方法をご確認ください」と付け加えました。
GoogleはこのバグにP1優先度・S1深刻度を割り当てました。これは、多数のユーザーに影響し、組織のコア機能を損なう可能性があるとして緊急修正が必要な欠陥を意味します。
「それで一件落着だと思っていました」とO’Leary氏は本紙との電話インタビューで語りました。
ところが11日後の4月7日、GoogleセキュリティBotから以前の決定を覆す新たなメッセージが届きました。本紙はそのメールを確認しており、O’Leary氏も木曜日に公開した記事にスクリーンショットを掲載しています。
メッセージには、Cloud Vulnerability Reward Programの審査委員会が「この問題のセキュリティへの影響が報奨金の受給基準を満たさない」と判断したと記されていました。
バグレポートを審査した結果、この問題は「意図どおりの動作」であるとGoogleは判断したとメッセージは続けており、バウンティの不支給という決定は「プロダクトチームが問題を修正しないことを意味するわけではない」とも記されていました。
それから約3カ月が経過した今も、このケースはP1/S1のまま「進行中（受理済み）」のステータスを維持しています。GoogleはCVEを割り当てておらず、修正も公開していません。O’Leary氏の調査に対する報奨金も支払われていません。
こうした事態はO’Leary氏に限らず、バグバウンティを申請する他のセキュリティ研究者にとっても初めてのことではありません。
O’Leary氏は今年初め、Microsoftでも同様の経験をしています。バグハンターの間で残念ながらよくある話となっているパターンで、O’Leary氏はAzure Backup for AKSにおける権限昇格の脆弱性を開示しましたが、Microsoftはレポートを却下。その後、CVEの割り当てやセキュリティアドバイザリの公開もなしに、密かに脆弱性を修正しました。
「これはパターンです」とO’Leary氏は本紙に語りました。「兆ドル規模の企業が私のような人間をどう扱うか、それだけのことです。本業ではGKEを使っており、広く利用されているシステムに重大な脆弱性を発見しても、ベンダー自身に修正させることすらできないのは、非常に苛立たしいことです」
Googleの見解
O’Leary氏の状況について本紙がGoogleに問い合わせたところ、同社は脆弱性が存在しないためバグバウンティの報奨金を支払わなかったと説明しました。
「報告された問題が報奨金の対象とならないのは、GCP IAM認可バイパスが、組織によってOrganization Admin役割を付与されたConfig Connectorサービスアカウントへのアクセス権を攻撃者がすでに持っている場合にのみ悪用可能だからです（つまり、特権アカウントが前提となります）」とGoogleのスポークスパーソンはThe Registerへのメールで述べました。
「さらに、攻撃者がIAMバイパスなどの管理権限を持つコマンドを実行するために特権Config Connectorインスタンスを悪用するには、まず組織の環境（例：外部に露出したコンテナ）への侵入が必要です」とスポークスパーソンは続けました。「Config Connectorサービスアカウントにこのレベルのアクセス権を付与することは、Google Cloudが公開しているベストプラクティスおよび最小権限の原則に反します」
本紙がバグレポートのケースがなぜ「進行中」のままでクローズされていないのかを尋ねたところ、Googleはこの質問には回答しませんでした。
O’Leary氏は、これは自分が受け取ったのと同じ説明だと本紙に語りました。そして、その説明を納得していません。
確かに、複数のGKEクラスタにわたってリソースを管理するには、Config Connectorサービスアカウントに組織レベルの権限が必要です。しかし、Google自身のドキュメントがその設定方法をユーザーに案内しているとO’Leary氏は指摘しており、本紙もこれを確認しています。
さらに、「その権限を持っているからといって、任意のネームスペースユーザーがそれを悪用できていいはずはありません」とO’Leary氏は主張します。「一つのネームスペースへのkubectlアクセスを持ちながら、GCP IAMの権限はゼロの開発者が、Organization Ownerになれてはいけないのです。また、監査証跡を残さずにプロジェクト内の任意のサービスアカウントを偽装できるべきでもありません」
O’Leary氏はこう断言します。「脆弱性の本質は、認可チェックの欠如です。Config Connectorは、ユーザーが認可されているかどうかを確認することなく、ユーザーに代わって特権操作を実行しているのです」
3行のコード、5秒で完全な管理者権限を掌握
ConfigConfusionを実証するビデオでO’Leary氏は、攻撃者が3行のYAMLを書くだけで、約5秒でGCP組織全体の完全な管理者権限を取得できることを示しています。
「Config Connectorには検証チェックが欠如しています」と彼は述べます。「Config ConnectorはGoogle管理のKubernetesオペレーターであり、この検証チェックの欠如が『混乱した代理人（confused deputy）』を生み出していることを発見しました。つまり、誰が何を要求しているかという検証が行われていないのです」
「混乱した代理人」問題は、ある操作を行う権限を持たないエンティティが、より高い権限を持つエンティティにその操作を強制できてしまうため、重大なセキュリティ上の課題となっています。
この問題を悪用するには、一つのネームスペースへのkubectlアクセスを持ちながらGCP権限は持たない開発者が、悪意のあるIAMPolicyMemberを送信することで、攻撃者の権限を昇格させます。
Config Connectorは、認可チェックを行わずにユーザーが制御する組織IDをGCP IAM APIに直接渡し、そのユーザーをGCP Organizationのオーナーにしてしまいます。これにより攻撃者は、プロジェクト、シークレット、課金情報、Gmailアカウントなど、環境内のあらゆるものに対する完全な管理者権限を取得します。
「しかも、その記録は一切残りません」とO’Leary氏は言います。
これは「攻撃者のKubernetesアイデンティティがGCP IAMに一切触れることがない」ためだと、彼は開示情報の中で述べています。「Config Connectorが、自身の昇格された認証情報を使ってリクエストを実行するのです」
「Jenga」型脆弱性
O’Leary氏によると、Googleはこれまでに、GCPにアクセスする別のサービスにおけるこの「混乱した代理人」の問題を2度修正しています。Tenable Researchがそれらの問題を記録し、Googleに報告していました。
一つは「ImageRunner」と呼ばれるもので、Google Cloud Runの権限を悪用して同じアカウント内のプライベートなGoogle Artifact RegistryおよびGoogle Container Registryのイメージを取得できるものでした。もう一つは「ConfusedComposer」で、Cloud Composer環境内で編集権限を持つアイデンティティが、デフォルトのCloud Buildサービスアカウントへと権限を昇格できるものでした。
「GCPにおけるこの権限昇格の脆弱性は、私たちが『Jenga』と呼ぶ、クラウドサービスにおける脆弱性の広範な攻撃クラスに基づいています」と、当時TenableのセキュリティリサーチャーLiv Matan氏は述べました。
ConfusedComposerは「クラウドサービスの権限に関連する、やや見えにくいクラウドプロバイダーの設定ミスを悪用して、意図されたアクセスレベルを超えた権限昇格を実現します」とMatan氏は説明しました。「このバリアントは、攻撃者がサービスオーケストレーションプロセスの一環としてクラウドプロバイダーが舞台裏で自動的にデプロイする、相互接続されたサービスをどのように悪用できるかを示しています」
Googleは最終的に、Cloud RunとCloud Composerの両方に認可チェックを追加しました。O’Leary氏は、なぜGoogleがConfig Connectorにも同様のチェックを追加できないのかが理解できないと述べています。
あるいは、薄々わかっているのかもしれません。
「私対Googleの構図です」と彼は言います。「TenableにはPRチームや法務チームがあるので、Googleも同じレベルのガスライティングはできません。私はただ、どうしてこれが真実なのか理解できないと言っている一個人に過ぎません」—つまり、高深刻度・高優先度のバグでありながら「意図どおりの動作」でもあるという状況が、いったいどうして成立するのかということです。
「そしてGoogleはただこう言うのです。『まあ、そういうことです』」 ®
