技術者ブログ

はじめに

この記事をお届けできることを非常にうれしく思います。タイトルは「ScutumはPOODLE攻撃を検知・防御する唯一のWAFです」となっていますが、実は末尾に「(ｷﾘｯ」が抜けているイメージです。

2015年1月26日より、クラウド型WAFのScutum(スキュータム)において、SSLv3を従来通り(AES/3DES/RC4)に使いつつ、POODLE攻撃を検知・防御できるようになりました。本エントリでは、その内容について説明をおこないます。

SSLv3を一律に無効にするのがデファクトスタンダードなPOODLE対策

POODLEはHeartbleedとならび、去年の「SSL/TLS脆弱性祭り」を彩った主役のひとりです。その対策として挙げられたのは、基本的には「SSLv3を無効にする」というものでした。

単なるウェブサーバであればともかく、WAFのようなセキュリティベンダーが開発するテクノロジーにおいてもこの点については横並びでした。筆者が調べた感じでは、各社のWAF等においても例外なく「SSLv3を無効にする」という対処が、特に疑問も呈さずに一律で適用されたように見えます。

筆者が「あれ？」と思ったのは、POODLE攻撃を積極的に検知して、止めようという流れがまったく見られなかったことです。SSLv3はやや古いシステムではまだまだ現役で使われているので、「はい、では今日からSSLv3は使えません」としてしまうと、実案件としては困る場面が多々あると思われます。POODLEの脆弱性を発見・報告したGoogleのように最先端を行き、かつ自社でブラウザも開発している会社の人からは、毎日業務をWindowsXPのIE6でこなしている人の姿は見えないのです（それが良いか悪いかはさておき）。

いずれにせよ、SSLv3をまるごと無効にしてしまうというのはやりすぎというか、「対策」というよりはサービス提供側の「仕様変更」に近いように感じました。

POODLEを検知・防御する

もっと良い方法はないのでしょうか。筆者が以前のエントリに書いたように、POODLE攻撃は大量のプロトコルエラーを発生させる等の特徴があるので、高い確率で検知できます。該当エントリでは書きませんでしたが、プロトコルエラーの他にも、攻撃者は暗号化されたデータブロックを複製し、通信の最後にそれを送ってくる（つまりブロックの重複が見られる）という特徴もあります。

POODLEでCookieに格納されているセッションIDのような意味のあるデータを取得するためには数千回のアクセスが行われるので、確率的には十分確実に検知できると考えられるというのが筆者の意見です(どの程度の確率なら許容できるのかという考え方は保護対象のウェブアプリケーションのリスク分析などが必要、つまりケースバイケースですが）。

ScutumではSSLv3の通信について、パディング処理のエラーに注目します。そして確率的な考え方に基づいて、ある閾値を超えた場合に「POODLE攻撃だ」と判断します。そしてその後は該当IPアドレスからのSSLv3での通信を拒否するという挙動を行うようになりました。

このようにSSLv3の通信の中からPOODLE攻撃のみを検知してブロックすることが可能になったため、これまでScutumではSSLv3の場合にはRC4のみが暗号スイートとして使用可能でしたが、現在はAES及び3DESも使えるようになっています。つまり、従来どおり、何も変更することなく、SSLv3を使い続けることができます。

これはもちろん「古いIE6を使い続けよう！」と言っているわけではありません。IE6を使い続けるかどうかはお客様の判断であり、私が口出しすることではありません。また、IE6以外にも、例えば独自のクライアントアプリケーションなどがSSLv3を使って開発されたが、メンテナがいない場面なども考えられます。単に、何かしらの理由があって今までSSLv3を使い続けている環境において、POODLEの影響を排除できるようになった、ということです。

ScutumではSSLv3は常に有効なのか？

ScutumではSSLv3やRC4を使用することができますが、「私のサイトでは古いブラウザは使われないので、SSLv3はまるごと無効にして問題ない」のような場合や、「RC4は現在では既にセキュアでないと考えるので、無効にしたい」等の場合には、Scutumの管理画面からSSLv3やRC4をそれぞれ個別に無効にすることができます。この場合はTLS+AES等が標準的に使用される形となります。

POODLE攻撃って本当に来るの？

筆者が今回いろいろと研究し、実際にPOODLE攻撃を防御・検知する機能を開発した動機は、実は大きく2つあります。ひとつは上記のように「これまで通りSSLv3を使えるのが、スマートな解決方法だ」ということ。そしてもうひとつは、「POODLE攻撃なんて本当は来ないんじゃないのか」という考えを実証したい、というものです。

POODLEはわざわざMITMを行い、かつターゲット(被害者)のブラウザにコードを送り込み、それをMITMする側のコンピュータと連動させながら制御する必要があります。かなり難易度が高く、かつ面倒な攻撃です。これを行うには技術レベルの高い攻撃者が、それなりのモチベーションを持って行う必要があります。またMITMできるのは一般的にはネットカフェ等のWifi接続などであり、場面を選びます(NSAのような国家レベルの組織が行うケースは例外ですが)。しかも取得できるのはせいぜいセッションIDやBasic認証のアカウントなどです。

GoogleやFacebook、twitterのような超大規模ウェブサイトであればともかく、Scutumのお客様の大半を占めるような、一般的な企業のウェブアプリケーションがPOODLEで攻撃される確率はほとんどゼロだろうと思います。今回POODLE攻撃を検知できるようにしたことで、この疑問について実際に調査できるようになりました。果たして本当にPOODLE攻撃はおこなわれるのかどうか、これから長い目で見守っていきたいと思います。

まとめ

POODLEに対して、他社のWAFは（筆者にいわせれば）手抜きの対策で、単にSSLv3を無効にしただけですが、我々のScutumではSSLv3を活かしつつPOODLEのみを効果的に検知・防御できるようになりました。POODLEは面倒な攻撃なので、現実的には、深刻な被害に繋がるケースは殆どないだろうと思います。本エントリに対するご意見などはお気軽に@kinyukaまでお寄せください。

最後に、POODLEについてのわかりやすい記事を書いてくださったDeNAのはるぷさんにあらためてお礼申し上げますm(_ _)m