攻撃者がルーティングベースのVPNを露出させる可能性
(leviathansecurity.com)- TunnelVision（CVE-2024-3661） は、DHCPの既存機能を悪用してユーザーのトラフィックをVPNトンネルの外へ迂回させ、その際パケットはVPNで暗号化されない
- 攻撃者は DHCP option 121 でより具体的なルートを注入し、VPN仮想インターフェースより優先される経路を作って、トラフィックを物理インターフェースへ送ることができる
- 対象が攻撃者制御のDHCPリースを受け入れ、クライアントがoption 121を実装していれば攻撃が可能で、テストではWindows、Linux、iOS、macOSが影響を受け、Androidは除外される
- VPN制御チャネルは維持されるため、ユーザーには接続中に見え続け、観測された事例では kill switch もトラフィック漏えいを防げなかった
- Linuxの ネットワーク名前空間 は強力な解決策になり得るが、ファイアウォールベースの緩和は選択的サービス拒否と、トラフィックの宛先を推測するサイドチャネルを生み得る
TunnelVisionが引き起こすVPNのdecloaking
- TunnelVisionはVPNカプセル化を迂回し、ユーザーのトラフィックをトンネルの外へ強制的に送る ネットワーク手法 である
- 攻撃者はDHCP（Dynamic Host Configuration Protocol）を利用し、対象パケットがVPNで暗号化されないまま送信されるようにできる
- VPN制御チャネルは維持されるため、ユーザーにはVPNに接続されたままのように見え、この効果は decloaking と呼ばれる
- この手法は2002年までさかのぼって実現可能だった可能性があり、公開後、DHCP option 121とVPNへの影響に関する先行研究が少なくとも2015年から存在していたことが確認された
- 2015年: Hardening OpenVPN for Def Con
- 2016年: Samy Kamkar's
- 2017年: Jomo's Mastodon
- 2023年: Lowend talk thread
VPNルーティングが攻撃面になる理由
- VPNはホストデバイスと別ネットワーク上のサーバーとの間にトラフィック用の トンネル を作り、VPNクライアントは仮想ネットワークインターフェースでトラフィックを暗号化・復号する
- 全トラフィックをVPNへ送る構成は full-tunnel VPN、ローカルネットワークなどの例外がある構成は split-tunnel VPN と呼ばれる
- VPNはサーバーとの接続を維持する必要があるため、VPNサーバーIP宛てのトラフィックを物理インターフェースへ送る例外ルートが必要になる
- ルーティングテーブルは宛先に応じてトラフィック経路を決め、多くのネットワークスタックでは、より具体的な CIDR prefix length が高い優先度を持つ
/32ルートは/24や/0より優先される- 多くのfull-tunnel VPNは
0.0.0.0/0または2つの/1ルートでトラフィックをVPNインターフェースへ送る
DHCP option 121を利用した経路注入
- DHCPはローカルネットワークデバイスにIPアドレスのリースを動的に提供し、options を通じてデフォルトゲートウェイやDNSサーバーなどの設定も伝達する
- 一般的な流れは、クライアントが
DHCPDISCOVERをブロードキャストし、サーバーがDHCPOFFERで期限付きのリースを提案する方式である - RFC 3442で導入されたDHCP option 121は classless static routes 機能で、DHCPサーバーがクライアントのルーティングテーブルに静的ルートを追加できるようにする
- option 121では、DHCPサーバーがインストールするルートのネットワークインターフェースデバイスを直接指定できない
- DHCPサーバーはCIDR範囲とルーターを指定する
- クライアントはDHCPサーバーと通信中のインターフェースを、そのルートのインターフェースとして暗黙的に選択する
- この動作により、注入されたルートのトラフィックはVPN仮想インターフェースではなく、DHCPサーバーと通信する 物理ネットワークインターフェース から出ていく可能性がある
攻撃条件と実行方法
- TunnelVision攻撃には2つの条件が必要である
- 対象ホストが攻撃者制御のDHCPサーバーからのリースを受け入れること
- 対象ホストのDHCPクライアントが DHCP option 121 を実装していること
- 同じネットワーク上の攻撃者は、複数の方法で対象のDHCPサーバーになれる
- 正規のDHCPサーバーにDHCP starvation攻撃を行った後、新しいクライアントに応答する
DHCPDISCOVERブロードキャストに先に応答し、DHCPクライアントのfirst-offer選択動作を悪用する- ARP spoofingで正規のDHCPサーバーとクライアント間のトラフィックを傍受し、リース更新を待つ
- 攻撃者は対象VPNユーザーと同じネットワークでDHCPサーバーを実行し、自分自身をゲートウェイに設定する
- その後、DHCP option 121でVPNユーザーのルーティングテーブルに任意のルートを追加し、VPNの
/0より具体的なルートを入れてVPN仮想インターフェースより優先させる- 複数の
/1ルートを設定することで、多くのVPNが使う0.0.0.0/0の全トラフィック規則を再現できる - 攻撃者は、どのIPアドレスがVPNトンネルへ行き、どのアドレスが攻撃者のDHCPサーバーと通信するインターフェースへ行くかを選択できる
- 複数の
- すでに確立済みのVPN接続にも適用可能で、DHCPリース時間を短く設定すればルーティングテーブル更新をより頻繁に誘導できる
PoCと実験シナリオ
- 公開資料は次のとおり
- Video proof of concept: https://www.youtube.com/watch?v=ajsLmZia6UU
- Lab Setup Code: https://github.com/leviathansecurity/TunnelVision
- DHCP Server image: https://drive.google.com/file/d/1WLJGs3ZUypf6hLh5WL4AJmsKdUOZo5yZ
- 実験環境は複数の攻撃シナリオを表すよう構成されている
- 攻撃者がDHCPサーバーやアクセスポイントを侵害した場合
- 悪意ある管理者がインフラを直接所有・設定した場合
- 攻撃者がカフェやオフィスのような物理的な場所にevil twin無線APを設置した場合
- 今後ArcaneTrickster公開後には、同じLAN内の隣接ホストだが特権的なネットワーク位置ではない攻撃者も模擬可能になる
影響を受けるOSとVPN
- テストでは、RFC仕様に従ったDHCPクライアントを実装し、DHCP option 121ルートをサポートするOSが影響を受ける
- 影響を観測: Windows、Linux、iOS、macOS
- 例外: AndroidはDHCP option 121をサポートしていないため影響を受けない
- ホストトラフィック保護を ルーティング規則 のみに依存するVPNは脆弱である
- 独自のVPNサーバーを運用するシステム管理者も、VPNクライアント構成を強化していなければ脆弱である可能性がある
- 暗号化アルゴリズムの強度は影響しない
- TunnelVisionはWireGuard、OpenVPN、IPsecのようなVPNプロトコル自体を破るものではない
- OSネットワークスタックのルーティング構成を変え、ユーザーがVPNトンネルを使わないようにする方式である
修正と緩和策
- Linuxの ネットワーク名前空間 はこの動作を完全に修正できる
- WireGuard documentation は、VPNを使用すべきアプリケーショントラフィックを別の名前空間で処理した後、物理インターフェースがある別の名前空間へ送る方法を示している
- Windows、macOS、その他のOSで同等に堅牢な解決策があるかは不明である
- 一部のVPNプロバイダーは、物理インターフェースのすべてのインバウンド・アウトバウンドトラフィックをファイアウォール規則でブロックする緩和策を使っている
- LANとVPNサーバー接続を維持するため、DHCPとVPNサーバーIPの例外が必要になる
- ディープパケットインスペクションでDHCPとVPNプロトコルだけを許可することもできるが、性能ペナルティがある可能性がある
- ファイアウォールによる緩和は、DHCPルートを使うトラフィックに 選択的サービス拒否 を生み、サイドチャネルを追加する
- 攻撃者はVPN暗号化トラフィックの量の変化を分析し、対象ユーザーが特定の宛先へトラフィックを送っているかを統計的に立証できる
- 事前定義されたリストと照合したり、検閲メカニズムとして選択的ブロックを行ったり、IP空間のブロックを二分探索のように使って現在の接続を対数時間で見つけたりできる
- VPN使用中にoption 121を無視する方法もあるが、この機能は正当なネットワーク接続に必要な場合があり、接続障害を引き起こし得る
- この緩和策が任意選択であれば、攻撃者がネットワークアクセスを拒否して、VPNやユーザーにoption 121を再び有効化させるよう誘導できる
- ホットスポットやVMも緩和に役立つ可能性がある
- セルラー端末が制御するパスワード保護されたLANは、攻撃者のローカルネットワークアクセスを防ぐ助けになる
- VMはネットワークアダプターがbridged modeでなければ同様に動作する
ユーザーと運用者に必要な対応
- 機密性の高いトラフィックでは信頼できないネットワークの利用を避け、やむを得ない場合はTunnelVisionに有効な緩和策を持つVPNプロバイダーを使うべきである
- VPN decloakが発生してもHTTPSウェブサイトに接続している場合、ほとんどのユーザーデータはローカルネットワーク攻撃者には見えないが、宛先とプロトコル は露出する可能性がある
- 企業VPNをカフェ、ホテル、空港などで使う場合、ネットワーク管理者はリスクを知らせ、可能な限り避けるよう案内すべきである
- 現実的でなければ、緩和や修正が適用されたVPNの使用を案内すべきである
- 信頼できるホットスポットを使用してからVPNへ接続する、または仮想DHCPサーバーからリースを受けるVM内でVPNを実行する方法も可能である
- 自社ネットワークやsite-to-site VPNを運用する企業はスイッチを点検し、DHCP snooping やARP保護のようなLayer 2保護機能を有効にすべきである
- こうした保護はrogue DHCPサーバーを減らすのに役立つが、悪意ある管理者シナリオは排除できない
- 内部リソースにHTTPSまたは他の暗号化プロトコルを適用すれば、信頼できないネットワークから接続したVPNユーザーのデータ漏えいを防ぐ助けになる
- VPNプロバイダーは、ネットワークインターフェースへ出ていくアウトバウンドパケットをブロックするファイアウォール機能をクライアントに追加できるが、ユーザーはローカルネットワークリソースとやり取りできなくなる
- Linux用full-tunnel VPNクライアントは、ネットワーク名前空間を使った分離を検討すべきである
- OSメンテナーは、Linux以外のOSでネットワーク名前空間関連機能の追加や強化を検討すべきである
- LANセキュリティ研究と実際の攻撃デモのための ArcaneTrickster というadversarial infrastructureライブラリが開発中で、後日公開される予定である
1件のコメント
Hacker News の意見
これは2016年の Samy Kamkar による PoisonTap 攻撃を少し変えたものです。USB/Thunderbolt ネットワークアダプターで同じことを行い、被害者のデバイスに挿して、0.0.0.0/1 と 128.0.0.0/1 のような、より具体的な経路を2つ広告すれば、インターフェースの順序に関係なく他のシステムインターフェースより優先され、すべてのトラフィックを持っていけます: https://github.com/samyk/poisontap
おそらく他にも先行事例はあるでしょうが、これは非常によく知られた例です。記事タイトルではすべての VPN クライアントが影響を受けると言っていますが、本文でも認めているように、多くの VPN クライアントは物理インターフェースを出入りするトラフィックを遮断するファイアウォールルールを設定します
匿名性をうたう、またはその匿名性が重要な VPN は、たいていこれを実装しています。デフォルトで有効になっていない設定も多いでしょうが、主要な個人向け/商用/企業向け VPN ソリューションのうち何パーセントがデフォルトでこれを有効にしているのかを文書化していれば、もっと有益だったと思います
一般読者向けの説明は良いものの、こうしたファイアウォールルールで大半のデータ流出を防ぐクライアントが多いことや、この分野の先行事例を認めていない点を見ると、タイトルはやや誇張気味に見えます
「サイドチャネル攻撃」という表現を見て、飲み物を吹き出しそうになりました
追記: 見たところ、NordVPN は少なくとも mac ではそのような基本ファイアウォールルールがなく、この攻撃に脆弱なようです
この記事がなぜこんなに長いのか分かりません
DHCP Option 121 は、DHCP サーバーが特定の CIDR 範囲に対するルーティングルールを設定できるようにするもので、より長いプレフィックスなので、デフォルトの 0.0.0.0/0 ルールより優先度が高くなります
インターネット上の VPN 情報の半分は VPN プロバイダーが書いたもので、実際にどう動くのかを説明するには不正確だったり、十分に技術的でなかったりします
導入部に「すでに知っている内容なら POC セクションへ飛んでください」という文をリンクとして入れようと思っていましたが、もっと目立つように更新します
記事は読まず、上のコメントだけを見ての推測です
以前、別の著者によるこの攻撃の記事を読んだ気がしたので探してみたところ、検索結果にあふれる VPN 業者のスパムをかき分けて先行研究 [1] を見つけました
今回の記事は欠陥を悪用する方法をより深く扱っており、概念実証に役立つコードもあります
1: https://www.usenix.org/conference/usenixsecurity23/presentat...
ただし、2023年8月の論文に出てくる2つの手法はいずれも、DHCP option 121 で経路をプッシュするものではありませんでした。DHCP で経路をプッシュすると、同じ攻撃者の位置からでも影響ははるかに大きくなります。たとえば、非 RFC1918 範囲の IP リースを配ったり、DNS 応答を偽装できる位置です
脅威モデルは、任意の攻撃者が何らかの方法で自分の LAN 上の DHCP サーバー になれるというものですが、可能性は低いものの不可能ではありません
逆に、ISP が提供したゲートウェイ機器を使っているなら話は変わります
ほとんどの VPN 商品の一番のセールスポイントがそれです
この場合の正しい対応は、4G/5G 接続を使い、信頼できない怪しいネットワークには接続しないことです
一般家庭では DHCP がルーターから提供されるため、通常はそれが最初に応答するという事実は二次的です。ネットワーク内の悪意あるデバイスなら誰でもこの脆弱性を使えます
Linux では、VPN インターフェースを VRF に入れることでも緩和できます。たとえば systemd-networkd はこれを標準でサポートしています
注意点は、VRF を有効にすると l3mdev 用の ip rule エントリは 1000 になりますが、ローカルトラフィックのルールは 0 になることです。ローカルルールを 1000 以上へ移す必要があります
この「攻撃」は DHCP option 121 を巧妙に使っているだけです。ひどく壊れたクライアント設定に対しては有効な攻撃です
デフォルト経路を変えたり、2つの /1 経路で上書きして VPN エンドポイントへのホスト経路を追加したりする方式は安全ではありません。カプセル化されたトラフィックを下位ネットワークから適切に隔離するには、ポリシーベースルーティングを使うべきです。たとえば Linux のネットワーク名前空間、FreeBSD vnet、OpenBSD rdomains などです
パケットフィルターとユーザー空間の「キルスイッチ」を無理やりつなぎ合わせようとする方式は設計段階から壊れており、一般的な VPN ホスティング業者が、自分たちの中核能力であるはずのものをどれほど理解していない、あるいは気にしていないかを示しています。古くからある「悪いものを列挙する」問題がまた出てきたわけです
今さら新しい話でもありません
システムで IPv6 が有効なのに IPv4 専用 VPN サービス を使っている人たちのほうが心配です
それは本当に大きくまずいことになり得ます
クライアント端末でVPNを迂回する方法はいくらでもあります。そのためVPNが必要なときは、クライアントとインターネットの間に、VPNトンネルを終端し、他の経路を持たないルーターを置くほうを好みます。
こうしたトラベルルーターは非常に簡単に設定でき、どこにでも持ち運べますし、実際にそうしています。
たとえば、職場のイントラネットへのVPN接続を常時維持する「work」Wi-Fiルーターがあり、オーストラリアのテレビを見たいときにオーストラリアのサーバーへVPN接続する「Australia」Wi-Fiがあり、最後に通常の家庭用インターネットWi-Fiがあります。
古いWi-Fiルーターが数台あれば非常に簡単にできますし、最近の安価な家庭用ルーターでもある程度のVPN対応はしているようです。VPN設定を集中管理してミスの余地を減らせることに加え、どの端末でもそのWi-FiにつなぐだけでVPNを使えるという大きな利点があります。
複数の古いルーターでこのように使っていますが、実際には、1台の家庭用ルーターが世界各地へVPNを張り、場所ごとに異なるWi-Fiネットワークを提供する製品にも市場があると思います。TV/Roku/iPadを、簡単に別の地域から接続しているように見せる用途です。
ただしLAN上に信頼できない端末がありDHCPを使っている場合、その端末はこの手法で暗号化されていない*トラフィックを盗み見ることができます。それでもゲートウェイが隠してくれるため、実際のIPは見つけられません。
この攻撃が最も現実的なのは、カフェのWi-Fiのような状況です。そういう場所に自分のルーターを持って行く可能性は低いでしょう。
ここでいう「暗号化されていないトラフィック」とは、VPNプロバイダーへ送られるようにカプセル化されていないトラフィックのことです。最近はほとんどがHTTPSなので、そのトラフィックの内容自体は依然として暗号化されているはずです。
技術寄りの人にとってはかなり自明であるべき内容ですが、ネットワーキングとVPNの入門説明としては良いものです。LinuxのVPNゲートウェイVMを何度か構成したことがありますが、ルーティングテーブルだけに依存する構造は常に脆弱に感じました。特に、その接続を使う同じマシン上で実行される場合はなおさらです。
ネットワーク名前空間や物理VPNゲートウェイルーターに加えて、VMベースのアーキテクチャでもこの問題は解決できます。私のホームラボでは、ファイアウォールがVPNゲートウェイVMから出る想定外のトラフィックを遮断します。VPN VLAN上の端末は外部へ直接接続できず、ゲートウェイVMは外部接続用の別VLANを持っています。
個人向けの解決策としては、QubesOSが似た構成をかなり少ない摩擦で設定できるようにしてくれますが、それでも一般的なOSより多くの技術知識が必要です。
「AndroidはDHCP option 121のサポートを実装していなかったため、唯一影響を受けなかった」という部分が興味深いです。
Googleがこの問題を知っていて意図的に下した判断だったのか、完全な偶然だったのか気になります。
推測ですが、AndroidのネットワーキングチームはIPv6に非常に好意的です。IPv4の抜け落ちたニッチな機能にはあまり関心がないようです。IPv6についても、どう使うべきかについて特定のビジョンを持っており、その結果、ステートフルDHCPv6のような機能を意図的にサポートしないことにつながっています。
このDHCPオプションは一般的に使われていないため、そのような戦略を取れば、セキュリティ上の懸念とは無関係にサポートされなかった可能性が高いです。
なので、それほど驚くことではありません。