Google OAuthログインは、失敗したスタートアップのドメインを買われると防御できない

 (trufflesecurity.com)
6 ポイント 投稿者 GN⁺ 2025-01-15 | 3件のコメント | WhatsAppで共有
  • Google OAuthのセキュリティ欠陥により、「Sign in with Google」認証プロセスに深刻な脆弱性がある
    • 失敗したスタートアップのドメインを購入した後、そのドメインのメールアカウントを再構成してSaaSサービスにログインできる
    • 機密データを含むサービスにアクセス可能:
      • Slack、ChatGPT、Notion、Zoom、HRシステム（社会保障番号を含む）
    • Googleは初回報告時に「意図された動作」として修正を拒否
  • 問題の根本原因: Google OAuthはドメイン所有権の変更を検知できない
    • ドメイン変更時、新しい所有者が以前の従業員アカウントに同一の資格情報（claims）でログイン可能
  • 使用される基本的な資格情報:
    • hd（ホスト対象ドメイン）: ドメイン情報を含む（例: example.com）
    • email: ユーザーのメールアドレスを含む（例: user@example.com）
  • サービス提供者がこの2つの情報に依存すると、ドメイン所有権の変更時にも同じアカウントへのアクセスを許してしまう
  • 問題の規模
    • 米国では600万人がスタートアップで勤務中
    • スタートアップの90%が失敗
    • 失敗したスタートアップの50%がGoogle Workspacesを使用
  • 約100,000件の失敗したスタートアップのドメインが購入可能
  • 平均してドメインごとに従業員10人、SaaSサービス10件を利用 → 1,000万件を超えるアカウントに機密データが含まれる可能性

解決策の提案とGoogleの対応

  • Googleに提案された解決策:
    1. ユーザー固有ID: 時間が経っても変わらない一意のユーザー識別子を追加
    2. Workspace固有ID: ドメインに紐づく一意のWorkspace識別子を追加
  • Googleの初期対応:
    • 2024年9月に報告 → 「修正不可」として終了
    • 2024年12月のShmooconカンファレンスでの発表後、Googleが再び問題を再検討
    • $1,337のバグバウンティを支払い、修正作業を開始
  • 現時点では、Googleの修正なしに根本的な問題を解決することは不可能
  • 一部のサービスは、ドメインが一致すると全ユーザー一覧を返すため、脆弱性はさらに悪化する
  • Googleログインの代わりにパスワードを使っていても、リセット可能
    • スタートアップはパスワード認証の代わりにSSOと2FAを強制適用
    • サービス提供者はパスワード再設定時に追加認証を要求（SMSコード、クレジットカード確認）

結論: Google OAuthセキュリティの根本的問題

  • GoogleのOAuth実装の欠陥により、ドメイン所有権の変更時にアカウント乗っ取りが可能
  • Googleの修正作業は始まったが、根本的な解決策はまだ未完了
  • 現時点では、数百万人の米国人のデータとアカウントが危険にさらされている

関連記事

3件のコメント

 
sixmen 2025-01-15

私は、ドメインを含むメールアドレスを認証手段として使っておきながら、そのドメインを手放す際に関連するSaaSをきちんと廃止しなかったユーザー側のミスだと思うのですが、これもセキュリティ上の欠陥と見なすべきなのでしょうか。
 
kargnas 2025-01-16

私が作っているサービスではこの問題を事前に防いでいましたが、それでもこの意見には共感します。
これが問題だというなら、一般的なメールアドレスによるログインや会員登録もすべて問題だと考えるべきです。どれもメールアドレスを固有IDとして使っており、パスワード再設定の認証でもすべてメールで所有確認をしているからです。

極端な話、gmail.com や hotmail.com のような有名ドメインがハッキングされて、そのドメインのDNS設定権限がハッカーに渡ったと仮定すると、当然ながら世界中のあらゆるSaaSのアカウントが危険にさらされるのはごく当然です。
 
GN⁺ 2025-01-15
Hacker Newsのコメント

  • DankStartupが事業を畳み、別の人物がドメインを取得して既存アカウントにアクセスできる状況は、DankStartup、Microsoft、OpenAIの責任問題に見える

    • これをOAuthの脆弱性として説明するのは適切ではない

  • GoogleのOpenID実装では、subクレームを使って認証するのが正しい方法である

    • subクレームが変更される場合に備えたフローが必要である
    • 提案されている「変更されない一意のユーザーID」はsubクレームと実質的に変わらない

  • DNSに依存する方式の根本的な問題であり、ドメインの期限切れ後に新しい所有者が以前の所有者の権限を持ててしまう

    • メールアドレスやDNSに依存する認証システムで起こりうる問題である

  • Google OAuthに脆弱性はなく、ドメインを取得すればそのドメインのすべてのメールアドレスを所有することになる

    • Google OAuthを使っていなくても同じ結果になりうる

  • 過去のthehunt.comの事例では、ドメイン取得後にあらゆるサービスへアクセスできたという経験の共有

    • ドメインの状態を監視してセキュリティ脅威を防ぐスタートアップのアイデアを提案

  • subフィールドを使わないサービス側の問題であり、ユーザー識別にはsubフィールドを使うべきである

    • subフィールドを使っていないサービスに脆弱性レポートを提出して収益化できる

  • GoogleのOpenID Connectで、2つの不変識別子を実装する提案

    • subクレームと、ドメインに紐づいた一意のWorkspace ID

  • Google OAuthでsubクレームが変更されるケースはまれであり、サービス実装の問題である可能性が高い

  • ドメイン取得後にメールへアクセスできた事例の共有

    • Googleとの内部的なつながりを通じて問題を解決

  • 「数百万のアカウント」という主張は、失敗したスタートアップがSaaSアカウントを無効化しないという前提に基づいている