どうしてもそのようなネットワークを使わなければならない場合は、TunnelVisionに対応済みだということが分かっているVPNプロバイダーを使うべきだ。

　研究者によれば「Android」は後ほど説明するDHCPのオプション121を実装していないため、TunnelVision攻撃を受けることはない。

VPNを利用する企業ができること

　企業のユーザーは自宅はもちろん、喫茶店やホテル、空港などからVPN接続を使うことがあるだろう。企業のネットワーク管理者は「このような場所での作業にはリスクが伴うため、可能な限り避けるべきだ」ということを従業員に伝えなければならない。そのような運用ポリシーが現実的でない場合、管理者は、以下で示す緩和策や修正策を可能にするVPNを使用するよう従業員に伝えるべきだ。信頼できるホットスポットを使用してからVPNに接続するようにポリシーを定めるのもよい。なお、仮想化DHCPサーバからリースを取得する仮想マシン（VM）の内部でVPNを実行すれば、ローカルネットワークのDHCPサーバが後ほど説明する危険なルートをインストールすることを完全に防止できる。つまりTunnelVisionの影響を受けなくなる。

　なお、TunnelVisionが利用するDHCP機能のサポートを削除することは、TunnelVision攻撃の解決にはつながらない。なぜなら、一部の正当なケースでインターネット接続を壊す可能性があるからだ。

　自社でネットワークを管理している企業やサイト間VPNを利用している企業は利用中のスイッチを見直して、DHCPスヌーピングやARPプロテクションなどの機能を有効にすべきだ。 これらの機能でレイヤー2を保護することができ、不正なDHCPサーバを防ぐ際に役立つ。だが、これらの方法ではTunnelVisionを使った攻撃のうち、不正な管理者のシナリオを排除することはできない。もう一つの対応策は、内部リソースを暗号化したHTTPSやその他のプロトコルを導入することだ。信頼できないネットワークから接続するVPNユーザーからのデータ漏えいを防止できる。

VPNプロバイダーができること

　研究チームが最も強く推奨するのは、VPNプロバイダーがWireGuardのドキュメントに記載されている方法と同様に、ネットワーク名前空間をサポートしているOSに実装することだ。WireGuardとはVPNを実装するための安全で高速なネットワークプロトコルおよびそれに関連するソフトウェアのことだ。なお、ネットワーク名前空間は「Linux」の機能であり、ローカルネットワークの制御からインタフェースとルーティングテーブルをセグメント化できる。

　VPNプロバイダーはTunnelVisionに対する緩和策や修正策に関する文書を公に提供し、ユーザー企業の管理者やエンドユーザーにTunnelVisionの存在について警告すべきだ。また、マーケティング資料を見直し、VPNが信頼されていないネットワークであっても顧客を保護できるという主張を、実際に証明されるまで中止した方がよいだろう。

　技術的にはネットワークインタフェースへのアウトバウンドパケットをドロップするファイアウォールルールを設定する機能をユーザーに提供することが対策になる。だが、この対策には副作用がある。VPNユーザーがローカルネットワークリソースとのやりとりから隔離されてしまうからだ。もしVPNクライアントがLinux用で、かつ完全なトンネルを想定しているのであれば、隔離のためにネットワーク名前空間を使う。

　なお、リジー・モラッティー氏とダニー・クロンセ氏はVPNプロバイダーの対策が有効かどうかを、依頼があれば研究室でテストできるという。

コンピュータネットワークとVPNの仕組み

　TunnelVision攻撃の動作を理解するには、ネットワーク技術についてのある程度の理解が必要だ。そこで具体的な攻撃手法に入る前に、必要な技術をおさらいしておこう。コンピュータネットワークについては囲み記事で紹介した。攻撃の実際を知りたい読者は記事の2ページ目に進んでほしい。

• そもそも2台のPCはどのように通信するのか（囲み記事）
• 仮想ネットワークインタフェース
• VPNと暗号化の意味
• VPNと仮想ネットワークインタフェース
• VPN通信と通常の通信の違い
• ルートとルーティングテーブル
• DHCP
• DHCPのオプション121

そもそも2台のPCはどのように通信するのか

　VPNの動作を理解するにはコンピュータネットワークの基本を学ぶ必要がある。コンピュータネットワークとは、互いに接続されて、データを送受信できるPCのグループのことだ。

