Google OAuthの一部機能に障害が発生

 (trufflesecurity.com)
1 ポイント 投稿者 GN⁺ 2023-12-22 | 1件のコメント | WhatsAppで共有
  • Google OAuthのemail claimを信頼してログイン権限を判断するサービスでは、退職者が会社のGoogle組織から削除された後も、SlackやZoomのようなアプリへのアクセスを維持できる可能性がある
  • Gmail以外のメールでもGoogleアカウントを作成でき、会社メールのエイリアス・プラスアドレス転送を使うと、組織に属していないGoogleアカウントでも会社ドメインのemail claimを送信できる
  • この非Gmailアカウントは会社のGoogle組織の管理画面やユーザー一覧には表示されないが、多くのサービスはメールアドレス末尾のドメインだけを見てログインを許可している
  • 組織はGoogleログインを無効化し、SAMLを厳格に適用することで緩和できるが、一部のサービスや社内アプリではこのオプションが提供されていない、またはSAMLをサポートしていない場合がある
  • Googleには8月4日に報告され、10月5日に**$1337**の報奨金が支払われ、12月16日に134日後の公開となったが、公開時点までGoogleの緩和変更はデプロイされていなかった

脆弱性の公開とタイムライン

  • Google OAuthの脆弱性により、会社でオフボーディングされGoogle組織から削除された従業員が、SlackやZoomのようなアプリケーションへのアクセスを無期限に維持できる可能性がある
  • 公開時点までGoogleはこのリスクを緩和する変更をデプロイしていなかった
  • タイムラインは以下の通り
    • 8月4日: Googleに報告し、数百のアプリケーションに影響する可能性を伝達
    • 8月7日: 問題がトリアージされた
    • 10月5日: Googleがこの問題に対して**$1337**を支払った
    • 11月25日: ZoomやSlackを含む影響を受ける数十のアプリケーションに非公開で一括報告
    • 12月16日: Googleへの通知から134日後に公開

識別子としてemail claimを使うリスク

  • Truffle SecurityのForagerログインは、以前にDescopeのMicrosoft OAuth脆弱性の影響を受けたことがある
  • 当時、Microsoftが直接生成または検証していないEmail claimを送信できること、そしてemail claimは一般に信頼できる識別子ではないことが確認された
  • GoogleのOIDCドキュメントも、Emailをデフォルトの識別子として使わないよう警告している
  • email_verified claimも特異な点として扱われたが、未検証のメールからemail claimを生成する方法は確認できなかった
  • ただし、email claim自体を悪用するケースは十分に確認された

非GmailのGoogleアカウントと重複するemail claim

  • GoogleアカウントはGmailアドレスでなくても既存のメールアドレスで作成できる
    • たとえばYahooのメールアドレスでGoogleアカウントを作成できる
    • このアカウントは非Gmailメールを設定した状態で、そのメールのemail claimを送信できる
  • Googleのドキュメントがメールをデフォルトの識別子として使わないようにしている理由の1つは、異なる2つのGoogleアカウントが同じemail claimを送信できるためである
    • 設定で非Gmailメールを変更し
    • 変更前のメールで新しいアカウントを作ると、同じemail claimが可能になる

会社のGoogle組織外に残るアカウント

  • 中核となる欠陥は、会社のGoogle組織メールに対してメールエイリアスとプラスアドレス転送を利用し、組織外のGoogleアカウントを作成できる点にある
  • 会社メールのプラスアドレスは、本来のユーザーの受信トレイに転送されることがある
  • この流れにより、会社のGoogle組織メールを使ったプラスアドレスベースの非Gmail Googleアカウントを作成でき、このアカウントは組織側で削除したりオフボーディングしたりできない
  • 多くのサービスはこのメールを解析し、末尾のドメインを基準にログイン可否を判断している
    • このアカウントでZoomに登録できる
    • このアカウントでSlackに登録できる
  • このような非Gmail Googleアカウントは実際のGoogle組織メンバーではないため、管理者設定やユーザーのGoogle一覧には表示されない

