技術者ブログ

クラウド型WAF「Scutum（スキュータム）」の開発者/エンジニアによるブログです。
金床“Kanatoko”をはじめとする株式会社ビットフォレストの技術チームが、“WAFを支える技術”をテーマに幅広く、不定期に更新中！

日	月	火	水	木	金	土
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

«　SSL BEASTが利用する「選択平文攻撃」をJavaで実行する方法　|　Tech Blog ホーム　|　Tomcatなど、Java製のサーバでBEAST対策を行う方法　»

BEAST(Browser Exploit Against SSL/TLS)とは何か

2011年10月19日

金床　“Kanatoko” （Scutum開発者／株式会社ビットフォレスト CTO）

はじめに

CBCモードへの選択平文攻撃を扱った前回のエントリに引き続き、BEASTについて見ていきます。今回は、BEASTの全体像について解説します。なお、BEASTの実際の攻撃コードはパブリックにされていないため、この記事の内容はあくまでも推測に基づくものとなっていることをご了承ください。

BEAST以前の情報

BEASTはSSLに対する「100%新しい画期的な攻撃方法」ではありません。過去に発見されていたいくつかのテクニックを適切に組み合わせ、さらに最後のひとさじを加えることで華麗にまとめあげたものとなっています。

BEASTの基となっている技術は、ほぼ次の2つの論文にまとまっていると考えられます。

The Vulnerability of SSL to Chosen-Plaintext Attack
A Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL

BEASTがこれら2つの論文と決定的に異なっているのは、その攻撃成功確率の高さです。「現実的な脅威と言えるかどうか？」という点で、BEASTは一歩ぬきんでた存在であると言えます。

BEAST作者は何を発見したのか？

上記の2つの論文では、前回のエントリで触れた「CBCモードへの選択平文攻撃」を、SSLに対していかに行うか？が話題の中心となっています。さまざまな仮想的な条件の元で、どの程度の確率で攻撃が可能か、という点を追求しているものの、具体的に成功確率の高い攻撃モデルを提供することはできていませんでした。また、攻撃対象もあいまいなものとなっています。

BEAST作者の2人組が発見したのは、次の2点です。

1点目は、この攻撃を成功させる理想的な通信の発見です。それはHTTPSのリクエストであり、攻撃対象をCookieに絞ることで、前述した2つの論文が追い求めていた「現実的に可能な攻撃」となっています。