　最も単純なのは2台のPCをイーサネットケーブルで接続してネットワーク化したものだ。このときPC同士は、プロトコルと呼ばれるルールを使って「会話」する。プロトコルにはそれぞれ目的があり、レイヤー（層）ごとに動作する。

　それぞれのレイヤーは異なるタイプの問題を解決することを目的としており、上位レイヤーや下位レイヤーで何が起こっているのかを知る必要がないように設計されている。これをカプセル化と呼ぶ。例えばWebブラウザ（HTTP）より下位のレイヤーでケーブル（同軸）を用いて電気を送る方法がどのように決まり、誰と話すべきか（イーサネット、IP）を知る必要はユーザーにはない。それでも受信サーバ（TCP）への正しいデータ配信が保証されていることを信頼できる。各レイヤーによってパッケージ化されたデータをパケットと呼ぶ。

|レイヤー|説明|何に例えられるか|プロトコル|

|---|---|---|---|

|アプリケーション層|受信者に送信する実際のデータを決定する|郵送される手紙のページ上の文字|http、dns、https、dhcpなど|

|トランスポート層|ホスト上のプロセスと受信者上のプロセスとの間でエンドツーエンドの通信を確立する|特定のアパート番号に配達される手紙|TCP、UDP|

|ネットワーク層|送信元システムから宛先システムへ、インターネットを介してトラフィックを送信する|都市内の1つの建物に手紙を配達する|IP、ARP|

|データリンク層|同じローカルネットワーク上のシステム間のトラフィックを制御する|郵便局のトラックが、郵便物をあちこち、あるいは街から街へと運ぶ|イーサネット|

|物理層|銅線や電波（Wi-Fi）などの物理媒体上でデータをエンコードする方法を決定する|物理的に手紙を書いて封筒に入れること|光ファイバー、同軸、衛星、マイクロ波|

TCP/IPにおけるレイヤーの内容

　レイヤーの次はネットワークインタフェースだ。ネットワークインタフェースとして分かりやすいのは、PCのマザーボードに取り付けられた無線ボードやネットワークボードなどの物理的なデバイスだ。これらのデバイスを使って、PCは物理的な媒体（銅線、光ファイバーケーブル、無線など）を介してデータのビット列を伝送できる。ネットワークインタフェースは、PC同士が距離を越えて通信するためのもので、ネットワーキングの基本的な部分だ。

　ネットワークインタフェースには2種類ある。物理ネットワークインタフェースと仮想ネットワークインタフェースだ。どちらのタイプのインタフェースもカプセル化に対応するように設計されているため、上位のレイヤーから同じようにやりとりできる。

　ユーザー側にあるVPNクライアントとサーバはそれぞれ仮想ネットワークインタフェースを利用する。物理的なハードウェアを使う代わりに、仮想ネットワークインタフェースはファイルディスクリプタを作成し、アプリケーションソフトウェアから読み書きできるようにする。OSとアプリケーションソフトウェアとの間でファイルに関する情報を伝えるためのインタフェースをファイルディスクリプタ（記述子）と呼ぶ。ファイルディスクリプタはホストのメモリにしか存在しないため、仮想ネットワークインタフェースは、トラフィックが物理的な媒体で伝送される必要のない図Aのような仮想化環境で特に有用だ。

図A　仮想マシン間のトラフィックがホストから外に出ることがない場合（提供：Leviathan Security）

　ユーザーが物理媒体上でトラフィックを送信できる仮想インタフェースが必要な場合もあるだろう。そのような場合、仮想インタフェースを物理ネットワークインタフェースでバックアップできる。このとき実際には仮想インタフェースが外向きのアウトバウンドトラフィックを図Bのように物理ネットワークインタフェースに転送する。

図B　物理インタフェースにバックアップされた仮想インタフェースの例（提供：Leviathan Security）

　VPNの特徴はもう一つある。カプセル化技術を使って通信データを保護することだ。カプセル化とは送信元のデバイスでデータをカプセル（通常はヘッダとペイロードを含む）に包み、受信側のデバイスでそれを開封するプロセスだ。カプセル化によってデータは暗号化され、送信中に起こるかもしれない改ざんや盗聴から保護される。

