Google CloudがGoogle Cloud VRPを更新、25万ドルの報奨で最上位枠を強化

Google Cloud VRPに加わった報奨枠

Google Cloud VRPは、世界のセキュリティ研究者と連携し、重大なソフトウェアの脆弱性の発見を促すプログラムです。Google Cloudは、最上位の報奨枠を拡充し、25万ドルのRoot-in-Cloud報奨を新たに設けました。^[1]

図1　Root-in-Cloud報奨の概要

自動化された研究によって、本物の脆弱性かどうかを確かめることが難しくなっています。Google Cloudは、自動化だけの発見を超える、人が主導する高度な研究を後押しする必要があるとしています。

Root-in-Cloud報奨は、テナント分離の回避やサービス間の論理の欠陥のような、影響の大きい複雑な発見を評価する狙いです。Google Cloudは、こうした脆弱性の特定には人の創造性や直感、厳密なシステム分析と、エージェント型システムの力の組み合わせが必要だとしています。

Root-in-Cloud報奨の検証方法

Google Cloudは、本番環境への影響を避けつつ試験を安全で明確かつ再現できるものにする狙いで、root-in-cloudアクセスの技術的な検証基準を定めました。proof-of-rootは、明確な暗号による検証を指します。^[1]

図2　proof-of-rootの検証と報告の適格性評価

proof-of-rootでの検証

Chris Betz氏は、25万ドルの報奨に対し、利用者の環境やサービスの可用性を危険にさらさずに研究者が発見を検証する方法を尋ねています。Google Cloudの脆弱性報奨プログラムを率いるMichael Cote氏は、高い報奨には明確で安全なルールが必要だと答えています。

図3　proof-of-rootの仕組み

Google Cloudは、研究者が実際の利用者のプロジェクトで攻撃手法を試すことを望んでいません。代わりに、指定されたサービスアカウントを使う決定的なproof-of-rootの仕組みを作り、研究者はそのIDへの不正アクセスを暗号技術で証明できます。

本番基盤でのRCEやroot取得の報告

Googleの本番基盤であるBorgで遠隔コード実行（RCE）を示した有効な報告は、Root-in-Cloud報奨の適格性を自動で評価されます。root-in-prodを達成した有効な報告も、Google Cloud VRPのパネルによる同じ評価の対象です。

Google Cloud VRPのパネルは、最初の侵入地点や実行コンテキスト、攻撃対象領域を分析します。その位置から任意のテナントやプロジェクトを完全に乗っ取れるかを判断し、判断に応じて報奨を授与する仕組みです。

図4　パネルが分析し判断する内容

Google Cloud VRPの詳細は、ルールページにまとめられています。ルールページには、エンドポイントの詳しい仕様やJSONペイロード、CLIの例が含まれます。

Root-in-Cloud報奨の必要要件

Root-in-Cloud報奨を得るには、任意のGoogle Cloudの組織やプロジェクトで、完全な管理権限を示す必要があります。完全な管理権限は「roles/owner」相当かIAMの完全な制御を指し、事前のアクセスや特別なプロジェクト設定がない状態から示すことが条件です。^[1]

図5　Root-in-Cloud報奨の適格性の必要要件

攻撃経路は、被害を受けるプロジェクトの既存のアクセスや足場に依存できません。漏えいやフィッシング、窃取で得た認証情報と、ユーザーの操作やソーシャルエンジニアリングにも頼れません。

Borgで実行を得た後のルール

Borgでのコード実行はサービスの可用性やテナントをまたぐデータに影響しうるため、研究者はBorgで何らかの実行を得た時点で調査をすべて止める必要があります。権限の昇格や本番環境の認証情報の取り出し、横方向への移動は認められず、行った研究者は失格となります。

図6　Borgでの実行と本番基盤の境界のルール

Google Cloudは、プログラムのルールを更新し、Googleの本番基盤の周りに厳格な境界を設けました。成果に近いが境界が不確かな研究者が連絡した場合、Google Cloudは、研究者が報奨を無効にする行動を取らずに研究の価値に応じて報奨を得られるよう協力するとしています。

Root-in-Cloudの報告前確認

Root-in-Cloud報奨を目指して報告を準備する場合は、示す権限と攻撃経路の前提を、達成条件と照らし合わせる手順が考えられます。Borgで実行を得た場合は、その時点で調査を止めたかどうかも確かめる対象です。

