POODLE攻撃

POODLE攻撃とは？

CVE-2014-3566として知られる脆弱性、またはPOODLE攻撃CVEは、SSLという安全な接続下で暗号化されたCookie、パスワード、その他のアプリ情報などの機密データを奪取するために利用されます。

アメリカのコンピュータ緊急対応チーム（US-CERT）は、2014年10月にウェブトラフィック取得に用いられる暗号技術の欠陥について警告を発しました。その結果、クライアントとサーバ間の通信において、攻撃者はPOODLE（Padding Oracle On Downgraded Legacy Encryption）の脆弱性を利用して暗号文を解読できるようになりました。

POODLE攻撃は、ウェブ上のデータ暗号化と認証に用いられるTransport Layer Security（TLS）プロトコル、SSL 3.0およびSSL 2.0といった規格に対して有効です。SSLをサポートするアプリも存在しますが、業界ではより新しく安全なTLS接続へと移行が進んでいます。TLSが利用できない場合、攻撃者はPOODLE攻撃を仕掛け、相手の接続を妨害して一部のアプリにSSL 3.0への切替を促します。

POODLE攻撃の仕組み

中間者（MiTM）攻撃者は、POODLE脆弱性により安全と信じられていた通信を傍受できます。これにより、攻撃者はクライアントの機密情報を盗み出したり、場合によってはクライアントになりすましたりする可能性があります。

POODLE攻撃を成功させるためには、以下の三段階を確実に実行する必要があります:

• 効果的なMiTM攻撃により、攻撃者は被害者の機密情報に下層からアクセスできる。MiTM攻撃では、攻撃者が通信している双方の間に密かに割り入り、メッセージを傍受・中継する。被害者は直接安全な接続で通信していると信じています。
• 次に、攻撃者はサーバにSSL 3.0プロトコルを利用させる。この際、TLS 1.2などの最新プロトコルが使えない場合、MiTM攻撃で接続を何度も切断し、クライアントが古いプロトコルに切り替えるよう仕向ける。これがダウングレード攻撃と呼ばれる段階である。
• サーバがSSL 3.0に切り替わると、攻撃者はPOODLEを用いて暗号ブロックを解読し、情報を抽出する。これにより、復号後の平文からデータを入手し、被害者のセッションを乗っ取ることが可能となる。

パディングとパディングオラクルとは？

ブロック暗号では、全てのデータがブロックサイズの倍数でなければなりません。例えば、ブロックサイズが8の場合、データは64、80、または336バイトなど、8の倍数である必要があります。倍数でない場合、適切な長さにするために不要な情報でパディングされます。

ほとんどのウェブサーバが用いるパディングの方法は以下の通りです:

• パディングの長さは常に最終ブロックの最後のバイトに含める。前のバイトに含まれるパディング量はこの値で示される。例えば、4バイトのパディングならブロックは xx-xx-xx-yy-yy-yy-yy-04 となる（yyはパディングを意味し、これはSSLの要件である）。
• 実装によっては、全てのパディングバイトの値がパディング長と同じになる。例えば、8バイト中4バイトがパディングの場合、ブロックは xx-xx-xx-04-04-04-04 となる。
• データの長さがブロックサイズとちょうど等しい場合、余分なパディングのみのブロックを追加する必要がある。例えば、この場合は 07-07-07-07-07-07-07 となる。もし最後のバイトがパディングを示していなければ、アルゴリズムはパディングと実際のデータを区別できない。
• つまり、SSLでは（パディング長以外の）パディングバイトは検証されないため、最後のバイトが00から07の範囲であればブロックは受け入れられる。例えば、xx-xx-xx-12-34-56-78-04というブロックも有効である。

パディングオラクルを利用すると、攻撃者はサーバに送信したデータがパディング不正かMAC不正かにより拒否されたかを判定できます。

次のシナリオを考えてみてください:

1. ブラウザからのデータを攻撃者が受け取り、その中にパスワードが含まれていることを把握する。また、このリクエストがHTTP POSTであり、パスワードの位置が明確であることも認識している。
2. 攻撃者は、暗号化されたデータをサーバに送信する前に、データを改変する。
3. その結果、サーバはデータが不正であることを攻撃者に通知する。ただし、返答はパディングの誤りかMACの誤りのどちらかで示され、これがPOODLE攻撃を可能にする。
4. 他の攻撃手法でもパディングオラクルが利用される。あるプロトコルでは、即時の返答は行わず、先にパディングを確認してからMACを検証する場合もあり、状況によっては、即時の返答がパディングエラー、遅延した返答がMACエラーを示すこともある。

