技術者ブログ

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

2017年10月

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        
  • お問い合わせはこちら
Scutum開発者/エンジニアによる技術ブログ WAF Tech Blog

SSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ

はじめに

以前のエントリでSSLに対する新しい攻撃手法「BEAST」を紹介しましたが、今回はBEASTをさらに発展させた「CRIME」という攻撃について簡単に紹介したいと思います。一次情報源としてこちらのスライド(英語)が閲覧できますので、時間がある方はぜひ目を通してみてください。

CRIMEの意味

CRIMEは "Compression Ratio Info-Leak Made Easy" あるいは "Compression Ratio Info-Leak Mass Exploitation" の頭文字で、SSLやSPDY(あるいはHTTPボディ部のgzip圧縮)で使われる圧縮アルゴリズムに注目した攻撃手法です。あまり知られていませんがSSLには圧縮機能が存在しており、サーバ側・クライアント側双方が圧縮機能をONにしている場合に、データが圧縮されます。

BEASTとの関係

CRIMEはBEASTの正統な後継者と呼べるものとなっており、BEASTが注目した、HTTPリクエストについての以下の特徴を同じように利用します。

  • イヴはアリスに知られずに、何度もメッセージを送らせることができる
  • メッセージには毎回Cookieが自動的に含まれる
  • URI部分やリクエストボディ部分など、イヴにとっての自由度が高く、ブロック境界を選択して1バイトずつブルートフォース攻撃を仕掛けやすい

攻撃の手法

攻撃の前提条件についてもBEASTと非常に似たものとなっており、イヴはアリスの通信を盗聴可能な状態であるものとなっています。この場合、SSLで暗号化されたデータであっても、データの長さそのものについてはイヴに漏れてしまいます。この「暗号化されていても、データのサイズについてはイヴに漏れる」という点がひとつの大きなポイントです。

イヴはBEASTと同様に、リクエストの内容の一部をコントロールすることができます。リクエストには毎回、アリスのCookieが自動的に含まれますが、このCookieの値を取得することが今回のイヴの目的となります。

SSLにおいて、圧縮機能は暗号化前のデータ中の文字列に重複部分があればそれを効率的に圧縮するように動作します。そのため、イヴが予測し、リクエストに埋め込んだ偽のCookieの値が、HTTPヘッダに含まれる本物のCookieの値と一致した場合にのみ、データの圧縮後のサイズが小さくなるわけです。イヴは様々な文字列を埋め込み、送信されるデータのサイズを確認します。サイズに変化があれば、「ビンゴ!」というわけです。

複数のリクエスト、SSL通信にまたがってブルートフォース攻撃を行いますが、この間に暗号化に使われる鍵が別のものになっても、攻撃には影響がありません。この点についてもBEASTと同様です。CRIMEではRC4であってもAESであっても攻撃が可能です。

SSL圧縮で使われるdeflateには16KBごとの境界が存在するため、攻撃対象のCookieの値がちょうどこの境界上に来るようにパディングのサイズを調節することで、1バイトずつのブルートフォース攻撃が可能となります。

対策

CRIME攻撃を防ぐためには、SSLやSPDYの圧縮機能をオフにします。最近になって各ブラウザのSSL/SPDYの圧縮機能がデフォルトでオフに変更されたのは、CRIME作者からの連絡があったからだと思われます。

JavaとCRIMEの関係

JavaのSSL実装では、元々圧縮機能がサポートされていません。このため、例えばTomcatをSSLサーバとして動作させている場合などには、CRIMEの影響は受けません。私たちが提供しているSaaS型WAFサービス、Scutumでも同様に、CRIMEの影響は受けない形となっています。

レスポンスボディのgzip圧縮に対する攻撃

CRIMEのスライドでは、具体的には触れていませんが、HTTPで非常によく使われている、レスポンスボディ部のgzip圧縮(+SSLが使用されている場合)に対する攻撃の可能性についても示唆しています。イヴがレスポンスの内容を比較的自由にコントロールできるなどの条件が整えば、レスポンス中のCSRF防止トークンなどを同様の手口でイヴが手に入れることができる可能性があります。

こちらについて完全に対策するためにはgzip圧縮を無効にする必要がありますが、パフォーマンスとのトレードオフとなるため、なかなか難しい選択となるでしょう。管理対象のウェブアプリケーションがレスポンスにおいてCRIME攻撃の影響を受けるのかどうかが正しく判断できるかどうかが、gzip圧縮を無効にするかどうかのひとつの判断基準となります。

CSRFの新しい形

筆者が以前のエントリでも指摘したように、BEASTもCRIMEも、意図しないリクエストが飛ばされ、そこにCookieが自動的に含まれてしまう点を攻撃するという意味で、CSRF攻撃の一種だと言えるでしょう。BEASTが発表されたらBEAST対策(RC4にする/TLSをバージョンアップする)を行い、CRIMEが発表されたらCRIME対策(圧縮機能をオフにする)を行う、といういたちごっこよりも、より根本的な対策が求められている気がします。

  • 第三のサイトによって発生させられるリクエストに、自動的にCookieが付加すること
  • たったひとつのCookieの値でセッション管理を行うこと
  • ブルートフォース攻撃を行うような、似たリクエストの連続送信をサーバ側が許可すること

上記のような点について、ブラウザやウェブアプリケーションができることはまだまだあるはずです。たとえばウェブアプリケーション(あるいはミドルウェア)が、Cookieの値を非常に頻繁に変更するような動作を行えば、BEASTもCRIMEも通用しません。また、ブルートフォース攻撃を行うような、短時間に似たリクエストが大量に発生すること自体を検出できれば、それによって攻撃の検知と防御ができる可能性もあります。

BEASTとCRIMEは、ウェブアプリケーションセキュリティはまだまだ奥が深いと痛感させられる攻撃手法だと感じました。果たしてこれに続く第三の攻撃が登場するのか、楽しみに待ちたいと思います。