本文とサイドメニューへジャンプするためのナビゲーションスキップです。

スタートアップガイド

J-Net21 中小企業ビジネス支援サイト

  • J-Net21とは
  • スタートアップガイド
中小機構
  • メルマガ登録
  • RSS一覧
  • お問い合わせ

HOME > 製品・技術を開発する > デジ・ステーション

デジ・ステーション


5分でわかる最新キーワード解説
BEAST/SSLの脆弱性を突く「BEAST攻撃」って何だ?

日々進歩するIT技術は、ともすると取り残されてしまいそうな勢いで進化の速度を高めています。そこでキーマンズネット編集部がお届けするのが「5分でわかる最新キーワード解説」。このコーナーを読めば、最新IT事情がスラスラ読み解けるようになることうけあい。忙しいアナタもサラっと読めてタメになる、そんなコーナーを目指します。今回のテーマ、「BEAST攻撃」は、Webでのセキュアな通信を支える暗号化通信の基盤技術であるSSL/TLSの脆弱性を利用して、通信の盗聴とアカウントの乗っ取りを実現してしまう高度な攻撃方法。インターネットの商業利用の信頼性を揺るがす危険性を秘めており、全世界が緊張を高めた攻撃手法です!

1.SSL/TLSの脆弱性を突く「BEAST」とは?

 「BEAST」とは「Browser Exploit Against SSL/TLS」の略で、Juliano Rizzo氏とThai Duong氏という2人のセキュリティ研究者によって、昨年秋開催のセキュリティ会議「ekoparty」においてデモンストレーションされた暗号化通信に対する新たな攻撃手法だ。

1-1.BEAST攻撃のデモンストレーション

デモンストレーションではたまたま「Paypal」のアカウントを対象に実験が行われたが、理論的には暗号化通信にSSL 3.0及び、その後継のTLS 1.0のブロック暗号を利用するあらゆるWebサイトへのアクセスに適用が可能な攻撃手法である。

SSL/TLSにおいては、ブラウザとサーバの両方が対応する複数の暗号化技術の中から、優先順位が高いものを選択して利用する。中でも広く普及するAESのようなブロック暗号の用いるCBC(cipher block chaining)というモードの実装上の脆弱性と、未知のバイト列を絞った「選択平文攻撃」という手法をたくみに組み合わせたのがBEASTの特長である。

これらの脆弱性はどれも既知のものであり、危険度は低いものなのだが、特定の条件下であれば、短時間にアカウント認証に用いるブラウザクッキーの復号化に成功することがデモンストレーションにより証明されたことは、全世界に大きな衝撃を与えた。

図1 BEASTとは?
図1 BEASTとは?

1-2.第1の脆弱性「CBCモード」

ブロック暗号とは、通信データサイズを16バイト程度のサイズのブロックごとに分け、秘密の共通鍵を用いて暗号化するものだが、単純に実装すると、同じ平文ブロックには同じ暗号文ブロックが生成されるため強度が低い。

図2 CBCモードのブロック暗号
図2 CBCモードのブロック暗号

Pnは平文ブロック(暗号化されていない元の文)
Eは暗号化の関数(変換のルール)
Cnは暗号文ブロック
IV(Initialization Vector)は最初にXOR演算するためのランダムなバイト列。

そこで常にランダムな暗号化ブロックを得るためにCBC(cipher block chaining)という手法が広く用いられている。

CBCでは、それぞれの平文ブロックを暗号化関数Eに通す前に、1つ前の暗号文ブロックを使ってXOR演算という一種のスクランブルを掛ける。

これにより、同じ平文でも毎回違う暗号文が出てきて、盗聴しても解読できない通信ができる仕組みだ。

しかし、サーバ管理者「ボブ」と正規ユーザ「アリス」、攻撃者「イヴ」について、次のような条件を考えてみると、盗聴が不可能ではないことが分かる。

●アリスからボブへと暗号化通信しており、イヴが攻撃
●イヴはすべてのパケットを盗聴しているが、暗号鍵は分からない
●P1の内容はアリスが決める(ボブに送りたい、秘密のメッセージ)
●P2以降のPnはイヴがコントロールできる
●イヴの目的はP1を知ること
●イヴはメッセージ全体の長さをコントロールできる(平文に任意のデータを追加できる)

この条件下でイヴがPnを総当りで送り続け、C1=Cnの盗聴結果が得られた場合、暗号化関数Eを用いる前の状態は、1番目とn番目のどちらも同じであることがイヴには分かってしまう。これを式で表すと次のようになる。

P1 xor IV = Pn xor C(n-1) :XOR(排他的論理和)後の2つのデータは同一