‍

一般的なPOODLE攻撃の実行

以下に、攻撃者が標準的なPOODLE攻撃を実行してウェブセッションクッキーを奪取する手順を示す:

1. 被害者のアプリにJavaScriptコードを実行させることで、攻撃が開始される。
2. 攻撃者のJavaScriptコードにより、クライアントアプリはサーバへ複数の認証付きリクエストを送信する。これらのリクエストにはセッションクッキーが必須である。
3. サーバに送信されるデータがブロックサイズの倍数となるよう、JavaScriptコードはURLに余計な文字（例：8文字）を追加し、最後のブロックがパディングのみで構成されるように調整する。
4. 攻撃者は、セッションクッキーがどのブロックに含まれているかを把握している。例えば、全体が10ブロックの場合、クッキーの値が3番目と4番目のブロックに含まれていると知っているかもしれない。
5. 正当なMACを生成するため、攻撃者はURLを毎回変更しながら、サーバに3番目から最後のブロックまでの暗号文のコピーを複数送信する。
6. 結果として、メッセージは何度も復号される可能性がある。復号後、3番目のブロックの最後のバイトが正しいパディングを示す07となる。
7. 復号された最後のバイトを得た攻撃者は、前のブロックとXOR演算を行い、本来の3番目のブロックの最後のバイトを割り出す。
8. 続いて、攻撃者はURLに1バイトを追加し、前述の工程を繰り返してクッキーの次の部分を取得する。こうして、4番目のブロックも復元される。
9. クッキーの長さが16の場合、攻撃者は最大4096回のリクエストを送るまでクッキーの全内容を把握できず、これには数分が必要となる。

‍

貴社のウェブサーバはPOODLE攻撃に脆弱か - どう判断する？

貴社のウェブサーバがSSL 3.0をサポートしているなら、POODLE脆弱性の有無を確認するだけで十分です。Wallarmは、ウェブサーバがSSL 3.0に対応しているかどうかの判定に利用できます。ウェブの脆弱性を手動で特定することも可能ですが、Wallarmはより多くの機能を提供します。

さらに、POODLEは旧式のTLSプロトコル実装にも悪用される可能性があります。ただし、最新のTLS実装は安全です。

なお、POODLEはウェブサーバだけでなくアプリにも影響し、企業全体にとっての脆弱性となる点に留意が必要です。

‍

POODLE攻撃の防止

SSL v3.0暗号化が悪意ある目的で使用される可能性は低いものの、POODLE攻撃により、256回の試行で暗号文の各バイトが解読される恐れがあります。例えば、16バイトのセッションクッキーの場合、約4096回（つまり数分）の試行が必要となり、効果的な攻撃が実行される危険性が生じます。何か重要な対策が求められる状況です。

POODLE脆弱性に対するCVE-ID（CVE-2014-3566）は、2014年10月14日の情報公開時に割り当てられました。ウェブアプリやサーバで旧式のSSL v3.0プロトコルを無効化するのが理にかなっていましたが、2014年当時、多くのウェブサイトやレガシーフレームワークに影響を及ぼすため、容易な選択ではありませんでした。一つの解決策（最近BEAST攻撃対策でも採用された方法）として、弱い暗号方式のサポートを削除し、POODLE攻撃がCBCモードのブロック暗号にのみ影響することから、SSL v3.0が提供する暗号方式へ移行する手法がありました。RC4ストリーム暗号は残されましたが、既に安全でないと示されていたため問題視されました。

POODLEの研究者は、一時的対策としてTLS FALLBACK SCSV暗号スイートの利用を推奨しました。これにより、フォールバック機能を維持しつつ、より安全でないSSL/TLSプロトコルへのダウングレードを防止でき、従来型への攻撃を阻止しながらもレガシーなサーバやアプリへの対応が可能となりました。ベンダーやウェブサイト運営者は迅速にTLS FALLBACK SCSVを実装し、SSL v3.0のサポートを速やかに廃止しました。RFC 7568はその年の6月にSSL v3.0を公式に非推奨としています。

結論

SSL v3.0は、安全性に疑問があるとの明確な証拠があるにもかかわらず、特に旧版のInternet Explorerを利用し続ける内部向けシステムなどのレガシー環境で用いられていました。レガシーサポートが維持される限り、安全なプロトコルへの移行は容易ではなかったものの、実際の脅威として、POODLE攻撃は中間者攻撃の状況下で実行される可能性があります。最近の調査では、2020年頃でも公開ウェブサーバの約4%が依然としてSSL v3.0をサポートしていると示されています。