SAMLライブラリに脆弱性が見つかり、シングルサインオンの過程で異なるユーザになりすますことが可能なことがわかった。なかなか衝撃的だったので整理してみたい。
なお、自分の整理なのでテンポよく簡潔な言葉でまとめることを心掛ける。それゆえ正確ではないかもしれない。間違いもあるだろう。
このブログをこれから読もうという奇特な方は注意いただきたい。
- まずSAMLとはなにか
以前も載せたアイデンティティ管理におけるレイヤー図だが
SAMLはこの「フェデレーション」と「SSO」の実装である。
フェデレーションとはネットワークドメインをまたいだアイデンティティの連携である。SSOはシングルサインオンで、1度誰かに認証してもらったという情報を引き回して何度もユーザがサインオン行為をしなくてよくすることだ。なんか似てるがちょっと違う。
SAMLはもともと企業のM&Aにより異なるシステム間で認証を統一するためにできたのが始まりと聞いたことがある。よって最初は企業ネットワーク内のアイデンティティ連携のための規格だったが、パブリッククラウドが台頭し、その認証連携にも活用できるため利用拡大し次第にネットワークドメインをまたいだアイデンティティ連携での利用が主流となった。
なお現在フェデレーションプロトコルの主流といえばOpenIDConnectだ。こちらはコンシューマ向けサービスでもともと利用されていたOpenIDという認証機能にOAuthの認可機能を取り入れエンタープライズで活用できるようになったものだ。
発展の経緯は違うものの機能的にはSAMLと似たような感じだ。だがOpenIDConnectは軽い。SAMLが一回のパケットに認証情報も属性情報もいろいろどっさり持ち込むのに対し、OpenIDConnectは最初のやりとりは最小限の認証情報だけ。属性情報が欲しければ再度要求するというフローになっている。トラフィックの問題でSAMLからOpenIDConnectに乗り換えた事例を聞いたことがある。
IdentityProviderは例えば社内イントラ内にあるADやLDAPサーバだ。ユーザが例えばSalesForceみたいなクラウドサービス（SP）を使いたいとき、わざわざ社員情報を登録するのは面倒だし管理が一元化できない。自社FWの外に社員情報を置くことにまだ抵抗もあるかもしれない。当然社内にすでにあるADやLDAPの情報を使いたい。
そこで利用したいクラウドサービスがSAMLフェデレーションに対応していれば、上記のフローで実際の認証はIdPが実施し、SPは「認証OKだったよ」という情報とそのユーザの属性情報だけもらい、以降の処理をする。
大元はDuo SecurityのKelby Ludwigさんが報告したらしい。
duo.com
英語のサイトなのでなんとなくわかるようでわからない。
こちらの富士榮さんのブログがめちゃくちゃわかりやすい。
idmlab.eidentity.jp
簡単に言うと、SAMLの応答（上のフローでいくと⑤の時）のNameIDというメルアドとか社員番号とかのユーザIDが入ってくる項目にコメントが埋め込まれると、コメントの後ろが無視されてしまうというのが今回の問題です。
これを悪用すると
(a) user@user.com<!-- コメント -->.evil.jp というユーザIDでIdPの認証を受ける（フロー図の④）
(b) IdPからSPにNameIDにuser@user.com<!-- コメント -->.evil.jpが入ったパケットがSAMLレスポンスとしていく（フロー図の⑤）
(c) SPはuser@user.com.evil.jpで正規化～署名検証までした後でuser@user.comとしてログインしてしまう
＝NameIDを詐称し他人で入れてしまうということです。
つまりSAMLのSP側の実装の不具合ということになります。
- 影響があったサービス
SAMLを使っていると全部影響があるということではなく、上記不具合が包含されたライブラリを使ってSAML SPを実装しているサービスに影響があります。
ここが情報豊富だった
www.kb.cert.org
以下のライブラリに不具合のある実装が包含されているようです。
| ライブラリ | 脆弱性番号 | GitHub/製品ページ | |
|---|---|---|---|
| OneLogin | python-saml | CVE-2017-11427 | https://github.com/onelogin/python-saml |
| 〃 | ruby-saml | CVE-2017-11428 | https://github.com/onelogin/ruby-saml |
| Clever | saml2-js | CVE-2017-11429 | https://github.com/Clever/saml2 |
| OmniAuth | SAML | CVE-2017-11430 | https://github.com/omniauth/omniauth-saml |
| Shibboleth |
openSAML C ++ |
CVE-2018-0489 | https://shibboleth.net/downloads/c++-opensaml/2.6.1/ |
| Duo Network Gateway | CVE-2018-7340 | ? |
各SAML製品またはベンダで影響なしと確認できているものは以下。
| AssureBridge | 影響なし |
| Box | 影響なし |
| CA Technologies | 影響なし |
| Cisco | 影響なし |
| ComponentSpace Pty Ltd | 影響なし |
| Entr'ouvert | 影響なし |
| ForgeRock | 影響なし |
| GitHub | 影響なし |
| 影響なし | |
| Microsoft（AAD、ADFS） | 影響なし |
| Okta Inc. | 影響なし |
| Ping Identity | 影響なし |
| Pivotal Software,Inc. | 影響なし |
| VMware | 影響なし |
| OpenAM | 影響なし |
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=475445&SearchOrder=4
SAMLライブラリ の脆弱性(JVNVU#98536678)について [AM20180306-1] - Open Source Solution Technology Corporation
- 所感
思ったより簡単な操作でできてしまうんだな、、と恐怖を感じました。
対象製品を利用している方は対策済みバージョンへアップデートをちゃんとしたほうがいいですね。
ちなみに本当に成功するのか試してみたい気持ちに少しだけなりましたが実際のサービスで意図的に詐称するとおそらく不正アクセス禁止法違反の「他人の識別符号（パスワード、生体認証）他を使ってアクセス制限を突破してはならない。」に該当しますよね(-_-;)
更新履歴：
2018/3/9 新規作成
2018/3/9 表がスマホでは見えなかったため、違う作り方にしました