XOR演算には2回繰り返すと元に戻る性質があるので、両方のデータに更にIVをXORすると、

{P1 xor IV} xor IV = {Pn xor C(n-1)} xor IV
  P1 = Pn xor C(n-1) xor IV

という式が成り立つ。

「P2以降のPnはイヴがコントロールでき」、「イヴはすべてのパケットを盗聴している」ので、イヴは、Pn、C(n-1)、IVの3つ全部を知っている。つまり、右辺の演算を実行するだけで、目的のP1の内容を(暗号鍵を知らないままに)イヴは解読できるのだ。

これがCBCモードの本質的な脆弱性であり「選択平文攻撃」と呼ばれる攻撃手法だ。

しかしながら、16バイトのデータには「3.4×10の38乗=340×1兆×1兆×1兆」ものパターンが存在するため、「C1=CnとなるまでイヴがPnを送り続ける」には、非現実的なほど長い時間が必要となり、実質的には問題視されることがなかった。

1-3.“未知データを1バイトに絞り込む”ことで一気に脆弱に

総当りでの攻撃(ブルートフォースアタックと呼ぶ)を、16バイト等のブロック単位で実行することが実質的に不可能であることは前述の通りである。

しかし、ブロック中の任意の15バイトをすべて知っていれば(1バイトのみ未知ならば)事情が変わってくる。  「予想されるP1」は256パターンに絞られるため、これを1番目から256番目まで並べてn番目をPex(n)と定義し、テストする平文Pts(n)として、少し工夫を加えた

Pts(n) = Pex(n) xor IV xor Cts(n-1)

を置くと、次の図のようになる。

図3 ブロックの1バイトのみ未知の場合のブルートフォースアタック

この場合、Pex(n)=P1、すなわち正解であるための条件は、Cts(n) =C1である。 C1と一致する暗号文Cts(n) が得られるまで、最大256回の試行を繰り返せば、必ず答え合わせに成功し、未知の1バイトを探り当てることができる。

ただし、正解のP1が通常の平文であるのに対して、テストに用いるPts(n) はXORを複数回行った特殊文字列となるため、送信文字列の制約などに掛かる可能性は否定できない。

1-4.実際のBEASTの動作

それでは実際のBEASTの攻撃のシナリオをみてみよう。

BEASTの攻撃シナリオ
●ボブのWebサイトに、アリスがログインし、セッション管理はCookieで行われる
●アリスのセッション認証Cookieを入手すれば、イヴはアリスになりすますことができる
●イヴはアリスとボブのサーバ間の通信をすべて傍受できる
●HTTPSセッションにはCBCモードの共通鍵暗号方式が採用されている

まずイヴはアリスのWebブラウザにマルウェアを送り込み、任意のHTTPSリクエストをボブへと送信できる状態とする。

リクエストは次のような文字列(“?”の部分が未知)となる。

POST /AAAAAA12345678 HTTP/1.1\r\n???????????????

16バイト=16文字ずつに分割されたブロックは次のようになる。

POST /AAAAAA1234|5678 HTTP/1.1\r\n?|????????????????

この2つ目のブロック「5678 HTTP/1.1\r\n?」には「?」の1文字しか未知のバイトが存在しないことがお分かりいただけるだろうか。この場合、前項で説明した通り、わずか256パターンの総当りで探し当てるブルートフォースアタックが成立してしまうのだ。

攻撃を実行して仮に答えが「A」だったら次は、「POST /AAAAAA1234」、「567 HTTP/1.1\r\nA?」のように冒頭の文字列を調整して位置をずらしたリクエストを送り、同様に次の1文字を256パターンから探し当てる。これを繰り返していけば、いずれはリクエスト内に含まれるセッション認証Cookieにまでたどり着き、同じブラウザからログインして、イヴはアリスのアカウントを奪取することが可能になる。

実際のデモンストレーションでは、Safariの取得したセッション認証CookieをBEAST攻撃により解読して、Firefoxに同じCookieを手動で作成してなりすましに成功している。しかも、解読に要した時間は2分に満たない。

参考:Juliano Rizzo氏とThai Duong氏によるデモ動画
「BEAST vs HTTPS」(YouTube)

2.BEASTはどれだけ危険な存在か

ここまでの情報をみると、BEASTの脅威は目の前のWebの安全性を即座に脅かしかねないように感じてしまうが、実際の危険度は、少なくとも現時点では非常に低いと考えられている。

2-1.BEAST攻撃を成功させることは難しい

BEASTの攻撃には、アリスとボブのやり取りのすべてのパケットをリアルタイムで盗聴するパケットスニファと、大量のリクエストを発行できるブラウザ上で動作するエージェント(マルウェア)の注入(JavaScriptインジェクションなど)が必要である。