組織・サービスプロバイダー・Googleの緩和策

  • 組織はGoogleログインを無効化し、SAMLを厳格に強制することで緩和できる
    • 大半のサービスプロバイダーではこの方法が機能する
    • 一部のサービスではこのオプションが提供されていない
    • 社内開発アプリケーションが影響を受ける一方で、SAMLをサポートしていない場合もある
  • サービスプロバイダーはGoogle OAuthのHD claimを利用できる
    • HD claimは、アカウントが関連付けられているGoogle組織のドメインを送信する
    • Google組織のメンバーではないアカウントにはHD claimが含まれない
    • テストした大半のサービスプロバイダーはHDではなくemail claimを使っていた
  • HD claimには重要な限界が残っている
    • HDは一意の識別子ではなく、単なるドメインである
    • Google組織が削除されてドメインが放置されると、別の誰かがそのドメインを取得して新しいGoogle組織を作成できる
    • 会社Aが会社Bに買収され、BがAのサービスを終了し既存ドメインを更新しないケースが例として挙げられる
    • インターネット上の誰かが会社Aのドメインを購入すれば、会社Aの既存サービスアカウントにログインできる可能性がある
  • サービスプロバイダーはJITアカウント作成を一般機能として許可せず、招待制またはLDAPグループベースのアカウントプロビジョニングへ移行できる
  • Googleは既存のGoogle組織ドメインで作成されたGoogleアカウントを禁止する形で広く緩和できる
    • Googleはgoogle.comアカウントを独自に禁止している
    • 同じ保護を他の組織にも拡張できる
  • Google側の別の緩和策としては、プラスアドレスによるGoogleアカウント登録の禁止、Googleメールエイリアスによる登録の禁止、組織が関連設定を構成できるより良い管理者設定の提供がある

追加の影響: サポート用メールとmagic linkフロー

  • 初期アクセス権がなくても、組織のZoomやSlackにアクセスすることが技術的には可能な場合がある
  • この流れは、他の研究者がmagic link sign-in flowsで見つけた脆弱性研究を活用する
  • Zendeskのような一部のサポート・チケットシステムでは、メールでサポートチケットを作成できる
    • サポートチケット用メールアドレスでGoogleアカウントを作成できる
    • チケット内容を確認してアカウント作成を完了できる可能性がある
    • その後、そのサポート用メールアドレスでOAuthログインを試行できる
  • メインドメインでemail to support機能を維持するのは安全ではなく、Zendeskのサポート用メールを代替メールアドレスとして構成する方法がある

公開の目的と残る問題

  • SlackやZoomのようなプラットフォームで元従業員がアクセスを維持できる問題は、Google OAuthシステムの欠陥に起因している
  • Googleにはこの問題を緩和できる広範な修正を行う能力がある
  • 公開の目的は、些細なドキュメント変更を超えて実際の変更を促すことにある
  • Googleは問題のトリアージ自体は迅速に行ったが、自社の90日改善慣行とは異なり、問題は134日目に公開された

関連記事