　VPNを使うとユーザーはホストデバイスと別のネットワークにあるサーバとの間にネットワークトラフィックのトンネルを作って通信できる。この場合、仮想ネットワークは地理的な制約を受けず、物理的なネットワークと同じように動作する。

　VPNクライアントは仮想ネットワークインタフェースを作成し、物理ネットワークインタフェースに送信する前に、必要なファイルディスクリプタを使用して、上位レイヤーでトラフィックを暗号化、復号する。

図1　単純なVPN構成の例　ユーザーは異なるネットワーク上のリソースにVPNを介してアクセスできる（提供：Leviathan Security）

　VPNを使うことは全く難しくない。ほとんどの場合、設定を終えるとサーバ接続するには、ログインしてボタンをクリックするだけだ。それ以外は必要ない。

（1）VPNクライアントで必要な設定を選択する
（2）接続ボタンをクリックする
（3）ログインする（クライアントによってはオプション）
（4）接続先のVPNからの確認を読む
（5）VPNからリモートリソースを利用する

　サイバー攻撃の観点で重要なのは、VPNを利用すると低レイヤーのネットワークトラフィックがインターネット経由で送信されることだ。つまり攻撃対象が増えてしまう。

　VPNはインターネットでローカルエリアネットワーク（LAN）を作り上げるために、低レイヤーを高レイヤーの中にカプセル化する。一般的にLANトラフィックはインターネット経由で送信されるトラフィックよりも特権的だ。つまりLANにアクセスできる攻撃者はLANの外部にいる攻撃者よりも受動的、能動的な攻撃手法を使いやすい。VPNはLANの攻撃対象領域を外部の攻撃者にも広げることになる。これは危険だ。そのためVPNはパケット暗号化などの補正制御を使うことで、攻撃されやすさをカバーしている。

　研究チームによれば、この点はVPNに関してよく誤解されているのだという。VPNで暗号化を利用する理由は、物理的なLANを使用する際のセキュリティを高めるためではない。先ほど記したようにVPNがインターネットで仮想化されたLANを構築する際に起こるリスクを軽減するためだ。VPNのマーケティング資料などに書かれていることとは異なり、VPNは物理LANで起こるローカルネットワーク攻撃からユーザーを守ることはできない。

VPNはどのやって仮想ネットワークインタフェースを使うのか

　VPNクライアントは仮想ネットワークインタフェースに関連付けられたファイルディスクリプタから受信したパケットを暗号化したものを作成する。この暗号化されたペイロードをVPNプロトコルのレイヤーに置き、VPNサーバと通信する。

　次の表でパケット1はVPNで暗号化される前のもの、パケット2は暗号化後のものを表す。アドレスは一例だ。ここでは「OpenVPN」を利用した。

　TunnelVisionの攻撃手法を紹介するために、VPNではどのようにパケットがVPNサーバに送信されるのかについて手順を図2にまとめた。この手順はリジー・モラッティー氏とダニー・クロンセ氏が可能な限り詳細に図解したものだ。通信手順は左上の「Send Payload 1」から始まる

図2　VPNのデータフロー図　1～28の順に動作する。青線がユーザーからの送信時、オレンジの線が受信時の動作を示す。Linuxホストを利用した場合であり、図の上部からユーザー空間、カーネル、ハードウェア、インターネットに分かれている。右下には有線接続を利用したときのネットワークインタフェースやドライバの位置を示した（提供：Leviathan Security）

　図2の1～28の動作を簡単に説明すると次のようになる。

