OAuth.jp

先週末に 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 に遷移
   • AuthZ EP: https://appleid.apple.com/auth/authorize
3. ログイン後、初回連携時にのみ出てくる同意画面 (メアド選択するところ) に到達
   • 
4. ここで「続ける」を押すと内部的に Ajax Call が実行される
   • Ajax API EP: https://appleid.apple.com/appleauth/auth/oauth/authorize
   • 選択されたメアドやその他の AuthZ Req Params が一通り JSON で POST される
   • レスポンスとしては id_token とか code なんかが含まれた JSON が返ってくる
   • 

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

OAuth 2.1 で PKCE 必須にするしない議論が盛り上がっておりますが、今日そのスレで新しい攻撃パターンが議題に上がりました。
https://mailarchive.ietf.org/arch/msg/oauth/HZt851AobQlJMBVd6_p8iWSyRS8/

今のところ “Nonce/PKCE Sidestep Attack (仮” と名付けられたこの攻撃は、以下のようなシナリオで成立します。

Nonce/PKCE Sidestep Attack (仮

[前提条件]

ある Client に、アプリケーションコンテキストによって PKCE を使うコンテキストと Nonce を使うコンテキストが共存している。

[攻撃シナリオ]

以下、原文 を要約。

1. 攻撃者は何らかの手段により Nonce に紐づいた (= PKCE code_challenge とは紐づいていない) 被害者の Code を詐取する。
2. 攻撃者は PKCE を使うコンテキストにおいて自らのブラウザで Client に Authorization Request を実行させ、code_challenge だけを抜き去ったものを Authorization Server に送る。
3. 攻撃者は受け取った Authorization Response 中の Code を Step.1 で取得した Code と差し替え Client に提示する。
4. Client は受け取った Code を Step.2 で生成した code_challenge に紐づいた code_verifier を付与して Token Request を実行する。
5. Authorization Server は code_challenge と紐づいていない Code を受け取ったので code_verifier は無視して Token Response を返す。
6. Client は Nonce を使うコンテキストでもないので Nonce のチェックも行わず、code_verifier が無視されたことも検知できないので成功裏に Token Response を受け取ってしまう。

以上により Code 置換攻撃が成立する。

約一年ぶりの記事ですね。
みなさん、三密避けて OAuth の勉強に勤しんでおられますでしょうか？
さて、今朝こんな記事が上がってました。

「Microsoft Teams」にアカウント乗っ取りの脆弱性、画像表示だけで不正侵入 – ITmedia エンタープライズ

今回の脆弱性は Teams のデスクトップ版と Web ブラウザ版の両方に影響する。攻撃者は狙った相手に GIF などの画像を送り付けて表示させ、画像が Web ブラウザに読み込まれる過程で認証トークンを盗み出す。被害者の画面には画像が表示されるだけなので、自分が攻撃されたことに気付かない。

攻撃者がこのユーザーになりすまして組織内の他の従業員に不正なGIFを送信すれば、ワームのような形で侵入を広げ、組織全体の Teams アカウントを乗っ取る可能性もある。そうなれば、社外秘情報や会議、カレンダー、パスワードといった重要情報が流出しかねない。

GIF 画像貼り付けるだけで Teams アカウント乗っ取れるとか、こんなの読んだら恐ろしくて Teams なんて使えないですね。

この脆弱性が報告されたのが2020年3月20日ということなんですが、Teams の中の人はどんな気持ちで以下の記事を読んでいたのでしょうか。

マイクロソフト、「Teams」のセキュリティをアピール—「Zoom」に批判集まる中 – ZDNet Japan

で、ここから本題、今回の Teams の脆弱性の詳細についてです。英語ですが、こちらの記事に詳細が載ってます。

Beware of the GIF: Account Takeover Vulnerability in Microsoft Teams | CyberArk

Sign in With Apple の特徴分析 (1) のつづき。

文章でつらつら書いても結局わかりづらいもんはわかりづらいんで、もう箇条書きで淡々と。

これだけそろってれば、あと最後の 要調査 ってとこを各自必要に応じて調べるなり、誰かがこの記事にコメントしてくれるなりすれば、一通りみなさんのサービスの設計に落とせるんでは無いかと思います。

※ 落とせない人は 僕 (= YAuth.jp 合同会社) に仕事を依頼する という手もありますw

前記事 で書いたように、ここ数日 Sign in with Apple 用の RubyGem 作りながら、Sign in with Apple の特徴というか、他の IdP との違いみたいなところいろいろ調査したので、現時点での Sign in with Apple に対する雑感をまとめておきます。

Client ID と Team ID および App ID との関係

個人として Apple Developer Account 使ったことしかないんで、会社として Developer 登録してる時の Team の扱いとかよくわかってないんですが、Apple Developer Account 登録すると Team ID ってのが割り振られます。個人だと 1 Developer Account に 1 Team ID。

この1つの Team ID の下に、複数の子 App ID が登録可能です。1 iOS App についき 1 App ID。

さらに、App ID には “Primary” という概念もあり、1つの Primary App ID の下に複数の App ID を登録することができます。

ここまでは、お仕事で実際に iOS App 作ってる人たちにはきっと当たり前な話なんだと思います。

そして、Primary App ID の下に App ID の代わりに Service ID っていうのが登録できます。

Service ID っての設定画面には Sign in with Apple 関連の設定項目しかないから、これは今回初めて出てきたものなのかもしれませんね。

で、iOS App で Sign in with Apple 使う場合は App ID というのが OAuth Client に該当し、Web とか Android とかで Sign in with Apple 使う時は、 Service ID というのが OAuth Client に該当するようです。

1 Team ID の下に複数 App ID が登録され、1 App ID の下に複数の子 App ID と Service ID が登録され、iOS/Mac Native の世界では App ID が、それ以外では Service ID が OAuth Client となる。

ここまではいいですね？いや、正直間違ってるかもしれんけどw

そして、Client の鍵 (Client Secret を生成する為の秘密鍵、詳しくは後述) を別途生成するのですが、この鍵は Primary App ID 毎に登録することになります。

鍵は Key Rotation のことも考慮してか、1 Primary App ID に複数同時に登録できます。

ただ、1 OAuth Client に 1 Private Key、という単位ではないので、鍵管理のやり方は普通の OAuth Client の場合と異なるやり方が必要になる Developer さんもいるかもしれませんね。