Firesheepと関連する話題を調べてみる - 思い立ったら書く日記

2010年10月、エフセキュアブログの記事にて、Firefoxアドオン「Firesheep」が公開されたことを知りました。「Firesheep」の説明を読んでみると、HTTPセッションハイジャック対象の Web サイトを独自に定義できるようでした。このことが気になったので、自宅のネットワークで「Firesheep」を使ってみました。この過程で調べたことをメモとしてまとめておきます。

Firesheepとはなんぞや

「Firesheep」は、第三者の Web ブラウザと定義した Web サイトが通信しているセッション ID を盗聴することで、 HTTPセッションハイジャックを実現する Firefox のアドオン（add-on）です。開発者 Eric Butler 氏の説明によると、HTTP セッションハイジャックが深刻な問題であることを実証するために、「Firesheep」をリリースしたとのことです。

Today at Toorcon 12 I announced the release of Firesheep, a Firefox extension designed to demonstrate just how serious this problem is.
Redirecting…

試しに「Firesheep」を使って、Twitter のセッションハイジャックを再現してみます。再現環境は、無線 LAN 接続した Windows 7 です。Firesheep 0.1 を起動した状態で、Google Chrome 7.0.517.44 で Twitter にログインすると、「Firesheep」に Twitter の HTTP セッションが表示されます（下図の赤枠を参照）。

「Firesheep」に表示された Twitter の HTTP セッションをダブルクリックすることで、その HTTP セッションハイジャックが再現されてしまいます（下図を参照）。エフセキュアブログで書かれているように、確かに容易に HTTP セッションハイジャックができてしまうことが分かりました。

特徴：HTTPセッションハイジャックの対象とする Web サイトを独自に定義できる

HTTP セッションハイジャックを実現するツールは、「Firesheep」だけではありません*1。「Firesheep」の特徴には、HTTP セッションハイジャックの対象とする Web サイトを独自に定義できる汎用性があります。以下に Eric Butler 氏の説明を引用します。

Firesheep is doing the exact same thing as these other tools, but with a simpler user interface. Firesheep is more generic than FBController, but it still needs to be aware of what sites to target.
Firesheep, a day later - codebutler

試しに「ニコニコ動画」の HTTP セッションハイジャックを再現してみました。再現環境は、先ほどの Twitter のセッションハイジャックを再現した環境と同じです。「Firesheep」に同梱されているコードを参考に「ニコニコ動画」のHTTP セッションハイジャックの定義スクリプトを書いてみたところ、「ニコニコ動画」の HTTP セッションハイジャックができてしまいました（下図を参照）。他にも僕が普段使っている Web サービスの一つで、HTTP セッションハイジャックできることを確認しています*2。

無線LAN環境のみで動作するものなのか

「Firesheep」に関連する記事等を読んでいると、認証なく接続できる無線 LAN 環境における悪用の危険性にふれられることが多いようです。ただし、「Firesheep」は有線 LAN 環境でも悪用される恐れがあります。有線 LAN 環境において「Firesheep」が悪用される場合、悪意ある第三者が ARP Cache Poisoning 等により有線 LAN 環境に流れるパケットを盗聴できなければなりません。

試しに有線 LAN 環境において、ARP Cache Poisoning *3を悪用して、「Firesheep」による HTTP セッションハイジャックを再現してみました。下図が再現した様子になります。

この再現環境では、ARP Cache Poisoning により、Host OS の Windows XP SP3（青枠：192.168.0.30）の通信が Guest OS の Windows XP SP3（赤枠：192.168.0.103）を経由して、ゲートウェイ（192.168.0.1）に送信されます。Host OS と Guest OS が保存しているゲートウェイの ARP キャッシュが異なることが橙色の枠から分かります。この状態で、Guest OS において「Firesheep」を起動しておき、Host OS の Google Chrome で Twitter にログインします。すると、「Firesheep」に Twitter の HTTP セッションが表示されてしまいます。

「Firesheep」を使ってみた結果、 HTTP 通信を盗聴できる環境であれば、「Firesheep」は HTTP セッションハイジャックに必要なセッション情報等を、盗聴した HTTP 通信から容易に抽出できるツールと言えます。

