TunnelCrackとTunnelVision：それぞれが実際に壊すもの

トンネルを出るVPNトラフィックについては、二つの研究名が同じ意味で使われているが、その背後の仕組みは同一ではない。TunnelCrackは二つの系統のルーティング例外を記述し、TunnelVisionはエンドポイントにDHCPが配布する経路を記述する。どちらも暗号化を破るものではなく、どちらも特定のクライアントビルドが今日どう動くかを教えてくれない。五つの確認が仕組みと見出しを切り分ける。

手順一：確認する仕組みに名前を付ける

2023年八月に公表されたTunnelCrackは、二つの攻撃系統を記述している。ローカルネットワークの場合、クライアントがローカルネットワークに属すると見なすトラフィックはローカルアクセス例外を通り、トンネルの外に出る。サーバーアドレスの場合、VPNサーバー自体に到達するためにクライアントが必要とする経路はトンネルの外にあり、そのアドレスを制御する攻撃者はこの例外を悪用できる。

TunnelVisionは、DHCPが配布するクラスレススタティックルートに関する別の報告である。悪意あるDHCPサーバーは、トラフィックの経路を変えるルートをエンドポイントに渡すことができ、VPNサーバーへ向かう経路も含まれる。この報告は関連するルーティング効果についての先行研究を認めており、基盤となる仕組みが名前より古いことを思い起こさせる。

名前はその仕組みに結び付けたままにしておく。もう一方がニュースになっているからという理由で片方の修正を適用することは、確認作業が網羅性なしに動きだけを生むやり方である。

手順二：ローカルアクセス例外を見る

ほとんどのクライアントは、トンネルが有効な間もプリンター、画面共有、ファイル共有が機能するよう、ローカルネットワークのトラフィックを除外する。この例外はセキュリティ上のコストを伴うポリシー判断であり、同じネットワーク上の攻撃者は自分をローカルホストとして提示でき、そこに届くトラフィックはトンネルに入っていない。

配布しているプロファイルにその例外が本当に必要かを問う。ローカル検出を一切使わない遠隔勤務の組織なら無効にできることが多く、残ったローカルサービスには文書化された経路で到達できる。例外が必要な場合は、ローカルトラフィックと表現するのではなく、どの宛先を対象にするのかを明記する。

確認は構成の問いであり、パケットキャプチャではない。配布するビルドのプロファイル設定とクライアントの文書を読むべきで、既定値は製品間でも同一製品のバージョン間でも異なる。回答はプロファイルの隣に書いておき、次の確認者が挙動から推測しなくて済むようにする。誰も文書化していない例外は、誰も確認しない例外である。

手順三：サーバーアドレスの学習方法を見る

クライアントはトンネルが存在する前にVPNサーバーへ到達しなければならないため、その宛先は設計上トンネルの外へ経路設定される。アドレスを名前から学習する場合、名前解決の段階は信頼経路の一部であり、その問い合わせに応答できる攻撃者はクライアントを自分が制御するホストへ向けられる。

アドレスを固定し、正しい名前を持つ検証済み証明書を使い、未検証のサーバーへのフォールバックを拒否することは、いずれも露出を減らす。どれもトンネルの外でサーバーに到達する必要性をなくすものではなく、そのアドレスに誰が応答できるかを変える。

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

経路検索は、クライアントがサーバーアドレスに使うインターフェースを示し、それが例外の具体的な姿である。その検索がトンネルのインターフェースを返すなら、クライアントはそもそもトンネルを確立できず、したがって外部経路は想定どおりで、問いはその宛先がどう選ばれるかだけである。

手順四：DHCPが配布する経路を見る

クラスレススタティックルートは、DHCPサーバーがルーティングテーブルの項目を配布することを可能にし、エンドポイントは通常それを尋ねずに受け入れる。攻撃者が正規のサーバーより速くDHCPに応答できるネットワークでは、その項目が利用者がトンネル内だと思っているトラフィックを迂回させうる。

エンドポイントの経路を、期待する経路と比較する。トンネルが有効な間にローカルゲートウェイを指す既定ルートや広いプレフィックスは、調査に値する兆候であり、攻撃トラフィックなしで見える。

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

最後の設定は、多くのクライアントとプラットフォームが何らかの形で公開しているエンドポイント側の制御、すなわちネットワークが供給する経路を無視する設定である。自動的な経路受け入れを無効にするのはトレードオフで、企業のDHCPサーバーからの正規の分割ルーティングも無効になるため、グローバルではなくネットワーク種別ごとに決める。

手順五：勧告と現在のビルドを分ける

公表された攻撃は、特定の時点で特定のクライアントバージョンで観察された挙動を記述する。目の前のノートPCが影響を受けていることも、修正済みであることも証明しない。どちらの主張にも実際のビルド番号とベンダーの現在の勧告が必要である。

クライアントのバージョン、プラットフォーム、上記の例外を左右するプロファイル設定、確認した日付を記録する。その記録は正直に古びるが、VPNがTunnelCrack向けにパッチされたというメモは正直に古びない。クライアントが更新されるたびに読み返すべきで、触れていないバージョンの下でプロファイルの既定値が変わりうるからだ。

実際に検証するときは、承認された計画を自分のエンドポイントと無害な宛先に対して使う。共有ネットワーク上の他の利用者に対して攻撃を再現することは試験ではなく、観察を容易にするためにピア検証やアプリケーション暗号化を無効にすることは、測ろうとしていた保護を外すことになる。

最後に、アプリケーション層の保護も視野に入れておく。ルーティング例外はトンネルが運ぶはずだったトラフィックを露出させうるが、アプリケーションのTLSはそのトラフィックを端から端まで依然として保護する。二つの層は独立して失敗するため、接続された制御チャネルは、すべてのフローが意図した経路を通った証拠にはならない。