こんにちは、富士榮です。
#コメント部分が本ポストの中でもコメントとして扱われて消えてしまっていたので修正しました。tkudoさんご指摘あざーす
＃その他、もろもろ修正しました。酔っぱらって夜中に斜め読みしたらダメですねｗ
DuoがSAMLの実装に関する脆弱性に関する
レポートをしています。
ZDNetの日本語版記事
https://japan.zdnet.com/article/35115353/
＃しかし、中身は「SAMLプロトコルの」脆弱性じゃなくて、SP実装の不具合なので、「プロトコルの脆弱性」は言い過ぎだなぁ、、と思います。
例によって記事になると何のことかさっぱりわからないので、元ネタとなるDuoのレポートを読んでみました。
（実際に実験は出来ていないので、また時間があれば試してみたいと思います）
Duoのレポート
Duo Finds SAML Vulnerabilities Affecting Multiple Implementations
https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations
＃Oktaのブログもわかりやすいです。
A Breakdown of the New SAML Authentication Bypass Vulnerability
https://developer.okta.com/blog/2018/02/27/a-breakdown-of-the-new-saml-authentication-bypass-vulnerability
簡単にまとめるとポイントは、以下の通りです。
- 外部IdPへの認証要求への返答として帰ってきたSAML ResponseのNameIDにコメントが含まれていると、正規化～署名検証時をした後、コメント部分より前の部分しかNameIDとして扱われず、別のユーザになりすますことが出来てしまう
- 影響を受けるのは以下の製品・サービス
- OneLogin
- Clever
- OmniAuth-SAML
- Shibboleth
- Duo Network Gateway
- 原因はSAML ResponseのNameIDの値の間にコメント（<!-- コメント -->）が存在した場合に、コメントの後ろの値を無視してしまうため（例：hoge@example.jpとhoge@example.jp<!-- コメント -->.evil.jpが同じNameIDとして扱われてしまう）
- 対応方法は対策済みバージョンへアップグレードすること
要するに、こんな感じです。
通常はSAML ResponseをSPが受け取る動きは以下の通りです。
今回指摘された正規化～検証後の値の取り扱いに関するバグがあるとこうなります。
NameIDがメールアドレス形式の場合はSP側で別のユーザになりすますのは難しいとは思いますが、NameIDが社員番号などの番号だった場合は割と容易になりすますことが出来そうです。
例えば、
攻撃者が「123<!-- コメント -->456」
というユーザでIdPで認証すると
SPがSAML ReponseのNameIDを「123」として扱ってしまう（コメントより後ろの「456」を正しく連結してくれない）ので、
「123」という全く別のユーザとしてSPへアクセスできてしまうことになります。
まずは皆さんがお使いのSAML SP（もしくは外部IdPと連携しているSAML IdP）が本件に該当するかどうか、対応版がリリースされているかどうかを確認して対策を進めてください。
投稿