2点目は、暗号化通信のストリームにおいて、暗号化ブロックの境界位置をイヴが自由にずらすことで、常に1バイトずつのブルートフォース攻撃が可能になる、ということです。彼らはこれをBCBA(Blockwise Chosen-Boundary Attack）と呼んでいます。

続いて、これら2点が実際の攻撃においてどのように用いられているのか、具体的な攻撃のシナリオを見ていきます。

具体的な攻撃シナリオ

BEASTが想定する攻撃シナリオは、次のような前提となっています。

ボブが運営するウェブサイトに、アリスがログインし、ウェブサイトを利用するタイミングを狙う
ログイン後のセッション管理はCookieで行われる
仮にイヴがアリスのCookieを入手すれば、アリスになりすまして、ボブのウェブサイトにログインすることができる
通信はすべてHTTPSで行われている
イヴはパケットキャプチャ能力を持っており、アリスとボブのサーバ間の通信をすべて傍受できる
イヴはパケットの傍受は可能であるものの、改ざんを行うことはできない
該当するHTTPSセッションにおいてCBCモードを使用する共通鍵暗号方式が採用されている

イヴは、何かしらの方法で、あらかじめアリスのウェブブラウザにマルウェアを送り込んでおきます。実際のBEASTのデモで使われたのは、Javaアプレットだったようです。

アリスがボブのウェブサイトにログインした後が、イヴにとっての攻撃のタイミングとなります。アリスとボブのサーバ間の通信はすべてHTTPSであるため、イヴにとって、正確に「アリスがいつログインしたか」を判断することは難しいでしょう。しかしデモで使われたpaypal.comのように、基本的にログインしてから使うタイプのウェブサイトであれば、ある程度の量のパケットが飛んだ時点でログインしたと判断することができます。

イヴは攻撃を開始します。あらかじめ送り込んでおいたマルウェアをリモートで制御し、ボブのウェブサイトにHTTPSのリクエストを送信させます。このリクエストには自動的にCookieが付加され、このCookie部分を復号することがイヴの目的となります。

CBCモードへの選択平文攻撃を開始

TLS_RSA_WITH_AES_256_CBC_SHAのようなCipherSuiteが選択されていれば、CBCモードに対する選択平文攻撃を仕掛けることが可能となります。

イヴが操っているマルウェアはHTTPSリクエストを送信しますが、この際リクエストのメソッドやURIはイヴが自由にコントロールすることができると考えてよいでしょう。例えばPOSTメソッドで/AAAAAAというURIにアクセスさせるリクエストを考えます。AESではブロック長は16バイトとなるので、最初のブロックは次のようになるでしょう。

POST /AAAAAA HTT

つまり、このブロックはイヴにとって完全に既知な内容となります。では、次のブロックはどうでしょうか。ここで、仮にボブのウェブサイトが「bob.example.jp」とし、リクエストヘッダの最初の行はHostフィールドが来ているものとします。すると次のようになります。

P/1.1\r\nHost: bob

3ブロック目は次のようになります。(Hostフィールドに続いてUser-Agentフィールドが並んでいると仮定します)

.example.com\r\nUs

このようにHTTPSリクエストは16バイトごとのブロックに分割されて暗号化されていきます。2ブロック目に注目した場合、上の例ではHostフィールドが先頭に来ていると仮定しましたが、これは必ずしもそうなるとは限りません。そのため、イヴにとって既知なのはリクエスト行の最後のCRとLFの並びまでであり、「Host」から先の部分は未知であると考えられます。つまり、2ブロック目は、イヴにとって既知の部分(7バイト)と未知のバイト(9バイト)から構成されています。

この場合、未知の部分が9バイトもあるため、ブルートフォース攻撃を成功させるためには最大で256の9乗もの回数の試行が必要とされ、実質的に攻撃することはできません。

そこで、イヴは2ブロック目の未知のバイトを1バイトだけにすることを考えます。URIを「/AAAAAA」ではなく、「/AAAAAA12345678」とするのです。すると、1ブロック目は次のようになります。

POST /AAAAAA1234

2ブロック目は次のようになります。

5678 HTTP/1.1\r\nH

2ブロック目において、イヴにとって未知なのは最後の1バイト(右端Hの部分)だけとなり、現実的にブルートフォース攻撃が可能となります。

イヴはPOSTリクエストのボディ部分において、適切にブロックの境界を判断し、自由にバイト列を組み立てます。16バイトのブロックごとに試行を重ね、最大で256回のチャレンジでこの「H」の文字を得ることができます。この試行はJavaアプレットとパケットキャプチャが連携して行います。前述したように暗号化前のデータはxorを経た、データとしてはまったくランダムなバイト列のようなものになるため、Javaアプレットのように送信するデータの形式に対して制限がゆるいものが攻撃に適しています。例えば送信するデータの（暗号化前の）形式について「正しいUTF-8の文字列であること」のような制限がある場合には、攻撃が困難なものとなることが予想されます。JavaScriptを使った攻撃などではこのような制限が存在することが想定されます。

もっとも攻撃効率が悪い場合でも、16x256=4096バイト、つまり約4KBほどのサイズのリクエストで未知の部分を1バイト得ることができます。実際には、アルファベットや数字などを優先することで、より効率の良いブルートフォース攻撃が可能となるでしょう。

1バイト判明したら、また同じようにURIの長さを調節することで、次の1バイトだけがブロックの最後の部分に位置するようにします。当然新しいHTTPSリクエストとなり、場合によっては(Keep-Aliveなどが関係します)新しい共通鍵が使われることもありますが、それはこの攻撃には影響を及ぼしません。リクエストに同じCookieが付加されている間は、HTTPヘッダの1文字目から順番にブルートフォース攻撃を行うことで、最終的にはCookie全体を取得することが可能となるのです。

また、HTTPSリクエストは同時並列的に送信することもできますので、より効率的にソフトウェアを作成することで、ブルートフォース攻撃の速度を飛躍的に高めることが可能となるでしょう。

HTTPの性質が招いたBEAST

通常わたしたちがウェブブラウザを使っているとき、バックグラウンドでどのようなHTTPリクエストがどのようなウェブサーバに飛んでいるかは、ほとんど気にされません。特にAjaxが一般化されてからは、ウェブサイト間の移動などのタイミングとは関係なく、数多くのHTTPリクエストが飛び交うようになりました。そのため、イヴがアリスのウェブブラウザ上のマルウェアから多くのHTTPSリクエストを送らせても、そのことがアリスに不自然に思われる可能性は極めて低いと考えられます。

イヴは数多くのHTTPSリクエストを送信させることができますが、これらのリクエストには毎回必ずCookieが含まれます。多くの場合、このCookieの内容は、数分から数十分程度、つまりセッションが切れるまでの間は、同じ値を持っていると考えられます。HTTPのKeep-Alive機能が使われる場合を除き、多くの場合、新たなHTTPSリクエストを送るたびに新しいSSL接続が生成されるため、暗号化に使われる共通鍵は異なるものとなってしまいますが、「CBCモードへの選択平文攻撃」においてはそれはそれほど重要なことではありません。

このように、以下に挙げるようなHTTP固有の性質が、まさにBEASTによる攻撃を可能にするものとなっています。

イヴはアリスに知られずに、何度もメッセージを送らせることができる
メッセージには毎回Cookieが自動的に含まれる
URI部分やリクエストボディ部分など、イヴにとっての自由度が高い

アリスに意図させずにイヴがリクエストを送信させ、そこに自動的にCookieが含まれてしまう点を攻撃するという意味では、BEASTはCSRF攻撃であるとも言えます。

Javaアプレットのバグ

BEASTの作者はHTTPSとCookieをターゲットにするということは比較的早い段階で決めたようですが、実際にデモを行うための実装に何を選ぶのかについては、紆余曲折があったようです。Javaアプレットをはじめ、FLASHやSilverlight、WebSocketやXMLHttpRequest等が検討された結果、最終的にはJavaアプレットが選ばれていますが、デモではJavaアプレットの未知の脆弱性が使用されています。

通常、イヴのサイトに置かれたアプレットからは、Same Origin Policy(SOP)に違反するため、ボブのサイトにリクエストを自由に送ることはできません。つまりBEASTはSSLの脆弱性を攻撃する、と喧伝されたものの、実際にはJavaプラグインの脆弱性に依存した形のものとなってしまっていました。そのため、「なんだ、結局はSSL自体の問題ではなく、Javaの脆弱性なのか」といった見方もする人もいたようです（私も、最初はそう思いました）。

ただし、これまでに見てきたように、たとえJavaプラグインに脆弱性がなかったとしても、BEASTの着眼点は実に巧妙であり、多数存在するウェブブラウザのプラグインアーキテクチャのどこかで、今後も攻撃を可能にするポテンシャルを秘めていると考えられます。

対策

AESのようなブロック暗号ではなく、RC4のようなストリーム暗号が優先して使われるように設定することで対策となります。Googleのウェブサーバでは（おそらくこちらはBEAST対策ではなくCPU使用率の問題だと思いますが）数年前からRC4を優先して使うような設定になっているようです。一方で、デモで使われてしまったpaypal.comではAESが優先されるようになっているようです。

TomcatなどのJavaアプリケーションサーバでは、OracleのJSSE実装を使っている場合、サーバ側でCipherSuiteの優先順位を決めることができません（必ずクライアント側の希望が優先されてしまいます）。この場合の対策については次回のエントリで触れたいと思います。

また、TLS1.1以降ではCBCモードの動作について変更がなされるようなので、その場合にはCipherSuiteの種類によらずBEAST攻撃は不可能となると期待されます。

OpenSSLやGoogle Chromeなどの一部のソフトウェアでは、空のデータを含むSSLレコードを合間に送信することでイヴからコントロールできない形でIV(各ブロックでxorに使われる値)を変化させることで対策を取っています。

参考にしたサイトなど

上記2つの論文以外に、次のウェブサイトなどを参考にしました。また、すでにファイルが消えているためURLの掲載はしませんが、BEAST作者による論文(Here comes the ninjas)についても参照しています。

«　SSL BEASTが利用する「選択平文攻撃」をJavaで実行する方法　|　Tech Blog ホーム　|　Tomcatなど、Java製のサーバでBEAST対策を行う方法　»