2019 年 6 月 5 日 Emil Hozan 著

セキュリティコンサルタントの PiotrDuszyński 氏が最近、Tor ネットワーク経由であっても訪問者の実 IP アドレスを特定できる方法を発表しました。Tor がプライバシーを守るよう構築されたものであることを考えると、これはプライバシーの重大な問題と言えます。ただし、同氏が発表した方法には、いくつかの前提条件があります。記事の見出しに「Tor」と書きましたが、この脅威は、単に Tor ネットワークの使用に限定されるものではなく、攻撃者が多段階攻撃を使って不正行為を実行できることを示す、わかりやすい例でもあります。順を追って詳しく説明することにしましょう。

具体的な環境要件

簡単に言うと、Tor ネットワークチャネル経由で誰かの IP アドレスを特定するには、次のような複数の条件が必要です。

• Tor ブラウザではなく、標準の Web ブラウザを使用する
• Tor 出口ノードの制御
• HTTP パケットスニッフィング
• HTTP 301 キャッシュポイズニング

これらの条件を個別に検証してから、全体をまとめて検証することにしましょう。

Tor ブラウザではなく、標準 Web ブラウザを使用する

この脆弱性は、標準 Web ブラウザ（Firefox や Chrome など）を使用すること、SOCKS5 プロトコルを Tor ネットワークのプロキシとすることが前提条件となります。したがって、この脆弱性の影響を受ける可能性があるのは、推奨されている Tor ブラウザを使用しないユーザということになります。Tor ブラウザ以外のブラウザの使用を中止すべき理由については、こちらをお読みになることをお勧めしますが、セキュリティ、プライバシー、ネットワークトラフィックの複雑さを十分に理解していない限り、Tor ブラウザを使わずに Tor ネットワークにアクセスするべきではありません。さらには、このネットワークの使用にあたっては、ベストプラクティスに従い、さらに重要なのは、倫理的に行動することです。

以前に掲載した記事で、ダークウェブにアクセスした私自身の経験を紹介し、どのような方法で安全を確保したかを解説したことがあります。具体的には、最初のセクション「調査のきっかけと準備」というセクションで少し詳しく説明していますので、参照してください。この記事では説明しませんが、これ以外にも多くの考慮しなければならない点があります。Tor ブラウザにも、他のソフトウェアと同様に脆弱性が存在し、このビデオで、識別可能情報が漏洩する可能性があるいくつかの例が紹介されています。

出口ノードを制御すれば、トラフィックフローを制御できる

次の、Tor ネットワークのすべてのユーザにとっての大きな問題は、攻撃者に Tor 出口ノードを制御されてしまった場合に発生します。Tor 出口ノードは基本的には、Tor ネットワークと公共インターネットの間のインタフェースです。インターネットの Web サイトへのアクセスには、いくつかの方法があります。ここでは、2 つの方法を例として説明しますが、1 つ目は、Web ブラウザを起動して URL アドレスを入力するか、ドメイン名が分からないために Google 検索を実行し、表示されるリンクをクリックする場合、もう 1 つは、Tor ネットワークからアクセスする場合で、これは、1 つ目の方法のちょっとした変化形です。これら 2 つの方法をもう少しわかりやすく説明したいと思います。

最初のアプローチは、最も一般的でよく利用される方法であり、Web 要求を実行することでネットワークパケットが送信先に送られ、その後に送信先からネットワークパケットが送られてきます。この場合、送信元と送信先の識別子は、IP アドレスと呼ばれ、これによって、公共インターネットでユーザが一意に識別されます。これは、最も単純化した説明であり、実際にはさまざまな処理が実行されます。

ところが、Tor ネットワークを経由すると、Tor ネットワークのリレーサービスをホスティングしている他のサーバを経由してから最終ノード（出口ノード）に到達することで、目的とする Web サイトへの接続が完結します。この出口ノードは、ユーザのネットワークパケットが Tor ネットワークと最終的な目的地である Web サイトの間を往復するためのインタフェースであり、ユーザに戻るための入口でもあります。中間のいくつものホップを通ることで、パケットに匿名性が追加されます。このプロセスでは他にもいくつかの処理が実行されますが、それについては、以前のブログ記事をお読みください。

確実に言えるのは、悪意ある攻撃者が出口ノードを制御している可能性があるという事実は、Tor ブラウザを使用しているかプロキシにしているかのどちらであっても、好ましい状況ではないということです。

HTTPS ではなく HTTP

さらには、我々が長年にわたって慣れ親しんできた HTTP トラフィックを盗聴する必要もあります。簡単に言うと、最近の HTTPS 以外のすべてに、中間者攻撃（MiTM）に対する脆弱性が存在し、これは頭の痛い問題です。HTTPS のセキュアを意味する「S」は、想定した受信者との通信であること、そして当然ながら、通信がハッキングされなかったことを保証するものです。HTTPS の世界では、Web サイトへのアクセスにデジタル証明書が使用されます。あるドメイン名を登録し、あなたがその所有者であることを証明する場合の具体的な手順としては、最初にドメイン名を登録し、あなたのアイデンティティが確認された後に、デジタル証明書を発行してくれる会社にそのドメイン名を提出します。そして、この証明書をセキュア接続で使用することで、あなたが指定したホスト名との通信であることを訪問者に保証します。

