VPN Gremlin：複数のSSL VPNにおけるユーザーなりすまし攻撃——パート2

前回の記事では、複数のSSL VPNでファイアウォール/ルーティングルールを回避する一連の攻撃について取り上げました。今回は、脆弱性詳細をさらに深く掘り下げ、SSL VPNの一般的な動作メカニズムについて解説します。最後に、SSL VPNトンネリングプロトコルをより深く調べるためのオープンソースツールをご紹介します。

目次

• SSL VPN接続の構造
• SSL VPNトンネリングプロトコルのファジング
• VPN Gremlinの実行
• まとめ

SSL VPN接続の構造

SSL VPN技術に影響度が大きいバグが多いことから、SSL VPNのトンネリングメカニズムを調査を実施しました。

しかし、これらのバグの大半は、HTTP APIリクエストの形で見つかっています。当初の調査では、SSL VPN接続は次のように3つの段階で構成されることがわかりました。

• 認証段階
• ゼロコンフィギュレーション段階
• トンネリング段階

IPsecプロトコルをご存じの方は、最初の段階をIKEに、2番目の段階を事前設定されたコンフィギュレーション（設定）ファイルに置き換えて考えてください。
ご存知のように、ほとんどのSSL VPNはゼロコンフィギュレーションプロトコルであり、それが普及率の高さに貢献しています。ほとんどのSSL VPNでは、最初の段階でユーザーが対応する認証情報を使用してサーバーを認証するだけで済みます。認証情報がサーバーに受け入れられると、サーバーはルーティングテーブル、割り当てられたIPアドレス、さらに第3段階（トンネリング）の認証に使用されたクッキーなどの接続情報を送り返します。クライアントは、この情報を使用して第3段階で接続を確立しますが、通常は、(D)-TLSプロトコル上にトンネルを作成して行われます。
このトンネルを作成することで、クライアントとサーバーは、基盤となるTLS/SSLスタックによって提供される暗号化と認証によって保護された、脆弱なネットワーク上でIPパケットを交換できます。

図1.SSL VPN接続プロトコル

図2.SSL VPNカプセル化レイヤ

さらに、当初の調査では、ほとんどのバグはプロトコルの第1段階か第2段階のどちらかで見つかっていたため、トンネリングプロトコル自体に関する調査はほとんど行われていませんでした。次のセクションに進む前に、我々がテストしたベンダーのリストを以下に示します。

表1.当社がテストしたCVE ID

SSL VPNトンネリングプロトコルのファジング

お気づきの方もいらっしゃるかもしれませんが、当社では複数のSSL VPNプロトコルをテストしています。このテストでは、ベンダーのトンネリングプロトコルをScapyで実装し、mitmproxyプロジェクトを使用して認証済み接続にパケットを挿入するという、少し変わったアプローチを行いました。そのため、最初と2番目の段階をスキップし、3番目の段階であるトンネリング段階のみに注目することができました。ベンダーごとに(D)-TLSレイヤ内に独自のカプセル化プロトコルを実装しているため、この面に作業を集中させました。

当社は、openconnectプロジェクトの実装を参考にして、正規クライアントが行うネットワーク上での振る舞いを観察して、プロトコルを実装しました。

図3.SSL VPNカプセル化レイヤ

最初のファジングの試行は、トンネル内の独自仕様のプロトコル自体に焦点を当てていたため、無駄に終わりました。また、このようなプロトコルは、基盤となるTCPやUDPパケットをカプセル化しており、いずれかのパーティによってネットワークの反対側に送信されることを意図していたため、当社のファジングの試行では、気がかりなバグは見つかりませんでした。そこで、基盤となるIPv4ヘッダーの1つのフィールドに対して、手動でテストすることにしました。

図4.最初のファジングの試行

バグを見つけた方法は次のとおりです。トンネリングプロトコルは、トンネル内でレイヤ4のトラフィックをカプセル化するため、ほとんどのベンダーは、(D)-TLSと独自仕様のプロトコルのカプセル化を解除した後、レイヤ4のヘッダーを検証していませんでした。SSL VPNゲートウェイが通常受信パケットを処理する方法を以下に示します。

図5.SSL VPNゲートウェイが受信パケットを処理する方法

VPN Gremlinの実行

発見されたバグは、受信側でカプセル化解除後に検証が欠落していることを暴露し、任意の送信元アドレスを持つレイヤ4パケットの送信を許可するものでした。当社のパケットは、受信側のSSL VPNアプライアンスによって正しく転送され、その結果、IPまたはポリシー（ユーザー）ベースのファイアウォールとルーティングルールを回避することができました。
これはなりすましタイプのバグであるため、偽造されたパケットを介してはまったく応答を受信できませんでした。VPN Gremlin攻撃で利用可能なエクスプロイトプリミティブ（悪用のための手法）をさらに調査し、次のようなことがわかりました。

