POODLEに関するFAQ

POODLEとは?

POODLEPadding Oracle On Downloaded Legacy Encryption)とは、SSLバージョン3.0(SSLv3)プロトコルに存在する脆弱性です。そのCBC暗号化スキームに問題があるために生じているものです。SSLSecure Sockets Layer)はインターネット上で通信セキュリティを提供するよう設計された暗号プロトコルです。SSLの大部分は、TLSTransport Layer Security)プロトコルに取って代わられましたが、それでもまだインターネットブラウザやアプリケーションでサポートされています。

どのようなデバイスが脆弱なのか?

SSLバージョン3.0(SSLv3)をサポートしているクライアントサイド アプリケーション、インターネットブラウザ、サーバーです。

この脆弱性は厳密にはどういうもの?

この脆弱性は主に、SSLv3における2つの欠陥によるものです。

  • SSLv3はランダムにパディングバイトを生成する

さらに

  • 復号後、メッセージの整合性チェックを行うために計算されているメッセージ認証コード(MAC)には、これらのパディングバイトが含まれない

つまり、見つかることなくこっそりと、そしてサーバー出力には何の変化ももたらすことなく、これらのパディングバイトを変えることが可能なのです。

つまりSSLv3には脆弱性がある。でもそれが攻撃にどう利用される?

ウェブサイトはしばしばセッションクッキーを利用し、特定のユーザーや、そのユーザーがウェブサイトにログインした後に作成された進行中のセッションの識別を行います。この特定のクッキーの値がわかれば、アタッカーはユーザーのアカウントの所有者になりすまし、ウェブサイトと通信を行うことができます。HTTPSとセッションクッキーを用いている一般的なウェブサイトは、 Gmail、Twitter、Facebookのほか、数多くあります。

簡単な攻撃シナリオを説明しましょう。まず、ネットワークを攻撃する際に中間者(Man in the Middle)攻撃を使って被害者のブラウザにJavascript を注入します。このJavascriptは対象の安全なHTTPウェブサイトに複数のリクエストを送信するように書かれたものです。各リクエストはそれぞれ、1バイトずつ異なる状態にします。各リクエストの後、そのウェブサイトはメッセージの復号を試みますが、たいていは失敗に終わります。しかし、256回の試み(1バイトの値で可能な組み合わせの数)のうち1回は、サーバーがメッセージの復号に成功し、セッションクッキーのその1バイトの部分を明らかにすることができるのです。セッションクッキーの残りのバイトに対してもこのプロセスを繰り返すことで、クッキー値全体を復号することが可能になります。

でも自分はTLSしか使わない!

たいていのTLSクライアントは「downgrade dance(ダウングレードして通信を行う)」機能を実装しています。クライアントとサーバーの間に安全な接続を確立する前に、ネゴシエーションフェーズあるいはdowngrade dance が起こります。ここでどちらにも互換性のある安全なプロトコルのバージョンが決定されます。一方が最新バージョンのプロトコルをサポートしていて、もう一方がサポートしていない場合、それよりも古いプロトコルなら両方がサポートしているかを確認するために、プロトコルのダウングレードが生じます。TLS接続を確立しようとする試みがすべて失敗に終わると、次に試されるプロトコルがSSLv3です。ダウングレードはこのように、どちらか一方が原因で起こるだけでなく、ネットワークの誤作動によっても引き起こすことが可能です。そのため、もしネットワークを支配しているアタッカーがサーバーとクライアント間のTLSプロトコルのハンドシェイクを妨害できれば、結局はSSLv3を使わざるを得ないという状況になります。

これは深刻な脆弱性ですか?

以下を考えると、深刻だと言えるでしょう。

  • すべての人気インターネットブラウザ(Google Chrome、Firefox、IE)がSSLv3をサポートしている

さらに

  • ほとんどのウェブサイト(アレクサのトップ100万HTTPSサイトの96.9%)がSSLv3をサポートしている

心配すべき?

攻撃(中間者攻撃)はアタッカーが被害者と同じネットワーク上にいて初めて機能するものであることを考えれば、攻撃の要件は今年見られたその他のバグよりも少々高いと言えるでしょう。お使いのアプリケーション/製品/ブラウザがSSLv3をサポートしていないのであれば、安全です。

安全を確保する方法を以下で紹介します。

どうしたら攻撃を防げる?

この種の攻撃を防ぐ方法は2つあります。

  • SSLv3のサポートを無効化する

あるいは

  • 接続を確立する際のプロトコルのダウングレードを止めるTLS_FALLBACK_SCSVのサポートを追加する。こうすることで、元々はTLS接続に対するリクエストだったものに対し、アタッカーがSSLバージョン3.0を無理やり使うことができなくなります。

こちらのページでは、さまざまなサーバー(Apache、Nginxなど)上でSSLv3を無効化する方法が紹介されています。こちらの記事では、 Google ChromeInternet Explorer上でどのようにSSLv3を無効化したらよいのか、詳細に解説されています。2014年11月25日にリリースが予定されているFirefox 34では、SSLv3はデフォルト設定で無効化されることとなっています。

フォーティネットの製品に関してですが、FortiGateFortiMailはデフォルトの構成では脆弱な状態ですが、SSLv3を無効化するCLI設定があります(詳細はFortiGuard Advisoryをご覧ください。この問題に関して適時更新しています)。

FortiGuardのIPSチームがSSLv3.POODLE.Information.Disclosureという名前で、この攻撃を検出するIPSシグネチャを構築しているところです。それまでの間、お使いの環境でSSLv3を完全にブロックしたい方は、以下のHTTPS用カスタムシグネチャを追加することも可能です。

F-SBID( --name "SSLv3.Server.Hello"; --protocol tcp; --flow from_server; --service SSL;
 --seq =,1,relative; --pattern "|16 03 00|"; --within 3,packet; ) 

これまでのところ、このソリューションで報告されている唯一の互換性の問題は、TLSに標準では対応していないInternet Explorer 6に関するもののみとなっています。

お役立ちリンク