TunnelVision攻撃とデクローキング

　TunnelVision攻撃の要点はVPNのカプセル化をバイパスするネットワークテクニックにある。攻撃者はこのテクニックを使って、DHCPがもともと内蔵している機能を使い、ターゲットユーザーのトラフィックをVPNトンネルから強制的に外す。

　こうなると、ユーザーはVPNによって暗号化されていないパケットを送信してしまい、攻撃者はそのトラフィックの内容を盗むことができる。リジー・モラッティー氏とダニー・クロンセ氏はこの効果をデクローキング（decloaking）と呼ぶ。

　TunnelVision攻撃の嫌らしい点は、攻撃後もVPNの制御チャネルが維持されているため、VPNにキルスイッチのような機能があったとしてもそれが作動しないことだ。研究チームが観測した全てのケースにおいて、ユーザーの画面ではVPNに接続されていると表示され続けていた。

VPNトラフィックをデクローキングする条件

　デクローキングによってVPNから情報を盗み出すためには幾つかの条件がある。

（1）攻撃対象となるホストが、攻撃者が管理するサーバからのDHCPリースを受け入れること
（2）ターゲットとなるホストのDHCPクライアントがDHCPオプション121を実装していること
（3）不正なDHCPサーバが、真のDHCPに対して「DHCP枯渇攻撃」（DHCP starvation attack）を実行して、新しいクライアントに応答すること
（4）DHCPクライアントの先着順リース選択を悪用するために、DHCPDISCOVERブロードキャストに応答するように作った不正なDHCPサーバを用意すること
（5）正規のDHCPサーバとクライアント間のトラフィックを傍受するためにARPスプーフィングを使用し、クライアントがリースを更新するのを待つ

　（5）が終わった時点でTunnelVision攻撃を始める準備ができた。

Tunnel Vision攻撃はどのように始まるのか

　研究チームが見つけ出した攻撃手法はこうだ。攻撃対象となるVPNユーザーと同じネットワークでDHCPサーバを実行し、さらに用意したDHCPコンフィギュレーションをゲートウェイとして使用するように設定する。VPNユーザーのトラフィックがゲートウェイに到達すると、DHCPサーバのトラフィック転送ルールを従ってトラフィックが正規のゲートウェイに至る。その間にトラフィックを盗み見る。

　具体的にはDHCPのオプション121を使って、VPNユーザーのルーティングテーブルにルートを設定する。設定するルートは任意だ。必要に応じて複数のルートをプッシュ（設定）できる。ほとんどのVPNが使用している/0のCIDR範囲よりも具体的なルートを設定すればよい。こうすればVPNが作成する仮想インタフェースのルートよりも優先度の高いルーティングルールを作成でき、攻撃に利用できる。複数の/1ルートを設定することで、ほとんどのVPNで設定されている0.0.0.0/0の全トラフィックルールを再現できる。

　ルートをプッシュするというのはどのような意味だろうか。これはネットワークトラフィックが仮想ネットワークインタフェースではなく、DHCPサーバと同じインタフェースで送信されるということだ。この機能はRFCには明記されていないものの、意図的に設けられたものだ。こうして、プッシュしたルートは、VPNの仮想インタフェースで暗号化されることなく、DHCPサーバと通信しているネットワークインタフェースで送信される。攻撃者はどのIPアドレスがトンネルを経由し、どのアドレスがDHCPサーバと通信しているネットワークインタフェースを経由するのかを選択できる。

　TunnelVision攻撃にさらされている図4を図2と比較すると、図中央左に描かれているルーティングテーブルに空色のルートが設定されていることが分かる。このルートが選ばれるとファイアウォールルールで「Network Interface（fun0）」に通信が振り分けられなくなり、VPNを経由せずに直接通信がインターネットに出てしまう。

図4　DHCPのオプション121を悪用してトラフィックがVPNプロセスによって暗号化されないように改変されたルート。図2と比較すると、VPNを使わないように経路が変化している（提供：Leviathan Security）

