Pre-hijacking Attacksのメモ書きやSSO/パスワードリセット/アカウントマージ周りのチェックリスト

Pre-hijacking Attacksについてのメモ書きです。元の論文と記事は次のページを読んでください。

[2205.10174] Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web
New Research Paper: Pre-hijacking Attacks on Web User Accounts – Microsoft Security Response Center

Pre-hijacking Attacks はメールアドレスの確認をしないでアカウントを作れるサービスという前提があります。

アカウント作成からそのまま機能を利用できるようにすることで、利用体験をよくするための施策として、メールアドレスの確認のステップを後回しまたはしないサービスがあります。モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするためにメールを確認しないでアカウント作成ができるサービスもあります。

例) Dropboxはメールアドレスとパスワードを入力して新規アカウントを作成できる。このときに、自分が持っていないメールアドレスでもとりあえずアカウントを作成できて、そのままログインできる。

攻撃の種類

📝 メールアドレスと書いてるけど、電話番号 + SMSも基本同じ。ログインするIDという意味合い

1. Classic-Federated Merge Attack:

攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
被害者は、GoogleログインなどのSSOでログインする
メールアドレスとIdPのメールアドレスが一致するのでアカウントがマージされる
攻撃者は、メールアドレスと攻撃者が設定したパスワードでログインできるので、マージ後の被害者のアカウントを乗っ取れる
対策:
- アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する

2. Unexpired Session Identifier Attack:

攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
攻撃者は、そのままログイン状態を維持するように定期的にアクセスし続ける
被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
被害者が、パスワードリセットしてサービスにログインして利用する
パスワードリセット時に、攻撃者がログインしていたセッションが切れないため、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
対策:
- パスワードリセットするときに、セッションもリセットする

3. Trojan Identifier Attack:

攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
攻撃者は、そのアカウントと攻撃者のIdPアカウントを紐づけておく
被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
被害者が、パスワードリセットしてサービスにログインして利用する
攻撃者は、攻撃者のIdPアカウントでサービスにログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
対策:
- アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
📝 Classic-Federated Merge Attack は被害者がSSOでログイン、Trojan Identifier Attackは攻撃者がSSOでログインの違い
- どちらもマージの挙動を利用した攻撃
📝 もと論文だと、もう一つの攻撃が含まれていて、サブメールアドレスや電話番号を最初に紐づけておいて、それでリセットする攻撃も同じくTrojan Identifier Attackと言ってる
- Classic-Federated Merge Attackの対義語として扱った方がいいので、SubProcess Attackみたいな別の名前に分離したい

4. Unexpired Email Change Attack:

攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
攻撃者は、そのアカウントで攻撃者のメールアドレスに変更の申請をしておく(まだ確定はしない)
サービスは、メールアドレスの変更の確認メールを攻撃者のメールアドレスの送信する(まだ確定はしない)
被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
被害者が、パスワードリセットしてサービスにログインして利用する
攻撃者、メールアドレスの変更の確認メールからメールアドレスの変更を確定する
攻撃者は、攻撃者のメールアドレスでログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
対策:
- パスワードリセットするときに、メールアドレスの変更を保留している状態もリセットする
- メールアドレスの変更の有効期限を設定する

5. Non-Verifying IdP Attack:

攻撃者は、メールアドレスの確認をしないIdPで被害者のメールアドレスを使ってアカウントを作成する
被害者は、自分自身のメールアドレスでアカウントを作成して利用する
攻撃者は、被害者のメールアドレスを使ったIdPでサービスにログインしてアカウントをマージさせる
攻撃者は、被害者のアカウントを乗っ取れる
📝 メールアドレスの存在確認などをしてないIdP連携の問題
- またサービスが、OpenIDのclaimに含まれる email_verified をチェックせずにマージしているとこの問題が起きる
- マージするときは、そのサービスでメールアドレスが確認ずみ + IdPアカウントのメールアドレスが確認ずみで初めてマージする
- さらにより良くするには、マージするタイミングで、サービスのメールアドレスに紐づくパスワードをリセットまたは再入力して、マージするタイミングでの持ち主をもう一度検証する
対策:
- そういうメールを検証しないIdPでSSOは実装しない
- アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する

チェックリスト

アカウント作成時には、メールアドレスの検証をしてからアカウントを作成する
- これができるとPre-hijacking AttacksのNon-Verifying IdP Attack以外は防げる
アカウント作成時に、メールアドレスの検証用のトークンなどを露出しない
- https://example.com/account/activate?token=xxx みたいなURLをメールに載せると思うが、このxxxトークンをレスポンスとかメールを確認してねページなどに露出しない
- メールアドレスの検証を回避できてしまうため
メールアドレス変更時に変更後のメールアドレスに確認メールを飛ばしているか
- #791775 Email Confirmation Bypass in myshop.myshopify.com that Leads to Full Privilege Escalation to Any Shop Owner by Taking Advantage of the Shopify SSO

メールアドレスの検証前にアカウントを作るサービスの場合

メールアドレス未確認のアカウントを定期的に削除する
メールアドレス未確認状態での機能を制限する

どちらのケースでも共通でやるべきもの

azu/Pre-hijacking Attacks.md