（1）アプリケーションプロセスが、作成したソケットにペイロードを送信する
（2）ソケットはペイロードをパケットにフォーマットした後、どのインタフェースを経由して送信するべきなのかを決定するために、ルーティングテーブルに送信する
（3）この場合、ルーティングテーブルはパケットをtun0経由で送るべきだと判断する
（4）ルーティングテーブルはパケットをファイアウォールに送る
（5）ファイアウォールのルールがパケットをtun0に送ることを許可する
（6）ネットワークインタフェースはパケットをシリアライズした後、ユーザーランドの/dev/net/tunのファイルディスクリプタに書き込む
（7）VPNクライアントプロセスはファイルディスクリプタ内にある暗号化されていないパケットの生バイト列を読み取る
（8）VPNプロセスは暗号化されたペイロードを作成して、VPNが作成したソケットに送信する
（9）ソケットはそのペイロードをVPNのサーバ宛のパケットに整形した後、ルーティングテーブルに送信する
（10）ルーティングテーブルはこのパケットがwlan0インタフェース経由で送られなければならないと判断する
（11）ルーティングテーブルがパケットをファイアウォールに送る
（12）ファイアウォールルールによって、アウトバウンドパケットがwlan0を使い続けてもよいと決定される
（13）ネットワークインタフェースがパケットをWi-Fiドライバに転送する
（14）Wi-FiドライバがVPNバウンドパケットを物理ネットワークインタフェースカード（NIC）に送る
（15）パケットがインターネットを経由してVPNサーバに送られる
（16）VPNサーバが物理NICに応答パケットを送り返す
（17）NICが応答パケットをWi-Fiドライバに送信する
（18）Wi-Fiドライバがレスポンスパケットをwlan0に送信する
（19）応答パケットがファイアウォールに送られる
（20）ファイアウォールのルールがパケットの継続を許可する
（21）パケットがVPNソケットに返される
（22）ソケットはパケットを受信し、パケットの暗号化されたペイロードをVPNクライアントプロセスに送信する
（23）VPNクライアントプロセスはペイロードを復号し、暗号化されていないレスポンスパケットのrawバイトをファイルディスクリプタに書き込む
（24）tun0インタフェースがファイル記述子からバイトをデシリアライズして、パケットにフォーマットする
（25）tun0インタフェースがパケットをファイアウォールに送る
（26）ファイアウォールのルールがパケットの継続を許可する
（27）パケットはユーザーのアプリケーションプロセスによってオープンされたソケットに返される
（28）パケットのペイロードがアプリケーションプロセスに返される

VPNを使うと通信はどのように変化するのか

　VPNを利用すると、利用していない場合と比べて通信はどのように変わるのだろうか。ユーザーがVPNサーバに接続すると、VPNクライアントプロセスはホストが確立したトンネルを経由してトラフィックをルーティングするように設定する。全てのトラフィックがVPNを通してルーティングされる場合を、リジー・モラッティー氏とダニー・クロンセ氏は「フルトンネルVPN」と呼ぶ。ローカルネットワークのトラフィックなど、トラフィックにユーザー定義の例外がある場合は、「スプリットトンネルVPN」と呼ぶ。VPNクライアントは、ホストのファイアウォールなど、ホストの他の設定も実行できる。

　一般的にこれらの設定変更は、VPN接続の確立時や切断時に「アップスクリプト」や「ダウンスクリプト」によって実行される。また、VPNクライアントのランタイムプロセスでも設定を変更する場合がある。これはVPNのベンダーごとによって異なる。

　なお、「全てのトラフィック」とは、「VPNを動作状態に保つために必要なトラフィック以外の全てのトラフィック」という意味だ。例えば、VPNは事前に設定したルーティングルールに例外を設けている。VPNサーバのIPアドレスに送られる全てのトラフィックは、それ自身のトンネルではなく、ハードウェアでバックアップされたインタフェース経由で送られなければならない。そうしないと、VPNサーバへのホストの接続が切れてしまい、VPNクライアントは暗号化されたパケットを送信できなくなるからだ。さらに、VPNはホストのIPアドレスリースを維持する必要があるため、DHCPトラフィックのための例外設定がある。

ルートとルーティングテーブルはどう役立つのか

　ルートとは宛先に基づいてトラフィックの送信先を記述する方法だ。ルーティングテーブルはネットワークスタックによって使われるルートの集合だ。どちらも図2の中央左に茶色の四角形として描かれている。ネットワークスタックとはネットワークからのデータの送受信を扱うOSの全てのコードのことだと理解してよい。

　一般的なルートは全てのトラフィック（CIDR：クラスレスドメイン間ルーティングの表記で0.0.0.0/0）を物理ネットワークインタフェース（eth0）を介してルーター（192.168.1.1）に送ることだ。この情報を次のように表す。

0.0.0.0/0 via 192.168.1.1 dev eth0

　複数のルートがあるとき、どうやって選択するのだろうか。特別な設定がない限り、プレフィックス長の数値が最も大きいものが、ルーティングの選択で優先される。具体的にはCIDR範囲のプレフィックス長で判断する。192.168.1.1/32の範囲のプレフィックス長は32であり、0.0.0.0/0の範囲のプレフィックス長は0だ。