図7　報告前に確かめる点（編集部の整理）

エンドポイントの詳しい仕様やCLIの例は、ルールページで照らし合わせる項目です。編集部の確認点は必要要件の照合にとどまり、乗っ取りの可否と報奨の授与はGoogle Cloud VRPのパネルが判断します。

Google Cloud VRPに届く報告の変化

Google Cloud VRPへの有効な報告の数は、発表時点までの過去18か月で横ばいでしたが、報告の総数は大きく増えました。Michael Cote氏は、自動スキャナーが影響の小さいノイズを大量に生んでいるとみています。^[1]

自動化は脆弱性発見の民主化を助け、参入障壁は急速に下がっているというのがMichael Cote氏の見方です。興味深いバグを持つ研究者や初めての研究者が増え、経験豊富な研究者には速さと影響の大きい発見が求められる一方、経験は成功を分ける鍵であり続けるとしています。

図8　Michael Cote氏がみる報告の変化

Michael Cote氏は、人の直感とエージェント型ツールを組み合わせる初めての研究者が、2年前の初心者より平均して興味深いバグを見つけているとしています。人の創造性とエージェント型の力の組み合わせは、どちらか単独よりはるかに豊かだというのが同氏の見方です。

Michael Cote氏は、Root-in-Cloud報奨を過去1年間の研究分野の変化を踏まえたものと位置付けています。同氏は、誰からの報告であっても質の高いものを重視するとしています。

公開を急ぐ圧力への懸念

Michael Cote氏は、速さを求める圧力を注視する必要があるとしています。悪用された脆弱性の数の最も急な増加はゼロデイではなくn-dayに由来するというのが、GTIGの調査結果です。

図9　早期公開に関するMichael Cote氏の懸念

同氏は、新たな報告の流入に伴い、公開を急ぐ圧力が強まることを懸念しています。その兆しはすでに見え始めているというのが同氏の見方です。

大規模言語モデルがソースを閲覧できるソフトウェアでのバグ発見の障壁を下げ、研究者は検証を待つ間に先を越されることを心配しています。同じ競争圧力は実績あるセキュリティ企業にも未対策の脆弱性を調整なく開示させかね、その性急さが利用者を直接危険にさらすというのが同氏の見方です。

同氏は、攻撃者が大規模言語モデルを使い、新たに公開された脆弱性の詳細を実際に使える攻撃コードへ素早く変えているとの公開情報の指摘を挙げています。報告の急増に選別担当が追われる中、未対策の脆弱性を標準の90日の協調的開示期間より大幅に早く開示すると、攻撃者に利用者を狙う知識と時間を与えるというのが同氏の見方です。

図10　報告急増の中で未対策の脆弱性を早期開示するリスク

90日＋30日の開示方針

Project Zeroは、90日＋30日という業界の責任ある開示の方針づくりを助けました。Michael Cote氏は、自律的な検出や悪用の能力によって、協調的な開示に従う意味がこれまで以上に大きくなったとしています。

図11　協調的開示に関するMichael Cote氏の見方

Michael Cote氏は、長期的には最初の公表を急ぐことが、セキュリティ企業自身の利益に反するとみています。新しい発見で一時的に注目を集めても、利用企業や広いエコシステムを危険にさらす組織は、最終的に利用企業に選ばれなくなるという見方です。

AIの転換点への3つの助言

Chris Betz氏は、自社で脆弱性管理の仕組みを運用し、外部の研究者と連携する企業のCISOに向けて、AIの転換点を乗り切るための助言を尋ねています。Michael Cote氏は、この問いに3つの提言で答えています。

図12　自社で脆弱性管理を運用し外部研究者と連携するCISOへの提言

こうしたCISOに向けた同氏の1つ目の提言は、エージェントが生成した報告に備え、もっともらしく見える誤りと本物のリスクを見分けて、有効な報告の滞留を防ぐことです。2つ目は、開示から実際に使える攻撃までの期間が縮むことに合わせて、公開後の修正や緩和策を早めることです。

3つ目として、セキュリティパートナーやベンダーに高い水準の協調的開示を求めるよう勧めています。同氏は、業界全体でエージェントによる脆弱性研究を責任ある形で当たり前にし、あらゆる取り組みで利用者の安全を中心に据え続ける必要があるとしています。