1件のコメント

 
GN⁺ 2023-12-22
Hacker Newsのコメント

  • この分野で仕事をしていて、ここ3〜4年で複数のログインプロバイダやSaaS企業において、この脆弱性の亜種を20回以上扱ってきた。ブログ記事の内容は正しいが、根本的な問題は、もはや修正するには手遅れなところまで来ていると思う。インターネット全体の委任認証は完全にめちゃくちゃで、GoogleやMicrosoftのエンジニアともかなり話してきたので、この問題群がすでに認識されていることは確信している。ただ、今の挙動を変えると既存サービスや何十年も前の企業向けログイン実装があまりにも多く壊れてしまう
    現時点での「修正」は単純だ。サイトで「Sign in with XYZ」を使うなら、プロバイダが送ってくるメールアドレスを信頼してはいけない。メールドメインだけを見て特別な権限を与えず、データベースで検証済みと表示する前に必ず独自の確認メールを送るべきだ。主要なOAuthプロバイダも文書でそれを明記するよう更新しており、記事自体もそこを指摘している。だから報奨金が支払われたこと自体、むしろ驚きだ

    • 組織がこの領域が実際にどれほど複雑かをきちんと理解していないことの結果のように感じる。複数の企業でOAuth2 + OIDCが導入される過程を見ると、常にセキュリティ優先の観点ではなく、「xでログイン」のような機能として売られてきた。PKCEのようにフローをより安全にしようとしても、Cookie共有やリダイレクト処理などで各プラットフォームがひどい振る舞いをするせいで、もぐら叩きになってしまう。3-legged OAuth2の基本は堅牢で、CASのような先例も多いが、OpenID FoundationはOIDCをマーケティングし販売してきたやり方のせいで大いに批判されるべきだ
    • 「メールドメインだけを見て特別な権限を与えず、データベースで検証済みと表示する前に常に独自の確認メールを送れ」というやり方は、ユーザーがGoogleでプラスアドレス付きでアカウントを登録したあと、締め出される前にそのGoogleアカウントでサービスにログインしていた場合、失敗しないか？ 毎回のログインごとに確認メールを送るのでなければ
    • この特定のケースでは、攻撃者が実際に確認メールを受け取れるのだから、その確認手順に何の意味があるのかわからない
    • 「データベースで検証済みと表示する前に常に独自の確認メールを送れ」というのは、ユーザー視点ではxでログイン機能を無意味にしてしまう
    • Google Apps顧客のドメインを使った登録をGoogleが防ぐことはできなかったのか？ それは特に何かを壊しそうには思えない

  • 関連して、Googleのドキュメントが推奨するように、もっと多くのサービスプロバイダがメールアドレスをデフォルトの識別子として使うのをやめるべきだ。Google Appsでユーザー名を変更したとき、Slack、Datadog、GoLinksなどで問題対応にかなりの時間を費やした

    • プロバイダは何を使うべきなのか？ メールアドレスがユーザーにとって最も安定したグローバル識別子だとずっと思っていたが、その前提は間違っているようだ
    • 同意しにくい。こうしたガイドラインは責任をアプリケーション開発者に押しつけるだけで、ほとんどは何もしないか、ばらばらに実装する可能性が高い
      ここで正しい方向は、利用するアプリケーションの要件に合い、追加責任を最小化するAPIを提供することだ。このケースであれば、Googleがemail_verifiedをfalseに設定して、アプリケーションや下位IdPに追加検証が必要だと分かるようにすべきだったと思う

  • user@domainがすでにGoogleメールサーバーで処理され、そこにプラスルーティング規則が適用されるのなら、なぜuser+suffix@domainのようなメールアドレスで新しいGoogleアカウントを作れるのか分からない。悪用でなくても、混乱を招くメール設定を作るのにうってつけに見える

    • ドメインはメールサーバーを自由に移せる。Googleはa+b@domain.comを特定の方式で処理するが、他のサーバーではそうとは限らない。結局のところ、両者は別々の固有のメールアドレスであり、インターネット全体でもそのように扱われるべきだ
    • このエイリアス機能は、その価値に比べて複雑になりすぎている気がする。特にGoogle規模ではなおさらだ
    • user+suffix@domainよりもっと悪い。少なくとも+XYZはメールRFCで明記されている。Googleはさらに進んで、名前の中のドットも通常のメールアドレスとして扱うと決めた。たとえばhi.my.name@google.comはhimyname@google.comと同じで、すべてのメールは後者にルーティングされる
    • Googleの認証システムが非常に古いレガシーだからだ。「Googleアカウント」は単なる文字列だ

  • 「Microsoft が、Microsoft 自身が作成または検証していないメールクレームを送ること、そして一般にメールクレームは信頼できるものと見なされていないことを知って驚いた」という点については、元の意図がそうだったとしても、OIDC がより柔軟であり得るというのは非常に有用だと思う。たとえば無料のログインプロバイダー[0]を運営しているが、これは上位の OIDC や直接のメールを通じて、第4の当事者である ID プロバイダー（IdP）として本人確認を行い、アプリとその IdP の間に プライバシーの遮断膜 を作る仕組みだ。つまり Google がユーザーのログイン先すべてのアプリを追跡できないようにする
    Google に自分のメールを持ち込めるということは、Google OIDC のセキュリティとユーザー体験を、メール+パスワードのプライバシーとあわせて得られるという意味だが、今度は Google の代わりに LastLogin を信頼しなければならないという大きな留保がある。その依存を減らすプロトコルも進行中だ。「Google のドキュメントは実際にはメールを識別子として使うなと警告していた」という点には完全に反対する。メールは、人々が実際に使っている唯一の本当のフェデレーテッド・アイデンティティだ。よりよい代替が広く普及するまでは、メールアドレスをアイデンティティとして扱うべきだと考えている
    [0]: https://lastlogin.io

    • 「メールアドレスをアイデンティティとして扱うべきだ」という点には反対だ。理由は2つある
      欧米以外では、コンピュータより携帯電話のほうが一般的で、UI もたいてい簡単なので、電話番号 のほうがアイデンティティである可能性が高い。さらにそれでは、アイデンティティをメールプロバイダーに完全に委ねることになる。Google のような顔の見えない組織は、予告や異議申し立て手続きなしにアクセスを遮断できるし、実際にそうするので、すべてを失い得る。背景を言うと、Okta の OAuth と OIDC 製品を立ち上げ、LinkedIn の関連講座を作り、今は Pangea Cyber で再び同じことをしている
    • 「メールアドレスをアイデンティティとして扱うべき」だって、誰もメールアドレスを共有せず、メールは非常に安全だという前提なのか
      永遠に待ち続けることもできるし、あるいは解決策を作り始めることもできる
    • 自分のシステム内でのメール識別子と、紐づいた Google アカウントの識別子としてのメールには重要な違いがある。自分で管理するシステム内では、メールがアイデンティティとしてそこそこ機能することには同意するが、外部システムと結び付ける場合は、Google が言うようにひどいやり方だ。一時的で、複数アカウントに紐づく可能性もあり、使える実際の ID があるのだから、わざわざ使う理由がない
    • LastLogin と Dex を比較してくれると本当にうれしい。どちらも Go 製なので特に気になる。Dex を評価したのかも知りたい
      Portier や、昔の Mozilla Persona も少しいじったが、結局メール正規化の問題を扱うのは負け戦か、難しすぎる戦いに思えた。よい解決策が切り開かれる前に自分は死ぬのだろうと半ば受け入れて、関心を別のところへ向けた

  • これは本当に Google OAuth の問題なのか、それとも多くのサービス提供者がアクセスを許可する前に OAuth トークンのクレーム をきちんと検証できていなかった失敗なのか？ 後者に見える

    • これらのサービス提供者が Google のエイリアス規則には従いながら、メールを主要識別子にしてはいけないという事実は無視しているのが問題のように聞こえる [1]。面白いのは、仕様をもっと忠実に守っていれば問題なかっただろうし、逆に仕様をあまり守らずエイリアスを別々のメールとして扱っていたとしても、少なくともより安全ではあっただろうという点だ
      [1] https://developers.google.com/identity/openid-connect/openid...
    • OAuth は期待どおりに動いていると思う。user@domain と user+wildcard@domain は依然としてユーザーが「所有する」メールアドレスとして検証されるので、そのメールアドレスに対する有効な認証とアイデンティティを提供する
      問題は Google 組織向けウェブサイト側にある。管理者は、自分に見えないアカウントやメールの資格情報を取り消すことができない。「これらの非 Gmail の Google アカウントは実際には Google 組織のメンバーではないため、管理者設定や Google ユーザー一覧には表示されない」という部分が核心だ

  • このフローに従えば、サポートチケット用メールアドレスで Google アカウントを作成し、チケット内容を潜在的に確認してアカウント作成を完了し、そのサポート用メールアドレスで複数のサービスに OAuth ログインできる。これは多くの 小規模企業 に影響し得る

  • ここから得た最大の結論は、ウェブ認証が今なおひどい混沌だということだ

    • 人々がドキュメントを読まず、自分が考えた方式で動くとただ思い込むからだ
    • 正気で実務的な人たちが、なぜ今でも単純な パスワード認証 を使い、求めるのかといえば、パスワードはちゃんと動くからだ

  • OIDC 仕様は、メールを一意の識別子として使ってはいけないと述べている。アプリケーションのユーザー名には iss と sub フィールドを使うべきだ
    理由はまず、ユーザーのメールアドレスが再利用され得ることが明らかだからだ。ある契約社員が Business A と Business B の両方で働き、両社とも認証サービスにその人のユーザーアカウントを作成した場合、SaaS プラットフォームの観点では、1つのメールアドレスを単一の B2B 顧客に対応付けることはできない。次に、メールアドレスは変わる。企業は買収され、改名し、合併し、人の名前も結婚・離婚・個人的選択で変わる。スタートアップで SSO を実装するのは最初は本当に難しかった。正しくやるのが難しく、使う前に一般概念と OIDC、OAuth2 をよく理解しておく必要がある。Auth0 に良い本がある。これを理解していないと、あちこちで password grant 認証を実装してしまい、アプリケーションを安全でなくする可能性が高い

    • こういう文章を読むと、積み上がったインポスター症候群が少し和らぐことがある。「抽象的な行為者を表す何かのためにサードパーティのシステムと連携するなら、安定していて文字列頼みではない信頼できる識別子が必要なはずだ」と思うようになる。実際、仕様もこの点は非常に明確で、少しでも堅牢なシステムを作る際の基本的な考慮事項を超える話ではない

  • 小さな縮図のようなものだ。OAuth2なるものは実際には存在しない。OAuth2は巨大企業が自分たち独自の恣意的・独占的な認証システムを実装するための方法にすぎない。認証システムそのものではなく、認証システムを作るための道具箱だ。だからOAuth2は標準になるはずだったが、実際には巨大企業ごとに互換性のない実装を持つ世界になった。もちろん人々は巨大企業のユースケースに合わせて開発するのだろうが、そうなると「標準」は結局Googleのやり方のようなものになってしまう
    そしてそれぞれがこうした小さなバグを抱えている。OAuth1に戻るべきだ。あれは本当の標準であり、標準を作るための道具箱ではなかった

    • これはバグというより、特定の構成要素が組み合わさって生じた不運な副作用に近い。所有権が変わりうるドメイン名、自分のメールアドレス取得、バックアップメールアドレスとメールの出所、プラス別名の寛容な許容、そしてドキュメントを読まないサービス実装者たちが合わさった結果だ。実装者たちはおそらく、動画や簡潔さのために省略されたサンプルからソリューションをコピーした可能性が高い
      PCB部品をいくつか使って回路を設計し、電圧・電流要件に合わせて抵抗やトランジスタを入れなければならないなら、データシートを読むことを期待されるべきではないか。簡単なサンプルから適当に推測して押し通せば、多くの場合回路は動くかもしれないし、ベンチテストやプロービングを少しすれば動作するかもしれない。しかし効率が悪かったり、部品が短絡して平均故障時間が短くなり、顧客が不幸になるかもしれない。最悪の場合、バッテリーが発火して実際の被害が出ることもある。そうなったとき、装置が早期に故障するのはPCBモジュール製造元のせいなのか、それともデータシートを読むべきだった装置メーカーの責任なのか。ソフトウェア全般にそこまで厳しい期待はしないが、認証と認可を扱うのであれば、サービス所有者は徹底しているべきだと思う。元記事も、ドキュメントに従えば問題は存在しないと言っている。Alphabetはバグ報奨金を支払って脆弱性は認めたのだから、会社の管理者がプラス別名や存在しないロールを許可/拒否リストで管理する制御を提供したり、Apps関連のメールが組織外のクレームに移されるのを制限したりはできるだろう。おそらくこの影響度を測定中か、測定の優先順位を付けている最中だろうが、メールクレームを実際以上に権威的かつ永続的だと仮定するクライアント側の問題なので、優先度は低い気がする。「バグ」の定義は「想定された動作」をどう定義し、誰が想定するかに大きく左右されるが、少なくとも意図した動作から外れているわけではなく、ドキュメントを正しく理解した人にとっては予想外でもないと思う
    • うーん……だとしても、プロバイダー間の互換性はGoogle OAuth2セキュリティに関するこの記事と関係があるのか？

  • 何を見落としているのだろう？ 記事で言及されているサポートシステム/Zendeskと放置された古いドメインの手法を除けば、whatever@mydomain.comで新しいGoogleアカウントを作るときには確認を求められる。だとすると、実際の悪用可能性はどれほどあるのか？

    • 要点は、正当なアクセス権があるうちに前もって仕込んでおき、後になってそのアクセス権を失うということだ
      たとえば egamirorrim@mydomain.com というGoogleアカウントが正当に存在するとしよう。egamirorrim+woopsie@mydomain.com のような別名で検証済みメールアドレスを持つ新しいGoogleアカウントを作ることができ、すると「Googleでログイン」の際にGoogleは egamirorrim+woopsie@mydomain.com というメールクレームを送る。その後 mydomain.com を解雇された場合、実際の egamirorrim@mydomain.com に紐づくアカウントは管理者に無効化されているため、もうログインできない。しかし新しいGoogleアカウント egamirorrim+woopsie@mydomain.com は組織と結び付いていないので、そのままログインし続けられる。ただし私が見る限り、これが問題になるのはプロバイダーが メールクレームだけで認可 を行う場合に限られる。以前OIDCを使ったことがあるが、メールアドレスクレームのテキストをパースしてリソースアクセス権を付与してはいけない。筆者がなぜ直感に反すると感じたのかは理解できるが、記事でもドキュメントがこれをするなと警告していると書かれている。元記事には「私がテストしたサービスプロバイダーの大半はHDを使わず、メールクレームを使っていた」とあるが、いいとして、それを何に「使う」というのか？ このトリックは現実の実サービスで実際に動作するのか？ もしそうなら、名前を公開して批判を受けるべきだ。たとえこの値を一意で不変だと誤って仮定したとしても、それだけで必ず何らかのアクセス権が発生するわけではない