ここで、誰かがあなたのネットワーク通信に侵入し、あなたの通信を傍受しているとしましょう。HTTP 経由で要求を送信する場合、要求は、攻撃者（MiTM）を通過した後にエンドポイントに送られます。HTTP 経由で送信されるデータはすべて平文であるため、パケットにアクセスできれば誰でも内容を読み取ることができます。さらに大きな問題として、返された応答を攻撃者が操作し、攻撃者の意図に沿って編集された内容が表示される可能性があります。Web 開発者向けのデバッグなどの正当な目的でこの方法が利用されることもあります。

HTTPS 経由で Web サイトにアクセスする場合は、基本的にはそのドメイン名にアクセスし、そのドメインから、「Web サイト example.com からの応答ですよ」という内容のデジタル証明書付きで応答が返されます。その証明書が付いていれば、証明書の信頼チェーンが正当なものであることを意味するため、そのサイトは自らの正当性を証明するためのハードルを越えたことになります。証明書を使用する大きなメリットは、何かが欠落しているという赤信号を Web ブラウザが教えてくれることです。そのような（正当な）赤信号の1つが、自己署名証明書の警告です。これは、企業の正当性を確認してデジタル証明書を発行する、信頼できる団体である認証局ではなく、サーバが自らのデジタル証明書を作成している場合に、このような警告が通知されます。Web ブラウザはサイトの証明書を要求しますが、信頼できる発行元ではなく、自己署名されたものであることを知らせる警告が表示されます。HTTPS 対応の Web サーバでアプリケーションを開発したりサービスをホスティングしたりする場合や、信頼できる友人がそれらのサービスをホスティングしている場合は、おそらく、自己署名証明書を使用することになるでしょう。そして、このような場合であれば、自己署名ブラウザの警告表示を無視しても構いません。

脅威を完成させる条件

これまでの説明では、実際にどのような方法で脅威が完成するかを理解するために、個々の要件について検証してきましたが、このプロセスを完成させるには、繰り返しになりますが、この脆弱性を悪用して Tor ネットワーク経由で非 HTTPS Web サイトにアクセスし、それと同時に、攻撃者が出口ノードを制御することで、不正 HTTP 301 を送信先サーバからユーザに返される応答にインジェクションする必要があります。これらのリダイレクトはキャッシュされるため、自分のコンピュータのローカルに保存されます。

ユーザが Tor ネットワークを抜け、少し時間が経過してから同じページを要求すると、そのユーザ専用に作成された、攻撃者が制御しているサーバへの不正なリダイレクトが発生します。結果として、そのサーバは、他の情報と一緒にそのユーザの IP アドレスを収集でき、そのサーバを制御している犯罪者がそれを利用できるようになります。

結論と対策のヒント

まず始めに対策のためのヒントを紹介してから、この記事のまとめに移りたいと思います。

この状況の潜在的な深刻さを決して軽視すべきではありません。HTTP 今も使用している正規のサイトが存在します。理由は不明ですが、今も存在するのは事実です。ここでの主な対策は、HTTP を使用して Web サイトにログインしないようにすることでしょう。やむを得ず使用する場合は、異なるメールアドレスとパスワードの組み合わせを利用することを強く推奨します。

Tor を使用すれば、プライバシーが保護されると多くの人が考えるはずであり、ほとんどの場合にそれは誤りではありません。しかしながら、悪意ある誰かが出口ノードを制御するという要件を満たすと、Tor の本来の目的が失われることになります。これには、Tor プロジェクトによる出口ノードのプログラムミングとパッケージングの方法に関係しますが、残念ながら、彼らであっても、意図を持って行動する脅威の実行者による自らのサーバの操作を制御することはできません。つまり、参加するリレーが信頼できる問題のないものであることを前提に成立し、自主性が尊重される、自主管理型システムのアプローチであると考える必要があるでしょう。

これらの点が問題を生じさせる原因になる可能性は十分にあり、実際には、Tor だけでなく、VPN やプロキシサービスをホスティングする攻撃者にもおそらく同じことが言えます。このようなサービスで、不正行為を行っていないこと、たとえば、サービスが実 IP アドレスを記録していないこと、また、それ以外の方法でサービスがユーザを追跡していないことをどのように確認できるのでしょうか？

そこで、対策の最終手段として、Tor ブラウザを使用することが重要になります。JavaScript、Cookie、キャッシュ、あるいは動作中のプラグインは、サイバーセキュリティにおいて重要な役割を果たしますが、Tor ブラウザはユーザのプライバシーを重視するとされています。そこで、JavaScript を無効にし、Webブラウザを閉じる際に Cookie とキャッシュを削除してから閉じて、再度開くことで、以前のセッションの静的な情報な残らないようにするか、最初から Tor ブラウザを使うようにすることが、対策の重要なヒントとなるでしょう。これを一歩進めて、オペレーティングシステムのレベルの匿名性を検討する方法もあり、その場合は、Whonix と Tails の 2 つの選択肢があります。

最後に申し上げたいのは、どのようなエクスプロイトにも考慮しなければならない要素が本当にたくさんあるということであり、そのような要素の複雑さをすべて理解するのは現実的ではないということです。どのような対策を講じたとしても、発見されていない（あるいは、発見されても公開されていない）ソフトウェアの脆弱性のエクスプロイトの方法が存在する可能性はあり、たとえば、ゼロデイマルウェアや多段階攻撃はこれに該当します。強い意志を持って攻撃を仕掛ける人がいることを考慮し、自分の行動に十分に注意し、利用可能な保護対策を最大限に活用することが重要です。