BEAST攻撃とは？ TLS/SSL規格の脆弱性

BEAST攻撃とは？

Browser Exploit Against SSL/TLSはBEASTと呼ばれます。これはTLS 1.0およびそれ以前のSSL規格に対するネットワークの脆弱性攻撃です。この攻撃は2011年にセキュリティ研究者Thai Duong氏とJuliano Rizzo氏によって初めて実行されました。ただし、Phillip Rogaway氏は2002年に脆弱性の可能性を指摘していました。

なぜこのような古い攻撃方式を検証する必要があるのでしょうか？調査によると、確認されたウェブサーバの30.7%が脆弱なTLS 1.0を利用しており、BEAST攻撃に対して守りが甘い状態でした。

これは、数多くの新しいセキュリティ技術が登場しても、現存の脅威が依然として企業にとって大きな課題であることを示しています。OpenSSLのHeartbleed、BEAST、BREACH、POODLEといったSSL/TLSの脆弱性も同様です。

BEAST攻撃の仕組み

CBCモードにおける初期化ベクトルは予測可能で、BEAST攻撃の暗号化の仕組みの重要なポイントとなります。攻撃者はブロックサイズの境界をずらすことで、このサイクルの規則性とブロックの一定の大きさを利用し、暗号を解読せずに平文を一部ずつ見破ることが可能です。

この仕組みを理解するには、ブロック暗号の動作を把握することが重要です。

TLS、ブロック暗号、初期化ベクトル

一般に、TLSはブロック暗号と対称暗号方式のスイートを利用します。対称暗号では同じ鍵を用いてデータの暗号化と復号が行われます。しかし、安全性を高めるため、まず非対称暗号方式によってアプリとサーバ間で共通鍵を取り決め、その後、より高速かつ効率的な対称暗号化が始まります。

ブロック暗号は、決まった長さ（正確には8バイト）のブロック単位でデータを暗号化するため、このように呼ばれます。不足する部分は任意のデータで埋められる仕組みです。DES、AES、3DESが代表的な例となります。

CBCモードでは、初期化ベクトル（IV）を用いて暗号化の多様性と安全性を向上させます。初期化ベクトルがなければ、同じ平文は常に同じ暗号文ブロックとなり、平文攻撃に対して脆弱になります。また、最初の平文ブロックは任意のデータと結合されたIVと共に鍵で暗号化され、ランダム性が加えられます。

その後、各ブロックのIVは前ブロックの暗号文となり、XORという演算で平文と結合（ブロック同士を連結する操作）され、定められた鍵で全体が暗号化されます。

‍

BEAST攻撃の実行

攻撃者がクライアントとサーバ間の通信を「盗聴」できると仮定します。悪意あるサイトを介してクライアントにJavaScriptやアプレットの送信を促し、サーバがTLS 1.0またはSSLを利用していた場合のことです。

その後、攻撃者は通信にデータブロックを挿入し、メッセージのIVを取得して必要な平文ブロックとXOR演算を行います。これをサーバに送信し応答を確認することで、中間者攻撃やレコード分割と呼ばれる手法が実行され、結果としてウェブサーバやアプリに保存されるパスワード、Mastercard番号、その他の情報が狙われる危険性が生じます。

初期のBEAST攻撃では、全ブロックの暗号文を推測できると考えられていました。しかし、実際にはたとえ8バイトのブロックでも最大2568回の試行が必要となるため、現実的ではない攻撃と見なされていました。

しかしながら、2011年にThai Duong氏とJuliano Rizzo氏は別の手法を発見しました。彼らは全ブロックを推測する代わりに、ブロック境界をずらして1バイトだけを切り出す方法を採用しました。これにより、1バイトの推測は、各桁の試行回数が限定され、成功するたびに境界が移動するため、はるかに容易になりました。これが攻撃の肝となる手法です。

‍

影響を軽減する試み

サーバ側およびアプリ側の両方で、ソフトウェアベンダーは攻撃の危険性を減らすために迅速な対策を講じました。TLS 1.1または1.2の利用が最も安全な方法であり、TLS 1.0の根本的な問題を解決しています。しかしながら、TLS 1.0は最新のSSL規格でありながら、ほとんどのサイトや主要なアプリで依然として利用されています。特に、Microsoft Windows XP上のInternet ExplorerやMac OS X 10.7以降で動作するGoogle Chrome、Mozilla Firefox、Safariでは脆弱でした。なお、Windows Server 2008 R2ではTLS 1.1が無効化されていましたが、Windows Secure Channel（SChannel）の設定変更により有効にすることが可能でした。

TLS 1.1へ移行する前に、規格を変更せずに対処するための方法がいくつか検討されました：

ストリーム暗号への変更：TLS規格では、ブロック暗号の他にストリーム暗号であるRC4もサポートされていました。CBCモードの脆弱性に鑑み、RC4への切り替えが提案されましたが、2013年に専門家はRC4も理論上危険であることを示しました。さらに、コードの他の欠陥が指摘され、IETFは2015年にRFC 7465を発行し、TLSでのRC4使用を正式に禁止しました。

ブロック暗号モードの変更：今回の攻撃がCBCモードを狙っているため、別のブロック暗号モードを用いれば問題は解決するかと考えられました。しかし、TLS 1.0は後のバージョンと異なりCBCモードのみをサポートしているため、この対策は実現できませんでした。

別の対策として、ゼロ長ペイロードを持つ空のデータブロックを追加し、不正な初期化ベクトルを消費させる方法が試されました。ゼロ長のデータブロックを送ると、不足分が任意のデータで埋められ、1つのランダムなブロックが生成されます。このランダムブロックが次のメッセージの初期化ベクトルとして利用され、暗号化の安全性が回復する仕組みです。しかし、この方法はTLS 1.0規格で定められておらず、特にInternet Explorer 6.0など一部のSSLスタックでは問題が発生しました。OpenSSLでは修正が加えられましたが、完全な解決策とはなりませんでした。

1/n-1パディングが利用される：FirefoxやSafariなど、一部のアプリではTLS 1.0実装においてHTTPSパケットの分割方式が採用されました。この方法は、ゼロ長ペイロードを用いた空パケットに似ています。nバイトのデータブロックを、先頭の1バイトを別パケット、残りのn-1バイトを続くパケットに分割して送信することで、任意のデータが加えられた初期化ベクトルが含まれ、暗号化サイクルに再び乱数が導入されます。

‍

BEAST脆弱性はどのように対策するか？

最初はRC4暗号がBEAST攻撃対策として推奨されました（ストリーム暗号であるため）。しかし、結果的にRC4も危険であることが判明しました。さらに、PCI DSS（Payment Card Industry Data Security Standard）ではこの暗号の使用が禁止されているため、この方法でBEASTに対抗するべきではありません。

TLS 1.0およびそれ以前の規格を無効にすることが、他のネットワーク脆弱性と同様にBEAST対策として最も明確な方法です。代表的なウェブサーバソフトについては、以下の手順に従ってください。また、TLS 1.1を無効にし、TLS 1.2のみを有効にすることを推奨します。（Google Chrome、Firefox、Safariなど、すべての主要なアプリがTLS 1.2に対応しています。）

• Apache

多くの場合、/etc/httpd/conf.d/SSL.conf にあるSSL.confファイルのSSLProtocol設定を変更する必要があります。例として、以下の設定がある場合：

SSLProtocol all - SSLv3

を次のように変更してください:

SSLProtocol TLSv1.2

その後、httpdを再起動します。

• Nginx

nginx.confファイル内のSSLプロトコル設定も変更します。例として、以下の設定がある場合：

ssl_protocols TLSv1 TLSv1.1 TLSv1.2

を次のように変更してください:

ssl_protocols TLSv1.2

その後、Nginxを再起動します。

• Microsoft IIS

Microsoft IISの場合、Microsoft Windowsのレジストリ設定を変更し、TLS 1.0を無効にする必要があります。

レジストリエディタを起動し、HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Server のTLS 1.0プロトコルのキーを探してください。

EnabledフィールドのDWORD値を0に変更し、DisabledByDefaultフィールドのDWORD値を1に設定します。

その他のSSLおよびTLS 1.1実装についても、上記の指示に従って設定を変更してください。

結論

セキュリティ専門家は、BEAST攻撃の事例から多くの教訓を得ることができます。最も重要なのは、実装が常に最新のセキュリティ規格に追いついていない点です。たとえば、直接的な攻撃が発生した時点で、TLS 1.1の対策は長期間講じられていました。また、時間が経つにつれ、現在は理論上または実用的ではないとされる暗号の脆弱性が実際の実装で突かれる可能性があるため、確立された基準に従うことが賢明です。最後に、古い規格の類似点をチェックできる最新の脆弱性スキャナを活用し、セキュリティを維持することが重要です。わずかな不備でも、理論上安全な暗号計算が破られる恐れがあります。