Firesheep 対策として採り上げられるツール

「Firesheep」の話題に伴って、関連するブログ記事等で、「Firesheep」による HTTP セッションハイジャックを防ぐツールも取り上げられていました。これらのツールには、以下の 2 つがありました。これらのツールもあわせて調べました。

Firesheep 対策ツール
Web ブラウザで HTTPS 通信を強制するツール

これらのツールを調べた結果から、これらのツールを使ったとしても、Web サイトの作りによっては「Firesheep」による HTTP セッションハイジャックが防げるわけではないと考えました。

Firesheep対策ツール

Firesheep 対策ツールには「BlackSheep」や「FireShepherd」などがあります。「BlackSheep」は、実際にはセッションを確立していない HTTP 通信を送信し、それを検知した「Firesheep」が HTTP セッションハイジャックしようとする行為を検出するツールです。「FireShepherd」は www.facebook.com に対して、定期的に不正な値を設定した HTTP リクエストを送信し、その HTTP リクエストを盗聴した「Firesheep」をエラーで終了させるツールです。

この 2 つのツールの目的は、「Firesheep」そのものの検出、または終了させることだけです。HTTP セッションハイジャックそのものを防ぐものではありません。HTTP セッションハイジャックを防ぐために、これらのツールは意味がありません（個人的にツールの着眼点は好きなんですが）。

「BlackSheep」、「FireShepherd」には興味がなかったため、実際に動作確認をしていません。「BlackSheep」、「FireShepherd」に関しては、M1n0x 氏の記事が参考になります。

Web ブラウザで HTTPS 通信を強制するツール

Web ブラウザで HTTPS 通信を強制ツールには、「Force-TLS」や「HTTPS Everywhere」などがあります。これらのツールの目的は、指定した Web サイトに利用者を強制的に HTTPS で接続させることです。これらのツールが機能するためには、Web サイトが HTTPS 用の Web ページを用意している必要があります。これらのツールをインストールしていると、利用者が対象 Web サイトに誤って HTTP で接続しようとしても、Web ブラウザが強制的に HTTPS で接続させます。例えば、Web ブラウザのアドレスバーに http://www.example.com と入力しても、Web ブラウザが https://www.example.com に接続させることを想像してみてください。

「Force-TLS」、「HTTPS Everywhere」はどちらも目的は同じですが、実装方法が異なります。これらのツールを試した結果*4とツールの説明から、これらのツールの違いを表にまとめてみます。

ツール名	HTTPSを強制するWebサイトの指定	HTTPSを強制する主体	HTTPS を強制する範囲
Force-TLS	HTTP 拡張ヘッダ「Strict-Transport-Security(HSTS)」または「X-Force-TLS」	Webサイト	指定したドメインおよびサブドメインすべて
HTTPS Everywhere	正規表現によるパターンマッチング	利用者	置換したURLすべて

「Force-TLS」や「HTTPS Everywhere」が、HTTP セッションハイジャックを防ぐうえで有効か、考えてみます。なお、ここからの説明は、「HTTPS Everywhere」を基にまとめています。

secure 属性が有効になっていない cookie を使って、HTTPS 通信のみでセッションを維持している場合、Web ブラウザで HTTPS 通信を強制するツールは、HTTP セッションハイジャックを防ぐことに効果があると考えました。別の見方をすると、Web ブラウザで HTTPS 通信を強制するツールによって、HTTP セッションハイジャック防止の効果が得られる Web サイトは限られる、ということになります。僕の誤解、間違い等あるかもしれません。その際はご指摘いただけると嬉しいです。

Cyber Clean Center(CCC) を例にとり、「HTTPS Everywhere」が HTTP セッションハイジャック対策として有効だと考える場合を説明してみます。

CCC の Web サイトに接続すると、HTTP レスポンスにて「BIGipServerpool」という cookie が発行されます（下図を参照）。この cookie は secure 属性が有効になっていないため、HTTP でも送信されることになります。

