3 ポイント 投稿者 GN⁺ 2024-05-07 | 1件のコメント | WhatsAppで共有
  • VPNは、ユーザーのデバイスと別ネットワーク上のサーバー間に、ネットワークトラフィックのためのトンネルを作成する技術。これによって作られた仮想ネットワークは物理ネットワークと同じように動作し、地理的な場所の制約を受けない。
  • VPNクライアントは仮想ネットワークインターフェースを作成し、トラフィックを暗号化・復号した後、物理ネットワークインターフェースへ送る役割を担う。
  • VPNはユーザーにとってできるだけ使いやすく設計されており、ログインしてボタンをクリックする以外に多くの作業を求めない。
  • VPNは低レイヤーのネットワークトラフィックをインターネットへ転送するため、実際にはホストの攻撃対象領域を増やしてしまう。VPNはLANトラフィックをインターネット上でカプセル化し、インターネット上にローカルネットワーク(LAN)を作る。
  • VPNはパケット暗号化のような補償的コントロールを使って、拡張されたLANの攻撃対象領域を緩和する。しかし、VPNは物理LANに対するローカルネットワーク攻撃からユーザーを保護するものではない。

DHCPとDHCPオプション121

  • DHCPはIPアドレスを動的に割り当て、デバイス構成をリモートで調整できるオプションを提供するプロトコル。
  • DHCPオプション121は、管理者がクライアントのルーティングテーブルに静的経路を追加できるようにするオプション。
  • DHCPオプション121の興味深い特徴は、DHCPサーバーが経路をインストールするネットワークインターフェースデバイスを指定できないこと。代わりに、DHCPクライアントはそのオプションのルーティングルールをインストールする際、DHCPサーバーと通信しているネットワークインターフェースを暗黙的に選択する。

Decloaking攻撃の要件と流れ

  • 標的ホストは、攻撃者が制御するDHCPサーバーからDHCPリースを受け入れる必要がある。
  • 標的ホストのDHCPクライアントはDHCPオプション121を実装していなければならない。
  • 攻撃者はVPNユーザーと同じネットワーク上でDHCPサーバーを動かし、DHCP設定で自分自身をゲートウェイとして設定する。
  • DHCPオプション121を使って、VPNユーザーのルーティングテーブルに経路を設定する。
  • 経路設定により、ネットワークトラフィックはVPNの仮想インターフェースではなく、DHCPサーバーと通信しているネットワークインターフェース経由で送信される。
  • トラフィックはVPNの暗号化トンネルの外側で送信されるが、VPN制御チャネルは維持されるため、VPNは接続されたままだと認識される。

影響を受ける対象

  • RFC仕様に従ってDHCPクライアントを実装し、DHCPオプション121経路をサポートするWindows、Linux、iOS、MacOSなど、ほとんどのOSが影響を受ける。(AndroidはDHCPオプション121をサポートしていないため影響を受けない)
  • ホストのトラフィック保護をルーティングルールのみに依存しているVPNは脆弱。
  • 独自のVPNサーバーをホスティングしている場合、VPNクライアント構成を強化していなければ脆弱である可能性がある。
  • ベースとなるVPNプロトコル(WireGuard、OpenVPN、IPsecなど)に関係なく、VPNが依存するOSのネットワークスタックを再構成するため影響を受ける。

緩和策と限界

  • Linuxのnetwork namespaceを使えばこの問題を完全に解決できるが、一般には十分に実装されていない。
  • 一部のVPNプロバイダーでは、ファイアウォールルールによって物理インターフェースのインバウンド/アウトバウンドトラフィックを遮断する対策が見られるが、部分的な緩和策にすぎない。
  • DHCPオプション121を無視することも可能な緩和策だが、ネットワーク接続が切れる可能性がある。
  • ホットスポットやVMを使うと、攻撃者がローカルネットワークアクセス権を得にくくなるため有効な場合がある。
  • 絶対的なトラフィック秘匿性が必要な場合、信頼できないネットワークの利用を避けることが最善の防御策。

GN⁺の見解

  • VPNは物理ネットワーク上でのLAN攻撃を緩和するようには設計されていないため、信頼できないネットワークでもVPNが顧客を保護するとするVPNプロバイダーのマーケティング主張は危険になりうる。VPNプロバイダーはTunnelVisionに対する緩和策や修正内容を公開文書として整備し、ユーザーに周知すべき。
  • 企業VPNはカフェ、ホテル、空港などでよく使われるため、ネットワーク管理者は従業員にこうした場所で作業することのリスクを知らせ、可能な限り避けるよう勧告すべき。また、内部リソースにHTTPSなどの暗号化プロトコルを実装し、信頼できないネットワークから接続するVPNユーザーによるデータ漏えいを防ぐ必要がある。
  • インターネットトラフィックの大半はHTTPSで保護されているため、VPNが無効化されても、ほとんどのユーザーデータがローカルネットワークの攻撃者に露出することはないとみられる。ただし、機密性の高いトラフィックについては警戒が必要。
  • Linuxを除くOSメンテナーは、network namespaceに関連する機能の追加または改善が可能か確認すべき。
  • VPN技術そのもののセキュリティ特性を破るわけではないが、VPNプロバイダーの保証とは矛盾するため、脆弱性と見なすことができる。研究チームは、この手法は2002年以降ずっと可能だったと推定しており、影響を受ける関係者へ広く知らせるため研究結果を公開することを決めた。

1件のコメント

 
GN⁺ 2024-05-07
Hacker Newsの意見

要約:

  • この攻撃は、2016年のSamy Kamkarによる「Poison Tap」攻撃に似ている。USB/Thunderboltネットワークアダプターを使って、より具体的な2つの経路を広告し、システム上の他のインターフェースより優先してすべてのトラフィックを横取りできる。
  • 見出しではすべてのVPNクライアントに影響すると主張しているが、多くのクライアントはファイアウォールルールを設定し、物理インターフェースとのトラフィックを遮断している。主要な個人向け/商用および企業向けVPNソリューションのうち、この機能がデフォルトで有効になっている割合を文書化していれば生産的だったはずだ。
  • DHCPオプション121を使うと、DHCPサーバーは特定のCIDR範囲に対するルーティングルールを設定できる。これは、より長いプレフィックスにより、デフォルトの0.0.0.0/0ルールより優先順位が高くなる。
  • この「攻撃」は、DHCPオプション121を巧みに利用したものだ。適切に分離するには、適切なポリシーベースルーティング(例: Linuxネットワーク名前空間、FreeBSD vnet、OpenBSD rdomains)を使うべきだ。
  • Linuxでは、VPNインターフェースをVRFに配置することでこれを緩和できる。systemd-networkdは標準でこれをサポートしている。
  • 攻撃者がLAN上のDHCPサーバーになれるという脅威モデルは、可能性は低いが不可能ではない。
  • 仮想マシンベースのアーキテクチャでもこの問題を解決できる。QubesOSでは、類似の設定を非常に簡単に構成できる。
  • ネットワーク名前空間の興味深い代替案は、カーネルネットワーキングを完全に迂回し、ユーザー空間のネットワークスタックを使うことだ。
  • IPv4専用のVPNサービスを使いながら、システムでIPv6を有効にしていることのほうがより心配だ。深刻な問題が発生する可能性がある。