しかし実際のネットワーク環境では、次のような特殊な条件が整わない限りBEAST攻撃を成功させることは難しい。

BEASTの攻撃シナリオ
●全パケットを盗聴される可能性自体がほぼ考えられない(man-in-the-middle:中間者攻撃)
●他ドメインのエージェントからボブにリクエストを送ることは本来不可能(Same Origin Policy:セイムオリジンポリシー)

1つ目の中間者攻撃については、信頼できるISPや企業ネットワークを利用している限り、悪意の第三者による侵入やハッキングはまずありえない。2つ目のSame Origin Policy(SOP)の回避のために、BEASTでは、開発中に初めて見つかったJava appletの未知の脆弱性(現在は対策済み)を利用している。

これは一種の偶然であり、現時点でFLASHやSilverlight、 WebSocketやXMLHttpRequestなどのブラウザプラグインに同様の脆弱性は見つかっていない。ただし、BEASTの手法は巧妙であり、増え続けるWebブラウザのプラグインアーキテクチャのどこかに、攻撃を可能にする脆弱性が発生する可能性は否めない。

2-2.TLS 1.1以降ならIVがリフレッシュされ安全

BEASTの攻撃成立のための条件として、IVが最初に定義されたのち、あとは最後の暗号文ブロックをIVがわりに利用し続けること(攻撃者がIVを知っていること)が重要である。

現在主流となっているSSL 3.0やTLS 1.0では、新たなリクエスト(SSL/TLSレコード)を送信する際にも、前回のリクエストの最後の暗号文ブロックをIVとして使う(連続的な通信として扱う)仕様となっているため、この条件をクリアする。

しかし、IVがリクエストごとにリフレッシュされるならば、BEASTの手法は通用しない。実際、最新のTLS 1.1やTLS 1.2などのCBCモードでは、IVはSSL/TLSレコードごとにリフレッシュされるため、BEASTに対する脆弱性は存在しない。

3.BEASTへの対策は?

現時点でのBEASTの対策として、次のようなものが挙げられる。

3-1.ユーザ側の対策

BEASTのエージェントがブラウザセッション中にアクティブであることを防ぐために、セキュアなサイトにログインする前に、ブラウザを再起動するという方法が有効である。また、公共のWiFiネットワークは通信傍受の可能性をゼロにできない点で、中間者攻撃のリスクが高い。そうした場所ではセキュアなWebサービスへのログインを避けることも、有効な対策となる。

3-2.ブラウザ側の対策

CBC暗号の使用を避け、RC4のようなストリームベースの暗号を使用することは有効な対策である。IVの継承を行わず常にリフレッシュするTLS1.1 のみを使用するのも有効だが、TLS1.1に対応するWebサーバはわずか0.25%過ぎないとの調査も存在しており、まだまだ時期尚早だと言えそうだ。また、Google Chromeなどの一部のブラウザでは、空のデータを含むSSL/TLSレコードを合間に送信することでIVを事実上リフレッシュする対策も施されていると言う。

各ブラウザにおける対策方法は、以下の通り。

Microsoft IE
http://www.keyman.or.jp/3w/prd/00/00006400/?p_id=30004493&url=http%3A%2F%2Fblogs.technet.com%2Fb%2Fsrd%2Farchive%2F2011%2F09%2F26%2Fis-ssl-broken-more-about-security-advisory-2588513.aspx
Mozilla Firefox
http://www.keyman.or.jp/3w/prd/00/00006400/?p_id=30004493&url=http%3A%2F%2Fblog.mozilla.com%2Fsecurity%2F2011%2F09%2F27%2Fattack-against-tls-protected-communications%2F
Google Chrome
ベータ/開発テスト段階のフィックスを準備中。安定され次第、自動アップデートにより提供される予定。
Apple Safari
執筆時点で情報なし。

3-3.サーバ/WAF側の対策

SSL/TLS通信のネゴシエーションにおいて、暗号化に用いるCipher Suites(暗号化方法のセット)にRC4暗号を使用するものを優先して選択するようにサーバを設定することは本質的な解決策となる。

同様にTLS1.1に対応して、利用できるユーザにはこちらを利用してもらうことも有効だろう。

Webアプリケーション及びWAFで、クロスオリジン・リクエストをブロックするクロスサイトリクエストフォージェリ(Cross site request forgeries:CSRF)防止の設定を行うことも、BEASTに有効である。

取材協力 :バラクーダネットワークスジャパン株式会社

掲載日:2012年2月29日

キーマンズネット

出典元:株式会社リクルート キーマンズネット 2012年1月25日掲載分

検索

このページの先頭へ