クラウド機械学習プラットフォームは、わずか数行のコードの背後に複雑なインフラを隠していることがよくあります。しかし、この便利な自動化機能が、Google Vertex AI Python SDKに深刻な脆弱性を生み出してしまいました。Palo Alto NetworksのUnit 42の専門家がこの重大な欠陥を発見しました。この脆弱性により、部外者がモデルのアップロードを傍受することが可能となり、モデルをホスティングするGoogleのインフラ内で不正なコードを実行できる状態になっていました。
予測可能なストレージバケットがもたらすリスク
この問題は、開発者がカスタムのCloud Storageステージングバケットを指定しなかった場合に発生します。SDKはプロジェクト識別子とリージョン情報を組み合わせた、予測可能なパターンでストレージ名を自動生成します。さらに、システムはバケットの存在確認のみを行い、所有権の検証は行いませんでした。Cloud Storageのバケット名はグローバルで一意であるため、攻撃者は自分のプロジェクト内で予測されるバケット名を先取りして作成することができてしまいます。
デシリアライゼーションと悪意あるコード
このすり替えが行われると、被害者のSDKは気づかないまま悪意あるバケットへモデルファイルを送信してしまいます。攻撃者はアップロードされたモデルを素早く悪意あるバージョンに差し替えます。このリスクをさらに高めているのが、Pythonでよく使われるプラクティスです。開発者はpickleやjoblibライブラリを使ってモデルを保存することが多いですが、これらのファイルは悪意あるロジックが埋め込まれている場合、ロード・デシリアライズの過程で任意のコードを実行してしまいます。
Unit 42による攻撃の実証
Unit 42の研究者たちは、制御されたテスト環境でこのシナリオを検証しました。Vertex AIモデルのハイジャック手法を詳述したレポートでは、攻撃に利用できる重要なタイミングの窓が確認されています。モデルのアップロードからVertex AIがファイルを読み込むまでの間に、約2.5秒の猶予があることが判明しました。実証デモでは、アップロード直後にCloud Functionをトリガーし、わずか1.4秒でモデルのすり替えに成功しました。つまり、Vertex AIが元のファイルにアクセスする前にすり替えが完了したことになります。その後、改ざんされたモデルはホスティングコンテナのメタデータサーバーからOAuthトークンを窃取しました。
広範なアクセスと影響
テスト中、盗み出されたトークンは広範なアクセス権を解放しました。その影響は、侵害されたモデルのデプロイにとどまりませんでした。攻撃者は同じGoogleマネージドプロジェクト内の他のモデルアーティファクトに関する機密情報を取得できます。このアクセス範囲には、学習済み重みを含むTensorFlowモデルも含まれていました。さらに、BigQueryのメタデータ、アクセス制御リスト、システムログも露出します。GKEクラスター名やコンテナイメージの内部パスまで明らかになりました。幸いなことに、Unit 42は実際の悪用事例は確認されていないと報告しています。
緩和策と修正手順
この攻撃が成立するには、2つの条件が必要です。第一に、被害者のデフォルトステージングバケットが選択したリージョンにまだ存在していないこと、第二に、ステージングバケットのパラメータが空のままであることです。Googleは2026年3月5日に脆弱性の報告を受け、バージョン1.144.0でバケット名にランダムな識別子を追加することで迅速に問題を緩和しました。その後、4月15日にリリースされたバージョン1.148.0で完全な修正が完了し、アップロード時に厳格なバケット所有権検証が導入されました。
Google Vertex AI Python SDKのユーザーは早急な対応が必要です。google-cloud-aiplatformライブラリをバージョン1.148.0以降にアップデートしてください。また、管理されたCloud Storage環境内でステージングバケットを常に明示的に定義することが重要です。さらに、インタラクティブ環境、継続的インテグレーション、自動モデルトレーニングプロセスを含む、すべてのデプロイ環境でSDKのバージョンを厳格に確認するようにしてください。
翻訳元: https://meterpreter.org/google-vertex-ai-vulnerability/