cookie「BIGipServerpool」をブラウザに保存した状態で、アドレスバーに http://www.ccc.go.jp と入力します。すると、Web サイトから 302 レスポンスコードが応答され、https://www.ccc.go.jp に誘導されます。しかし、HTTP リクエストでは cookie「BIGipServerpool」が送信されてしまいます。HTTP 通信を盗聴できる環境であれば、この HTTP リクエストを盗聴することで、第三者の cookie「BIGipServerpool」を知ることができます。

「HTTPS Everywhere」をインストールして、同じようにアドレスバーに http://www.ccc.go.jp と入力してみます。このとき、http://www.ccc.go.jp を https://www.ccc.go.jp に置換するだけの独自ルールを設定しておきます（下記を参照）。すると、https://www.ccc.go.jp に誘導される点は同じですが、ブラウザは http://www.ccc.go.jp に HTTP リクエストを送信せずに、https://www.ccc.go.jp に誘導されます。これは、ブラウザの内部で https://www.ccc.go.jp にリダイレクトするためと考えます。「HTTPS Everywhere」を使わない場合と比べると、HTTP 通信で cookie「BIGipServerpool」が送信される余地がなくなります*5。

<ruleset name="ccc.go.jp">
  <target host="*.ccc.go.jp" />
  <rule from="^http://www\.ccc\.go\.jp/" to="https://www.ccc.go.jp/"/>
</ruleset>

ちなみに、Web サイトが HTTP 通信と HTTPS 通信ともに同じセッション ID を cookie で送信するように実装していた場合、「HTTPS Everywhere」を使ったとしても、HTTP セッションハイジャックを防ぐことができないと考えます。

HTTPセッションハイジャックを防ぐ

cookie を使って利用者のセッションを維持している Web サイトにおいて、HTTP セッションハイジャックを防ぐためには、Web サイト全体を HTTPS で提供し、かつ cookie の secure 属性を有効にする必要があると考えます。実際に Gmail では、すべての Web ページを HTTPS 通信で提供しています。とはいえ、現実的にすべての Web サイトで、Web サイト全体を HTTPS で提供できるのか？というのが、個人的な思いです。

利用者のブラウザと Web サイト間の HTTP 通信が中継する経路上のネットワークにおいて、盗聴や中間者攻撃（Man-In-The-Middle Attack）等が実施されなければ HTTP 通信でもよいわけです。だけど、現実的な話ではないし、実際にさくらインターネットにおける ARP Cache Poisoning による事件もありました（参考情報）。こういった背景から、HTTPS は重要だと思います。

しかし、Web サイト全体を HTTPS で提供するには、Web サイト管理者に追加で負担が生じます。この負担が生じる理由には、（Web サイトを運用していない僕が思いつくところでは）SSL サーバ証明書の導入と維持、SSL の暗号化と復号に耐えられるパフォーマンス向上等の追加投資があります。利用者の多い Web サイトほど、この負担が大きくなると思います。また、Zscaler Research のブログ記事によると、SSL サーバ証明書に関連する問題もあるようですね。「Firesheep」が対象とする Web サイトにも、すべての Web ページを HTTPS で提供していない Web サイトもあります（Zscaler Research のブログ記事を参照）。以上のことから、現状では Web サイト管理者の裁量によって、どの Web ページを HTTPS で提供するかが決められていると思います。

「Web サイト管理者が、すべての Web ページを HTTPS で提供できるならやる。提供できない場合、重要な情報（アカウント情報や個人情報等）のみ HTTPS 通信で提供して、HTTP セッションハイジャックされることを考慮して、重要な処理を行う場合には再度認証する。」
このあたりが現実的な落としどころなのかなぁと僕は考えました。

参考情報

*1:HTTP セッションハイジャックを実現するツールに関しては、開発者 Eric Butler 氏のブログ記事における [Background on HTTP Session Hijacking] が参考になります。僕はこのブログ記事で紹介されているツールを使ったことがありません。

*2:「Firesheep」の汎用性を確認する目的で、独自のスクリプトを書きました。悪用も可能であるため、この日記では独自のスクリプトを公開しません。

*3:ARP Cache Poisoning には Ettercap NG 0.7.3を使用しました。

*4:「Force-TLS」については HTTP 拡張ヘッダを送信する Web サイトを知らなかったので、試せませんでした。

*5:「HTTPS Everywhere」のルールの書き方に不備があった場合を除きます。