OAuth.jp

いままで Mix-up Attack は Client が AS 毎に redirect_uri を使い分けていれば防げると信じられてきましたが、それじゃ防げないケースもあるよってのが OAuth ML に投稿されました。

細かい解説は英語読んでもらうとして、シーケンスにするとこういうことです。

Attacker AS が (Display Name やロゴ等を通じて) 一見 Honest Client に見えるような Client (Attacker Client) を Honest AS に登録しておく必要があります。

User が Attacker AS 選んでるのに Honest AS に飛んで Approve してしまってる部分も、Attacker Proxy が利用可能な状況 (e.g., Client が HTTP なエンドポイントで Honest AS のログインボタン等を表示している) であればもっと違和感のないフローになるでしょう。

で、解決策として AuthZ Response に “iss” を含めることが提案されているのですが、「悪意のある可能性があるIdPを採用しない」ってのが一番の解決策であることに代わりはありません。

忘れそうなので一旦メモ。

ドコモ口座の問題って、こういうことでしょ？

1. 銀行側のAALが1を満たさないので銀行側が銀行口座を保護できない
2. 銀行側のAALが1を満たさないので「銀行にKYCを依拠する」というサービスのLoAが1を満たさずサービスとして成り立っていない
   • 結果としてドコモ口座のIALは1 (= dアカウント登録直後と同等) のまま
3. 「銀行口座名義とドコモ口座名義の一致確認」と「銀行にKYCを依拠」が同時に発生してしまっている結果「銀行口座名義とドコモ口座名義の一致確認」が実質なされていない
   • 参考) https://gist.github.com/nov/b8be7b50db48862784b470c1ae6c1718
4. 口座の一致確認が行われていないためドコモも銀行口座を保護できない
   • ドコモ口座側のAALは1を満たすのでドコモがドコモ口座を保護することは可能
5. 結果として銀行口座は保護されない

そして、責任分界点はこのあたりで、

• 銀行預金に対する金銭被害の責任は銀行に帰し
• その預金が反社に渡る責任はドコモに帰する

eKYC文脈ではこのあたりが論点で、

• 上記2をサービスとして成り立たせるためのAAL, FAL要件に関する合意
• 上記2がサービスとして成り立ったとしても上記3が実質なされていないことには代わりがないので、それを良しとするのかどうか

金融文脈ではこの辺りが論点になるのかなと。

• 銀行側のAALが1を満たさない場合でも規約上の免責事項に該当することを良しとするか
• 銀行側のAALが1を満たさない場合でも「送金先による口座名義確認とセットでは結果として銀行口座が保護される」ことを良しとするか

先週末に 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