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 →

OAuth / Connect における CSRF Attack の新パターン

Published on:
Tags:

昨日こんなのが OAuth ML に流れてました。

[OAUTH-WG] Another CSRF attack

前提条件

RP (Relying Party a.k.a. OAuth Client) が2つ以上の IdP (Identity Provider a.k.a. OAuth Server) と連携している状況で、片方の IdP に悪意がある。

  • 悪意ある IdP = AIdP (A は Attacker の略)
  • その他の IdP = HIdP (H は Honest の略)

攻撃フロー

Another CSRF Attack

  1. Victim が AIdP を使って RP へのログインを試みる。
  2. RP は Authorization Request を AIdP に送る。
    • AuthZ Req には Browser Session と紐付いた state パラメータをつけている。
  3. AIdP は Victim を認証し、必要に応じて同意を取得する (ふりをする)
    • 同時に AIdP は裏で HIdP から code を取得する。
    • HIdP の code は Attacker の HIdP 上のアカウントに紐付いているもの。
  4. AIdP は HIdP から取得した code を、RP の HIdP 用 redirect_uri に返す。
    • この時 Step2 で RP が発行した state を付与する。
  5. RP は Browser Session と紐付いた state を検証した上で code を HIdP の Token Endpoint に送る。
  6. HIdP は Attacker のアカウントに紐付いた access_token を返す。
  7. RP は Victim をログインさせる。
    • ここで HIdP 上の Attacker アカウントと RP 上の Victim アカウントが紐づけられる。

そして、Attacker は任意のタイミングで自身の HIdP 上のアカウントを使って、RP 上の Victim のアカウントにログインできる。

防御策

state をリクエスト先の IdP とも紐づけましょう。

FB Message API Callback as an Azure Function

Published on:
Tags:

今日は Azure Function で FB Message API Callback を作ってみます。

Azure Function は、Azure Portal の Marketplace で “Function App” って検索すると出てきますね。

Azure Function in Marketplace

Function App の Deploy がおわったら、QuickStart から “Webhook + API” を選びましょう。

Azure Function QuickStart

以下の様な Node.js のテンプレートアプリが出来上がります。

Azure Function Template

まずは FB Message の WebHook としてこの Function を登録します。

Read on →