• この攻撃では、トンネルに認証されていること、および利用可能な送信元IPアドレスと標的IPアドレスを知っている必要がある。
• 非常に限定的なケースでは、TCPオフパス攻撃を実行することが可能。ただし、ICMPおよびUDPベースのプロトコルに依存する脆弱性は実行可能性あり。

そこで、VPN Gremlin攻撃がネットワーク内で成功するケースをいくつかご紹介します。

ケース1：保護されたネットワーク内の脆弱なデバイス

前述のように、この攻撃では、利用可能な送信元IPアドレスを知っている必要があります。
ほとんどの場合、これは接続されている他のクライアントのIPアドレスに限定されるため、すでにトンネルに認証されている他のクライアントになりすますことしかできません。

この制限があるため、ネットワークが従来のネットワークセグメンテーションに依存し、要塞ホストに依存していない場合、接続の中断が発生したり、ネットワークに対してVPN Gremlin攻撃を仕掛けたりする可能性があります。攻撃者は実際にはサーバーにとって正規のクライアントであるため、ポリシーベースのルーティングやゼロトラストネットワークは、このようなケースを防御できないかもしれません。
企業によっては、脆弱なデバイスを隔離されたネットワーク環境に「隔離」し、脆弱であってもファームウェアにパッチを適用するためにオフラインにすることができない単一障害点のネットワークスイッチ/ルーターがある場合など、限られた数の従業員にアクセスを制限しているところもあります。

この一見正規と思えるクライアントは、実はVPN Gremlin攻撃であり、この隔離されたネットワークはまだアクセス可能です。これはまた、ステートレスなプロトコルベースの脆弱性を使用する必要がありますが、まれに存在します。

図6.保護されたネットワーク内のデバイスを介したDoSの例

ケース2：トンネル内にDNSサーバーがある場合のDNSスプーフィング/ハイジャック

2番目のケースは、オフパスTCP攻撃の実行に関連するものです。『Yossi GiladおよびAmir Herzberg. 2014年著。オフパスTCPインジェクション攻撃。
ACM Trans. Inf. Syst. Secur. 16, 4, Article 13（2014年4月）』の調査結果によると、オフパスTCP攻撃を行う方法の1つに、DNSキャッシュポイズニングがあります。

そこで当社では、VPN Gremlin攻撃がDNSキャッシュポイズニングで機能するように、ネットワークアーキテクチャを考案しました。このアーキテクチャは、SSL VPNトンネル内にDNSサーバーを配置するものです
（つまり、すべてのSSL VPNクライアントとイントラネットクライアントは、DNSを使用するためにはSSL VPNまたはそのブリッジに接続しなければなりません）。

図7.DNSスプーフィングの例

まとめ

VPN Gremlin攻撃はなりすまし型の脆弱性攻撃であるため、そのエクスプロイトプリミティブ（悪用の手法）は性質上非常に限られています。しかし、この調査では2つの重要なポイントが明確になりました。1つ目は、VPNのトンネリング攻撃対象領域に関する調査がほとんど、あるいはまったく行われていないこと。2つ目は、かつては理論上のものと考えられていた攻撃が、2024年の実際の状況を見ると実現可能になっていることです。後日、攻撃が（次に示すように）わずかなコマンドで実行可能であることがわかったため、Scapyにはすべてのベンダーのプロトコルを実装しませんでした。

ip addr add 偽装IP> dev ppp0 peer ピアIP>
ip r add 標的ip> dev ppp0
ping -I 偽装IP> 標的IP>

したがって、新たなゼロデイ脆弱性攻撃から身を守るためには、企業は多層防御対策を採り入れなければならないということになります。たとえば、VPN Gremlin攻撃は、ルーターとファイアウォールがパケットを正しくルーティングおよびブロックするという基本的な前提を覆しています。要塞ホスト（複雑なTCP接続が必要）を使用してネットワークセグメンテーションを実装するか、ネットワークセグメントを移動したり、イントラネット上のデバイスにアクセスしたりする際に認証を要求するなど、2番目のレイヤでゼロトラスト・ネットワーク・アーキテクチャを適用することで、VPNベースの攻撃が成功する可能性をかなり低減させることができます。

最後に、Scapyレイヤの実装については、GPL-2こちらで公開しています。