Zero-day in Sign in With Apple Deep-dive

Author: Nov Matake
Date:

先週末に Zero-day in Sign in with Apple とかいう記事が出ていました。

この記事ではいまいち詳細がわからないんで、ちょっと実際 Apple IdP の挙動調べてみたら、当該 Endpoint 発見しました。

実際にどこが脆弱だったのか

  1. 非 Safari ブラウザで、適当な RP にアクセス
    • e.g.,) http://signin-with-apple.herokuapp.com/ (Nov SIWA RP)
    • Safari だと OS の Native UI が出てきてブラウザ遷移しないので注意
    • 既に連携済の RP の場合は一度連携解除しておくこと
  2. Sign in with Apple のボタンをクリックして Apple AuthZ Endpoint に遷移
  3. ログイン後、初回連携時にのみ出てくる同意画面 (メアド選択するところ) に到達
    • Sign in with Apple Consent Screen
  4. ここで「続ける」を押すと内部的に Ajax Call が実行される

で、問題は Step.4 で Submit されるメールアドレスが、実際当該 Apple ID に紐づいてないものでも OK だったということですね。

The Real Cause of the Sign In with Apple Zero-Day という解説記事では、メールアドレスの値そのものを POST するんではなく real_email / proxy_email という Flag 値のみを POST すべしとか書いてますが、実際には Apple ID には複数のメールアドレスが紐付き Sign in with Apple の同意画面でのメールアドレス選択肢も3つ以上になるケースがあるので、メールアドレスの値そのものを POST することは理にかなっています。

問題は、POST されたメールアドレスが当該アカウントと紐づいてるかを Apple IdP サーバーがチェックしてなかったという点だけですね。

現在はメールアドレスとアカウントの紐付けがサーバーサイドでチェックされているので、変なメールアドレスを投げるとちゃんと 400 が返ってきます。

余談 : OAuth 2.0 WMRM 使われてる!

Sign in with Apple には Popup Mode なるものがあります。

実際以下の URL にアクセスして黒い方のボタンをクリックするとそれが体験できます。
http://signin-with-apple.herokuapp.com/?popup=true

ここ、よく見ると OAuth 2.0 Web Message Response Mode (WMRM, response_mode=web_message) が使われています。

大昔、@zigorou さんと @_nat さんとノリで Independent Draft まで書いて、その後放置してるやつですね。懐かしいですねぇ.. #遠い目

OAuth 2.0 Web Message Response Mode

Apple さんは redirect_uri に Origin 指定したりとかはしてないんですけどね。

OAuth WMRM、実は Auth0 とか Okta とかも使ってるんですよね。Okta のはなんか変な Prefix ついてるけど。

Comments