Simonkoeck氏によると、Googleはこの問題を2026年10月7日に修正しました。同氏は、本番環境のインフラに対してOSコマンドを実行する代わりに、遅延時間を制御した実行によって攻撃が成立することを実証しました。
ペイロードをデコードして展開すると、CSRFトークンと、google_oauth2_flow_<csrf>というキーで保存されたシリアライズ済みのOAuthフローオブジェクトが見つかりました。
Flaskのbytesタグは、oauth2client.client.OAuth2WebServerFlowオブジェクトを含むPythonのpickleをBase64エンコードして包んでいました。
このオブジェクトからは、OAuthのクライアントIDとクライアントシークレットが露出していました。さらに重要なのは、露出したクライアントシークレットが、アプリケーションのFlask SECRET_KEYとしても使われていたことを同氏が突き止めた点です。
これにより、完全性が全面的に損なわれる状態が生じました。攻撃者はセッションの内容を改変し、サーバが信頼する署名を生成できます。OAuthコールバックはFlaskの署名を検証したうえで、対応するフローエントリを取得してバイト列をデコードし、pickle.loads()に渡していました。
そのため攻撃者は、正しく署名されたセッションの中に、任意のシリアライズ済みオブジェクトを仕込むことができました。CSRFトークンと、それに対応するフローキーの両方を自由に選べるため、デシリアライズ処理に到達できたのです。
Simonkoeck氏は次のように説明しています。Pythonのpickleは、オブジェクトの復元時に呼び出し可能オブジェクトを実行できます。攻撃者が信頼されるpickleペイロードを制御できるようになった時点で、コールバックは認証なしでコードを実行できる経路になりました。
同氏は安全に実証するため、さまざまな時間を指定したtime.sleep()を呼び出すペイロードを使用しました。応答時間は、遅延0秒で約0.207秒、3秒で3.193秒、5秒で5.194秒、8秒で8.283秒でした。
開示された情報によると、影響は7つのGoogleドメインに及びます。ただし、提供された説明で明示されているのは、developers.google.com、firebase.google.com、developer.android.com、source.android.com、docs.partner.android.comの5つです。
Simonkoeck氏は、露出したOAuthシークレットのローテーション、影響を受けたセッションの無効化、各デプロイメントへの独立したサーバ側署名鍵の割り当て、OAuthフローオブジェクトのサーバ側での保持、クライアントが制御できるpickleデータの検証済みデータ専用シリアライズへの置き換えを推奨しています。
報告は8月6日に提出され、8月7日にトリアージを経て受理され、8月27日に報奨が支払われました。報奨金9万ドルは、基本額7万5,000ドルに、報告の質が非常に高いことを評価した1.2倍の係数を乗じたものです。
1万6,000以上のSOCチームがANY.RUNを活用し、脅威調査の効率化と手作業の削減を実現しています。 自社チームで試してみる
翻訳元: https://cyberpress.org/critical-google-devsite-flaw/
