HTTPS でも Full URL が漏れる?OAuth の Code も漏れるんじゃね??

Published on:
Tags:

なんですかこれは!

New attack bypasses HTTPS protection on Macs, Windows, and Linux

DHCP につなぐと PAC ファイルがダウンロードされて HTTPS であろうとアクセス先の Full URL は漏れるですって?

Web Proxy Autodiscovery ですって?

チョットニホンゴデオネガイシマス

ってことで、まぁこれが実際どれくらい簡単に実現できる攻撃パターンなのかは他のセキュリティ業界の方々に後で聞くとして、この記事でも触れられてる OpenID Connect とか OAuth2 への影響について、ちょっとまとめておきましょうか。

Authorization Request & Response が漏れる

response_mode=form_post なんていうのも一部ありますが、基本 OAuth2 / OpenID Connect の Authorization Request & Response は GET です。

Implicit Flow の場合は Response Parameter が URL Fragment についてるので、Server に送られる Full URL が漏れたところで特に URL Fragment の内容は漏れないですが、Code Flow の場合は Response の Query についてる Authorization Code は漏れますね。

まぁ Authorization Request に含まれる state とかも漏れますが、今回のケースだと Cookie とかは漏れないんで、state が漏れること自体は大して問題ではないでしょう。

ただ、Redirect URL に HTTPS 使っても code 漏れるってのは、辛そうですね。

Authorization Code が漏れたらどうなるの?

Code 置換攻撃 (Code Cut & Paste Attack) が可能になります。

ここに漏れた code があるとしましょう。すると、以下の手順で攻撃者は code 所有者の RP 上のアカウントにログインすることができます。

  1. 攻撃者自身のブラウザで Authorization Request 発行
  2. 攻撃者自身の IdP 上のアカウントで IdP にログイン
  3. Authorization Response を途中で止める
  4. Authorization Response 中に含まれる code を被害者のものに置換 (state は置換しない)
  5. Code 置換済の Authorization Response を RP に送る

こうすると、RP が state を使った CSRF 対策を行っていても、RP は受け取った code を使って攻撃者を被害者としてログインさせてしまいます。

これが Code 置換攻撃です。

では、これを防ぐ手立てはあるのでしょうか?

Read on →

NIST 800-63C を翻訳しました

Published on:
Tags:

先日このブログでも紹介した OAuth Revocation, JWK JWK Thumbprint 仕様の翻訳版 に引き続き、OpenID Foundation Japan 翻訳・教育 WG リーダーとしての Nov です。

先日 翻訳 WG の Facebook Page でも告知したように、現在 NIST SP 800-63-3 – Digital Authentication Guideline の翻訳を開始しています。

今日はその中から、すでに翻訳が完了している NIST SP 800-63C – Federation and Assertions のご紹介です。

Level of Assurance

プロフェッショナルなみなさまのことです、すでに Level of Assurance とか LoA とかいう単語を耳にしたこともおありでしょう。

NIST SP 800-63 は、LoA の各レベルでの要求事項を具体的に定めている NIST (米国国立標準技術研究所) の公式ドキュメントで、800-63-3 はその Revision 3 です。

Revison 3 では、Revision 2 まで単一のドキュメントだった 800-63 を、以下の4つに分割しています。

  • SP 800-63-3 (Digital Authentication Guideline)
  • SP 800-63A (Identity Proofing & Enrollment)
  • SP 800-63B (Authentication & Lifecycle Management)
  • SP 800-63C (Federation & Assertions)

そして LoA も3つの Assurance Levels に分割し、それぞれをレベル分けした上で、それぞれのレベルの組み合わせを持って LoA を定義しています。

  • Identity Assurance Level (IAL, Lv.1 – Lv.3 までの3段階)
  • Authenticator Assurance Level (AAL, Lv.1 – Lv.3 までの3段階)
  • Federation Assurance Level (FAL, Lv.1 – Lv.4 までの4段階)

LoA 自体は今まで通り Lv.1 – Lv.4 までの4段階で、それぞれの LoA に求められる IAL, AAL, FAL のレベルは以下の通りとなっています。

LOA IAL AAL FAL
1 1 1 1
2 2 2 or 3 2
3 2 2 or 3 2
4 3 3 4

LoA Lv.2.5 とか、Lv.1+ とか、謎のオレオレ定義が乱立してた LoA の定義も、こういう仕組みで多少はフィレキシブルに扱えるように…

ま、なるといいですね。

Federation Assurance Level (FAL)

で、上記のうち FAL を定義しているのが、NIST SP 800-63C – Federation and Assertions です。

800-63C では、Assertion と Federation Protocol のレベル分けのために、それらの特徴を複数のカテゴリに渡って分類し、それらの組み合わせによって FAL を定義しています。

FAL Requirement
1 Bearer assertion, direct presentation, asymmetrically signed by CSP
2 Bearer assertion, indirect presentation, asymmetrically signed by CSP
3 Bearer assertion, indirect presentation, asymmetrically signed by CSP and encrypted to RP
4 Holder of key assertion, indirect presentation, asymmetrically signed by CSP and encrypted to RP

Bearer か Holder-of-Key かとか、Direct か Indirect か (Artifact 使うか使わないか) とか、署名のみか署名後暗号化するかとか、プロフェッショナルなみなさまにはたまらないですよね!