　次の例では10.10.10.2にトラフィックを送った場合、/32ルールが選ばれる。

0.0.0.0/0 via 192.168.1.1 dev eth0
192.168.1.1経由で10.10.10.1/24 dev wifi1
192.168.1.2経由で10.10.10.2/32 dev eth0

　ほとんどのフルトンネルVPNは、全てのトラフィックを捕捉するために、可能な限り特定性の低いルールを使用する。次の例では、仮想的なVPNのサーバアドレス（12.34.56.78）の例外ルートも含まれている

>> 0.0.0.0/0 via 10.13.37.1 dev tun0
>> 12.34.56.78/32 via 192.168.1.1 dev eth0

　あるいは、プロバイダーは2つの/1ルールを使って、デフォルトルートより優先させることができる。DHCPが物理ゲートウェイへのデフォルトルートを設定するのは、敵対的でない環境でもよくあることだという。

0.0.0.0/0 via 192.168.1.1 dev eth0
10.13.37.1経由で0.0.0.0/1 dev tun0
128.0.0.0/1 via 10.13.37.1 dev tun0
192.168.1.1経由で12.34.56.78/32 dev eth0

DHCPとは何か

　TunnelVision攻撃ではDHCPを悪用する。そこで、DHCPについても触れておこう。

　DHCPはもともと、ローカルネットワークにあるデバイスにIPアドレスを動的に発行する確実な方法として開発された。最近のOSはほぼ全て、IPアドレスを自動的に要求するDHCPクライアントを備えている。

　DHCPは有効期間を決めてIPアドレスをリース（提供）する。さらにリモートで動的にデバイスの設定を調整できるオプションと呼ばれる多くの追加機能を含んでいる。よく使われるオプションには、インターネットへのプライマリールートとして機能するデフォルトゲートウェイの設定や、「google.com」のようなドメイン名をIPアドレスに解決するDNS（ドメインネームシステム）サーバの設定などがある。

　インターネット接続をするためにIPアドレスが欲しいクライアントは、ブロードキャストを使ってローカルサブネット全体にDHCPDISCOVERパケットを送る。他のホストはこれを無視するが、サーバはDHCPOFFERを直接クライアントにユニキャストして応答し、期限付きのリースを提供する。

　クライアントがDHCPサーバを「知っている」場合、ブロードキャストの代わりに DHCPDISCOVERをDHCPサーバにユニキャストするオプションもある。

　DHCPサーバがオファーを出すと、クライアントはそのオファーを受け入れるのか拒否するのかを選択できる。つまり、複数のオファーを受け取った場合、クライアントはその中から最適なものを選択する。多くの場合、DHCPクライアントは「早い者勝ち」の選択をすることが多い。選択されなかったサーバにはDHCPDECLINEメッセージがクライアントから送信される。ここにTunnelVision攻撃の足掛かりがある。DHCPOFFERに含まれるオプションの悪用だ。

DHCPのオプション121とは何か

　1997年に制定されたDHCPのRFC（リクエストフォーコメント）には、あるオプションが含まれていた。このオプション33を使って、ネットワーク管理者はクライアントのルーティングテーブルに静的ルートを指定できた。しかし、この方法ではクラスフルな静的ルートが使用されていたため、公衆IPアドレス空間が限られてくるにつれて、次第に使われなくなった。2002年に「RFC 3442」によってオプション121（クラスレス静的ルート）が導入されて、オプション33は廃止された。

　オプション121では、管理者がクライアントのルーティング テーブルに静的ルートを追加できるようになったものの、クラスレスな範囲を使用する。なお、一度にインストールできるルートの数には、パケットサイズ以外の制限はない。

　オプション121ではインストールするルートのネットワークインタフェースデバイスをDHCPサーバで指定できない。図3は「Wireshark」でキャプチャーしたDHCPOFFERパケットの様子だ。CIDR範囲と使用するルーターが指定されているが、インタフェースデバイスは指定されていない。

図3　オプション121ルートを含むDHCPOFFERパケットの様子（提供：Leviathan Security）

　その代わりに、DHCPクライアントはこのオプションのルーティングルールをインストールする際に、DHCPサーバと通信しているネットワークインタフェースを暗黙のうちに選択する。これが攻撃の糸口だ。