　図4ではVPNの暗号化されたトンネルの外側にトラフィックが送信されている。このテクニックは、VPNユーザーのホストが DHCPサーバからのリースを更新する必要がある際、すでに確立されているVPN接続に対しても使用できる。新規にVPNを開始しようとしているユーザーだけが攻撃対象ではない。

　DHCPリースに短いリース時間を設定して、ユーザーがルーティングテーブルを頻繁に更新するように強制することで、攻撃が成功する確率が上がる。さらに、VPNはすでに物理インタフェースを通信に使っているので、VPNの制御チャネルには何の変化もない。研究チームのテストでは、VPNのステータスは常に接続中になっており、安全のための防御策（キルスイッチ）が作動してVPN接続が切断されることはなかったという。

TunnelVisionをどう捉えるべきなのか

　研究者によれば、TunnelVisionはネットワーク通信の基礎技術のセキュリティ特性を侵害していないため、攻撃のために脆弱（ぜいじゃく）性を利用しているとは言えない。研究者の観点では、TunnelVisionはDHCP、ルーティングテーブル、VPNの本来の動作をそのまま使っている。だからこそ危険だとも言える。

　VPNプロバイダーは自分たちの製品が「信頼されていないネットワークにおいても攻撃者から顧客を守る」と保証することがある。このような保証はTunnelVisionには無効だ。転送中のデータを保護することと、LANを用いた全ての攻撃から保護することには大きな違いがあるからだ。VPNは物理ネットワークにおけるLAN攻撃を軽減するようにはそもそも設計されていない。

　TunnelVisionでは、VPNの暗号化されたプロトコルは破られておらず、VPNは完全に機能している。攻撃者はその代わりに、ターゲットユーザーにVPNトンネルを使わないように強制する。「VPNがローカルネットワークにいる攻撃者から守ってくれる」という保証にユーザーが頼っているならTunnelVisionは大きな問題になる。

　TunnelVisionは全てのOSに影響を与えるわけではない。冒頭で記したようにAndroidは影響を受けない。研究者のテストによれば、DHCPクライアントをRFC仕様に従って実装し、DHCPのオプション121をサポートする全てのOSが影響を受けた。「Windows」やLinux、「iOS」や「macOS」ではTunnelVision攻撃が有効だ。

　今回の研究により、ホストのトラフィックを保護する際、ルーティングルールのみに依存するVPNは脆弱だと分かった。システム管理者などが独自のVPNサーバをホスティングしていたり、VPNクライアントの構成を強化していなかったりする場合は、TunnelVision攻撃を受ける可能性がある。なお、一部のVPNプロバイダーがファイアウォールルールを使用して、VPN以外のインタフェースへのトラフィックをドロップすることで対策していることが確認できたという。

　TunnelVisionの動作から分かるようにVPNで使われる暗号化アルゴリズムの強度は、今回の問題には全く関係がない。これは誤解しやすい点だという。TunnelVisionの効果は、基盤となるVPNプロトコル（WireGuard、OpenVPN、IPsecなど）とも無関係だ。なぜなら、VPNが依存するOSのネットワークスタックをTunnelVision攻撃で再構成するためだ。

　TunnelVision攻撃は2002年時点ですでに動作可能だっただろうと研究者は結論付けている。少なく2015年にはルーティングテーブルとDHCPのオプション121を組み合わせた場合の先行研究がある。すでにTunnelVision攻撃が広まっていてもおかしくない状態だ。

　研究チームがVPNサービスなどの関係者にTunnelVision攻撃への対策について問い合わせた際、この問題を深刻なものだと認識していないケースに複数遭遇したという。TunnelVision攻撃を成功させる前提条件がローカルネットワークへのアクセスだけなのにもかかわらず、前提条件としてアクセス特権やアカウントが含まれていると思い込んでいた関係者がいた。VPNの関係者にもTunnelVision攻撃の危険性が浸透していないと言うことだ。