ってことで、プロフェッショナルなみなさまにおかれましては、ぜひ翻訳版読んでいただいて、日本語版の GitHub Repository へのフィードバックお待ちしております!

あと NIST 本家の英語版も絶賛更新中らしいんで、英語語版の GitHub Repository にもフィードバックしてあげると喜ばれると思います!

僕も3箇所ほどフィードバックして見ましたが、特に報告者の国籍等は関係無く反応返ってくるので、どっかのパブコメよりはよっぽど…おっと、誰か来たようだ。

残りの 800-63-3, 800-63A, 800-63B について

絶賛翻訳中です。

NIST 800-63-3 シリーズはセクションごとにファイルが分割していて翻訳箇所の並列化がしやすくなってるので、翻訳手伝ってくれるひとはまだまだ募集してます。

応募方法は 翻訳 WG の Facebook Page をご覧ください。

じっくりドキュメントを読み込みたい方には、翻訳とかいい機会だと思いますよ!

Office 365 と外部 SAML IdP との連携設定

Published on:
Tags:

どうも、事務局長の Nov です。

どうも、ジムキョクチョのノブです。

どうも、ノブキョクチョです。

どうも、のぶチョです。

そう、のぶ千代です。

最近歳のせいか、Rails で SAML IdP とか作ってます。

今日は自作 SAML IdP を Office 365 と連携させてみたので、その格闘の記録を残しておきます。

Office 365 の制約とか Azure AD の制約とか全く前提知識なしに格闘した記録なんで、そういうのいいから手っ取り早くやり方教えろやって人は我らがふぁらおぅ兄さんのこちらの連載をご覧ください。

Read on →

OAuth Revocation と JWK を翻訳しました

Published on:
Tags:

どうも、この度 OpenID Foundation Japan の事務局長になった Nov です。

事務局長就任のご挨拶的なポエムを書けというオーラをふつふつと感じながら、ガン無視してこの記事を書いております。

さて、みなさん覚えておられるでしょうか?

OpenID Foundation Japan 翻訳 Working Group のことを。

僕が OpenID のエバンジェリストになる前からリーダーをしており、古くは 2010 年に今は亡き OpenID 2.0 の仕様を翻訳していた、あの伝説の WG を。

その伝説の WG が、2年超の休眠期間を終えて、ついに復活します!

復活第一弾は、OAuth Revocation と JWK!

え、この2つにどういう関連性があるのかって?

特にないです!

JWK 翻訳しようとしたら、途中まで翻訳されて休眠してた OAuth Revocation の存在を思い出しただけです!

Read on →

Office 365 SAML Implementation Vulnerability

Published on:
Tags:

先日 Office 365 のこんな記事見つけたので、一応まとめておきますかね。

The road to hell is paved with SAML Assertions

タイトルだけ見るとまた SAML is DEAD 案件かと思いきや、Office 365 の脆弱性の話です。

SAML 悪く無いです。

SAML isn’t vulnerable, just DEAD.

SAML SP としての Office 365

Office 365 は SAML Service Provider (SP) として動作するので、みなさんがお持ちの Identity Provider (IdP) を SAML IdP として動作することができれば、みなさんの IdP に登録されてるアカウントを使って Office 365 にログインすることができます。

みなさんの社内の ADFS とか、Ping Federate / Okta / OneLogin … みたいな IDaaS とか、そういうのは大抵 SAML IdP として動作するので、そういう製品を使ってるなら、みなさんの会社のアカウントでそのまま Office 365 にログインできます。

通常 SAML SP は、IdP から返ってくる SAML Response に含まれる IdP 側のユーザー識別子 (Subject Identifier) と IdP 自身の識別子 (Issuer Identifier) のペアを元に、SP 側のアカウントにログインさせます。

がしかし、Office 365 の場合は、IdP が渡してくる Email アドレスと Office 365 がローカルで持ってる Email アドレスの一致だけを見て Office 365 ローカルのユーザーを認証していたようです。Subject Identifier も Issuer Identifier も無視していた、と。

(実際には、SAML IdP と Office 365 の間に Azure AD が介在しており、SAML Assertion の検証は Azure ADがやるようなアーキテクチャになっていて、Azure AD では Subject Identifier & Issuer Identifier をちゃんと見ているようですが、全体として見ると Office 365 が SAML IdP の Issuer と Subject をガン無視した形になってます。この辺の話しだすとややこしい割に MS 以外の人にはあまり関係無い話になっちゃうので、今回はスルー)

Office 365 の脆弱性概要

これで何が起こっていたかというと、nov@victim.example.com という Email アドレスを持つ Office 365 ユーザーのアカウントにログインする際に、attacker.example.com という IdP が nov@victim.example.com という Email アドレスを含んだ SAML Assertion を発行すると、Office 365 がその Assertion を受け入れて nov@victim.example.com の Office 365 アカウントへのログインを許可してしまっていました。

よって、以下の2つのパターンが、どちらも同じ Office 365 アカウントにログイン可能になっていました。

Issuer Identifier Subject Identifier Email Address
attacker.example.com 58df3c9b2c32ca86f.. nov@victim.example.com
victim.example.com 20166f0c077c1f6c1.. nov@victim.example.com

うん、これは最悪ですね。

Read on →