去る7月1日に次のような記事が流れてきました。
ただ、この記事からだけだと、結局どういう脆弱性なのかわかりませんし、Palo Alto Networks のサイトの当該ページに行っても同様です。ここのところ忙しくてなかなか手が回らなかったのですが、今日土曜日は仕事をしないと決めていたのでちょっと調べてみました。といっても、他の文献をあたっただけですが。
その中で詳しくて良いと思ったのが、tenableの解説です。
攻撃成功の前提条件
それによると、この攻撃が成功するためには次の２つの前提条件があります。
- SAML認証をおこなっていること。
- IdPの証明書の検証を行わない設定になっていること。
「IdPの証明書の検証を行わないなってことあるの？」と思われるかも知れませんが、これはかなり普通のことです。自己署名証明書を使う場合がこれで、いわばRaw Keyを使っている状態ということになります。上記の記事によると、実際に以下の製品ではこの設定を推奨しているようです。
- Okta [Image]
- SecureAuth [Image]
- SafeNet Trusted Access [Image]
- Duo [Image]
- Trusona via Azure AD [Image]
- Azure AD [Image]
- Centrify [Image]
メジャーどころ勢揃いですね。そして、セキュリティ的にはこれで問題ありません。
何が起きているのか？
さて、では、お待ちかねのセキュリティホールの内容です。(図１)の設定で省略されるのは、IdPが署名に使う証明書のCertificate ChainとRevocationのチェックを省略するだけのはずですよね？ところが、実際には、SAML Assertionに対するIdPの署名の検証まで省略してしまっていたようなのです。すべてのSAML Assertionへの署名の検証が省略されるのか、ある特定の条件のときなのかはわかりませんが、その条件にあたれば、管理者の権限まで取られてしまうことは確かなようです。なので、重大性MAXの脆弱性〜VPNで守っているつもりでもまったく守られていない状態〜にあたるわけですね。
ITメディアの記事を最初に読んだときには「署名検証の不備」と書かれていたので、またXML署名におけるXML正規化由来の署名バイパスかと思って、
と書いたのですが、どうやらそうではなくて、「PKIは人類には早すぎた」問題だったようです。
対策
対策は２種類あります。
- PaloAltoネットワークが出したパッチを当てる。
- すぐにパッチが当てられないならば、IdPの使う証明書を自己署名ではなくCAが発行したものに変え、IdPの証明書の検証を行うようにすること。
です。まだ、実際の攻撃はされていないようですが、可及的速やかに対策する必要がありますのでご注意ください。