2016年3月16日
HTTPレスポンスのgzip圧縮による日時リーク : Torの秘匿ネットワークの秘匿性を脅かす仕様・実装について
本記事は、原著者の許諾のもとに翻訳・掲載しております。
Torの秘匿サービス
Tor は、ボランティアネットワークが運営している、匿名でインターネットが利用できるサービスです。通常、Torは、追跡されたり特定されたりすることなくWebブラウジングするために利用されます。
あまり知られていないTorのサービスの特徴の1つは、Torにおいて 秘匿サービス として知られているものを提供する能力です。秘匿サービスは、基本的にTorネットワークを通じてサービスを提供するサーバです。Torを考えたときに最初に思い浮かぶものは、匿名でのWebブラウジングでしょう。しかし、ハクティビストや反体制派の人々にとっては、特定されることなくWebブラウジングできるだけでなく、簡単に追跡されたり閉鎖されたりすることなしにWebページを提供できる点が、非常に便利なのです。
Torネットワークにおいては、Torネットワークの利用者だけがアクセスできる数千の「秘匿サービス」があります。これにより、幅広い話題の禁じられた情報にアクセスすることが可能になります。これらのサイトは、example.onionのようなトップレベルドメイン.onionが付いた秘密のDNSアドレスを持っています。.onionで終わるサイトは、簡単に追跡したり閉鎖したりできません。また、オーナーは、簡単に特定されません。
秘匿サービスのセットアップで最も複雑な作業の1つは、サーバの真のIPアドレス情報が漏れないWebサーバの設定です。サイトが複雑であればあるほど、何があってもサービス情報が漏れない本当の秘匿サービスのセットアップは、より困難になります。
過去数年間、FBIは、なりすましや情報漏えい、ブラウザの脆弱性を利用して、ある複数の秘匿サービスを特定し、閉鎖することに成功しました。最も有名な例は、 シルクロード です。これは、Torの中に隠れた有名な闇市場で、ここで薬物の類が販売されていました。
もちろん、秘匿サービスの裏で、管理者たちは、サービスを提供しているサーバの物理的場所についての情報や、秘匿サービスのオーナーの特定に結び付く情報が漏れないよう、最善を尽くしています。
タイムゾーンのリーク
HTTPプロトコルによって、クライアントは、圧縮能力をサーバに知らせることができます。クライアントとサーバが同じ圧縮フォーマットをサポートしている場合、サーバは、帯域幅と時間をセーブするために、HTTPレスポンスを圧縮することができます。全ての主なWebサーバとブラウザは圧縮をサポートしています。 HTTP圧縮 で使われる最も一般的なフォーマットは、 gzip と deflate です。
gzipは比較的高速で、正確な圧縮比での圧縮が可能な、データ圧縮フォーマットです。
圧縮フォーマットとして、gzipは圧縮データにデータヘッダが含まれるよう指定します。このヘッダには、圧縮データの情報、データを圧縮したオペレーティングシステムの他、最も重要な情報、 データが圧縮された日付 が協定世界時(UTC)にのっとって記録されています。
Forensics Wiki を見ると、ヘッダは次の通りです。
オフセット | サイズ | 値 | 内容 |
---|---|---|---|
0 | 2 | 0x1f 0x8b | gzipのストリームを見分けるマジックナンバー |
2 | 1 | 圧縮メソッド | |
3 | 1 | フラグ | |
4 | 4 | 圧縮日 | |
8 | 1 | 圧縮フラグ | |
9 | 1 | オペレーティングシステム |
よって、このヘッダがgzip圧縮データに付いていれば、適当なWebサーバにgzip圧縮リクエストを出し、gzip圧縮レスポンスを待って、バイト数が0x1f 0x8bで始まっているかどうかということと、正確な圧縮日を確認できるのです。
一般的なWebサーバでは、これは非常に限定的なシナリオにおいてのみ有用です。なぜなら、サーバの地理的な位置はいずれにしても隠されず、これもまた隠されていないサーバIPアドレスが分かればすぐに特定されるからです。しかし、 秘匿サービス では、サーバの時間帯に関する情報は、サーバが稼働している可能性のある国を特定するのに非常に役立ちます。
gzipの仕様を見れば、ファイル更新時間のヘッダフィールドには、ローカル時刻ではなく、世界時を使用すべきことは明確です。しかし、多くのサイトが世界時の代わりにローカル時刻を送信しています。どうもMicrosoft Windows内の欠陥が原因 かもしれない 、と思えるのですが、どの機能が仕様に沿わず、ローカル時刻をリークしているのかをはっきりさせるには、さらなる調査が必要です。これは当然 Torのせいではありませんし、Torのプロトコルのバグでもありません。 また、 gzipの仕様の問題でもないのです。 ある動作のせいです。ベンダーたちによって間違って実装され、多くのWebサーバにおいて初期設定のままのHTTPプロトコルで使えるようになってしまった、gzipフォーマットのあいまいな機能が原因なのです。
良いニュースは、多くのWebサーバでは、gzipの日付フィールドを’0’で埋めるようあらかじめ設定されていることです。理由は分かりませんが、おそらくパフォーマンスの観点からでしょう。少しリサーチをしてみたところ、Webサーバの約10%がHTTPレスポンスをgzipで圧縮する際に遠隔日時をリークしていることが分かりました。また、ヘッダに遠隔日時を内包する数少ないサーバも、ローカル時間の代わりに世界時を使うことをしていないのです。
クロックスキューによる特定
しかし、ローカル時刻ではなく世界時を送信している、つまりファイル更新時間をゼロで埋めず正しく世界時を送信する場合でさえ問題があります。正しい世界時を送信すると、クロックスキュー攻撃による特定がされやすくなるのです。 Murdoch, 2006 による以前の報告を読んでみてください。
このシナリオでは、正しいgzipの実行で提供される世界時は、攻撃開始のための別のサイドチャネルでしかありません。
コンセプトの証明
gzip圧縮HTTPレスポンスに遠隔日時が含まれていればそれを取得する、小さなPHPスクリプトをcurl(コマンドライン)を使って開発しました。HTTPレスポンスの圧縮ができ、かつgzipヘッダの’date’フィールドにゼロではない正確な日付を埋め込むWebサーバでのみ機能します。
いくつかのサーバでテストしたところ、日付がgzipヘッダに送られたのは instagram.com 、 reddit.com 、それから bing.com でした。この例では、 reddit.com と instagram.com は仕様通り、世界時を送信しました。 bing.com が送ったのはローカル時刻でした。
もちろんプライバシーの懸念があるので、どの秘匿サービスが遠隔日時をリークしているかについて情報提供はしません。
使用例:
user@localhost:~$ php time.php bing.com
The server that processed the request on: bing.com has local date set to:
Sunday 21st of February 2016 01:21:21 PM
user@localhost:~$ php time.php reddit.com
The server that processed the request on: reddit.com has local date set to:
Sunday 21st of February 2016 09:21:25 PM
user@localhost:~$ php time.php instagram.com
The server that processed the request on: instagram.com has local date set to:
Sunday 21st of February 2016 09:21:30 PM
user@localhost:~$
この例では、3つのサーバ全て、gzipヘッダの中に時刻を含んでいますが、 reddit.comとinstagram.com は世界時を、 bing.com はローカル時刻を送っています。
コンセプトの証明はこちらで。
https://github.com/jcarlosn/gzip-http-time
Tor自体のgzip
Torプロトコルそのものが、複数の伝達のためにgzipを使っています。しかし、Tor-onionsメーリングリストでWison-Brownが述べているようにこの件は既に知られていることで、Tor開発の際に考慮に入れられていました。
Tor自体には、内部でgzip圧縮を使ってディレクトリドキュメントを圧縮しているものの、そのことによる問題はありません。秘匿サービスとクライアントはディレクトリドキュメントを生成したり、再圧縮したりしないので、影響を受けることは絶対にないのです。Torのオーソリティは多数決により、圧縮の初期化にgzipヘッダにゼロを設定するdeflateInit2を使っています。下記はzlib.hのdeflateInit2ドキュメンテーションの引用です。
“windowBitsもオプションのgzipエンコーディングでは15より大きいことがあります。単純なgzipヘッダを記述し、zlibラッパーでなく圧縮データに従うよう16を追加してください。gzipヘッダにはファイル名、余剰データ、コメント、更新時刻(ゼロ設定)、ヘッダCRCはなく、オペレーティングシステムは255(未詳)に設定されます。gzipストリームが書かれる場合、strm->adlerはadler32ではなくcrc32です。”
これに関する全ての会話は、 tor-onions メーリングリストで見られます。
謝辞
この潜在的な問題を見つけた時から、それが遠隔であってもTorユーザのプライバシーに影響を及ぼすのではと心配でした。この問題の原因と、gzipの仕様が世界時を指定しているのに、いくつかのサーバがローカル時刻を送っているのはなぜなのか、少々理解し難かったです。この気付きをシェアしたばかりで混乱していた頃でさえ、誰にも言わず自分だけで影響を理解しようとするより、オープンに議論したほうが建設的だと考えていました。onion Torメーリングリストに連絡を取り(実際そうしました)、この記事を拡散して注意を喚起し、これが問題になり得るのか理解する助けを得ることが自分の責任だと思ったのです。
議論に加わり、本件に関する追加情報を集め、この問題が及ぼす可能性のある影響を明確にする手助けをしてくれたHDM、brlewisとHenryk Plotzに感謝します。
最終更新: 2016年2月22日 8:50:16 PM UTC。数ヶ所の誤り訂正とコメント欄からの情報追記。
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa