VPN への寄生 — VPN Post-Exploitation 手法に関する調査
エグゼクティブサマリー
このブログ記事では、Akamai の研究者が、見過ごされている VPN Post-exploitation の脅威を明らかにします。つまり、VPN サーバーを侵害した後に、さらに侵害をエスカレートさせるために攻撃者が使用する可能性のある手法について取り上げます。
調査結果には、Ivanti Connect Secure および FortiGate VPN に影響を与えるいくつかの脆弱性が含まれています。
その脆弱性に加えて、Ivanti Connect Secure 製品や FortiGate 製品、およびその他の VPN サーバーに影響を与える可能性がある、まだ修正されていない一連の手法についても詳しく説明します。
調査では、多くの場合、侵害された VPN サーバーを利用して攻撃者がネットワーク内の他の重要な資産を簡単に制御できる可能性があることが明らかになっています。
このブログ記事はこれらのリスクに対する意識を高めることを目的としており、VPN Post-exploitation 手法のリスクを最小限に抑えるために防御者が従うべきベストプラクティスを提示します。
概要
これまでに、誰もがこのような話を聞いたことがあるはずです。VPN サーバーに重大な脆弱性が発見されました。それは実際に悪用されています。管理者が急いでパッチを適用しました。ソーシャルメディアでパニックが広がりました。
昨年は VPN セキュリティにとって、かなり厳しい 1 年でした。 1 か月 おきに 重大な脆弱性にパッチが適用されたり、攻撃者に野放し状態で悪用されている重大な脆弱性が発見されたりしました。この種のアクティビティは 2023 年に大幅に増加しましたが、新しいものではありません。VPN サーバーはインターネットからアクセス可能で、豊富なアタックサーフェスをさらしており、セキュリティや監視が不足していることが多いため、攻撃者はずっと VPN サーバーを悪用しようとしていました。
これまで、 VPN サーバーは主に、ある 1 つの目的を達成するために悪用されてきました。それは、初期アクセスです。攻撃者は、インターネットに面した VPN サーバーを侵害して、内部ネットワークへの足がかりとして利用し、侵入を実行できるようにします。
このアプローチは非常に効果的ですが、私たちは次のような疑問を抱きました。VPN サーバーを制御することを、ネットワークへのゲートウェイとして捉えるだけでよいのだろうか。
他にどのような可能性があるのかを知りたいと思ったのです。
以降では、他の手段（脆弱性、認証情報の窃取など）ですでに VPN サーバーを侵害した攻撃者がさらなる目的を達成するために使用する可能性のある VPN Post-exploitation 手法について検討します。
VPN への寄生
攻撃者が Post-exploitation 手法を実行するために使用する主なアプローチは、 デバイスの OS をターゲットにすることです。リモートコード実行（RCE）を取得した後、攻撃者はデバイス OS 上にカスタムインプラントをドロップする可能性があります。この時点から、攻撃者は VPN のあらゆる側面を制御できます。たとえば、機微な情報を漏えいする機能をフックしたり、ログを操作して検知を回避したり、デバイス上に潜伏し続けるためにシステム設定を変更したりできます。
このアプローチには多くの利点がありますが、主な欠点が 1 つあります。それは、高コストであることです。機器は通常、強化されたカスタム OS で動作するため、VPN デバイス用のカスタムインプラントを開発および維持するために必要な労力はかなりのものになる可能性があります。つまり、VPN Post-exploitation 手法は一般的に、最上位の国家的な攻撃者のみが使用していました。
別のアプローチの検討
私たちは、別のアプローチを検討することにしました。つまり、より「簡単」な形の VPN Post-exploitation です。OS 上で動作するカスタムインプラントに頼るのではなく、デバイスの既存の機能を悪用することにしました。私たちは次のような疑問を抱きました。VPN 管理インターフェースだけを使用して、攻撃者は何を達成できるだろうか？
私たちが「VPN への寄生」と名付けたこのアプローチには、少なくとも 2 つの利点があります。
このタイプのアクセスは、完全な RCE よりも簡単に取得できます。管理インターフェースへのアクセスは、認証バイパスの脆弱性、脆弱な認証情報、またはフィッシングによって取得できます。
このアプローチはカスタムペイロードの開発作業を回避できるため、よりコスト効率に優れています。
テストの対象として、市場をリードする 2 つの VPN サーバー、Ivanti Connect Secure と FortiGate をターゲットにすることとしました。私たちは 2 つの CVE と、攻撃者が VPN サーバーを制御してネットワーク内の他の重要な資産を乗っ取るために使用する可能性がある、まだ修正されていない手法を発見しました。これらにより、 VPN の侵害がネットワーク全体の侵害に発展する可能性があります。
調査結果は FortiGate と Ivanti に的を絞っていますが、私たちが発見した手法には他の VPN サーバーやエッジデバイスに関連する変種が存在する可能性があると考えられます。
リモート認証サーバーの悪用
VPN サーバーによって処理される最も興味深い資産として、外部認証情報があげられます。VPN サーバーは、認証にローカルユーザーを使用することをサポートしていますが、多くの場合、外部認証サーバーが使用されます。
管理者は、ユーザーごとに別々の認証情報セットを維持するのではなく、既存のアイデンティティプロバイダーを使用してユーザーを認証することを選択できます。ユーザーは VPN サーバーに「通常の」認証情報を送信します。この認証情報は、リモート認証サーバーを介して検証されます（図 1）。
図 1：リモート認証サーバーを使用してユーザーを認証
この目的では、複数のタイプの認証サーバーを使用できます。2 つの主なオプションは、LDAP と RADIUS です。
私たちは、攻撃者がこのふるまいを悪用して外部認証情報を侵害できるようにするいくつかの手法を特定しました。それにより、攻撃者はネットワーク内の他のリソースにアクセスできるようになる可能性があります。
LDAP 認証情報の傍受
VPN で最も一般的な認証サーバーオプションの 1 つが LDAP です。これは通常、Active Directory（AD）ドメインコントローラーです。この設定では、ユーザーはドメイン認証情報を使用して VPN にアクセスできるため、この方法は非常に便利です。
LDAP 認証サーバーを設定する場合、VPN がユーザー情報をクエリーできるようにするために、AD サービスアカウントの認証情報が提供されます。図 2 は、FortiGate におけるこの設定の例です。
図 2：FortiGate の GUI における LDAP 認証サーバーの設定画面
ユーザーが LDAP 認証情報を使用して FortiGate または Ivanti への認証を試みると、VPN は LDAP サーバーに接続してそれを検証します。実際の実行方法は FortiGate と Ivanti の間でわずかに異なるため、両方について検討します。
FortiGate の LDAP 認証
認証情報を検証するために、FortiGate はそれを使用してリモートサーバーへの認証を試みます。このプロセスは、 シンプルな認証 によって実行されます。つまり、FortiGate は パスワードをクリアテキストでサーバーに送信します （図 3）。
図 3：LDAP の簡易バインドにより、クリアテキストのユーザーパスワードが公開
このプロセス中に 2 つの認証情報が送信されます。FortiGate で設定された LDAP サービスアカウントの認証情報と、認証を行うユーザーによって提供された認証情報です。両方ともクリアテキストで送信されます。
デフォルト設定は LDAP ですが、FortiGate は LDAPS と TLS もサポートしており、それらはクリアテキスト通信を阻止するはずです。
Ivanti の LDAP 認証
Ivanti での LDAP 認証の実行は若干異なり、標準の LDAP と Active Directory の 2 種類の LDAP 認証サーバーをサポートしています（図 4）。
図 4：LDAP サーバーや Active Directory サーバーを含む Ivanti の認証サーバーオプション
LDAP 認証サーバー
LDAP 認証サーバーでは、このプロセスは FortiGate のプロセスと非常に似ています。つまり、簡易 LDAP を使用すると、簡易バインドが実行され、AD サービスアカウントの認証情報と認証を行うユーザーの認証情報の両方がクリアテキストで送信されます（図 5）。
図 5：Ivanti が LDAP 認証情報をクリアテキストで送信
ただし、LDAP 認証サーバーを設定する場合、デフォルト設定は TLS であり、LDAPS もサポートされています。そのため、Ivanti インスタンスは簡易 LDAP を使用する可能性が低いです。
AD 認証サーバー
設定可能な 2 つ目のタイプの LDAP 認証サーバーは、AD サーバーです。このオプションを使用すると、Kerberos を使用して認証が実行されます。これは、パスワードが送信されないことを意味します（図 6）。
図 6：Kerberos を使用した安全な LDAP 認証
クリアテキストの LDAP 認証情報の取得
FortiGate と Ivanti のどちらの場合も、ユーザーの認証に簡易 LDAP を使用すると、VPN に送信されるあらゆる認証情報が侵害される可能性があります。このような侵害は、VPN と LDAP サーバーの間にいる攻撃者、または VPN サーバーを制御している攻撃者によって実行される可能性があります。
どうすれば、インプラントをデバイスにドロップせずに認証情報を取得できるのでしょうか。攻撃者にとって幸いなことに、FortiGate と Ivanti のどちらにもパケットキャプチャ機能が組み込まれています。この機能を利用して LDAP パケットをキャプチャすることで、攻撃者は VPN を通過するあらゆる認証情報を傍受できます（図 7）。
図 7：FortiGate または Ivanti のパケットキャプチャ機能を使用して、LDAP 通信をキャプチャ
セキュアなプロトコルが使用されている場合、クリアテキストの認証情報はサーバーから送信されません。それにもかかわらず、 VPN を制御している攻撃者はそれを取得できます。 攻撃者が VPN を制御している場合、攻撃者が設定を変更して簡易 LDAP にダウングレードするのを阻止するものはありません。
通常の LDAP サーバーでは、設定を簡易 LDAP に変更するだけです。Ivanti の AD サーバーをダウングレードするためには、AD 接続の詳細を使用して、既存のサーバーではなく、新しい通常の LDAP サーバーを設定します。どちらの場合も、この変更はユーザーに対して透過的に行われ、それによって VPN がクリアテキストでパスワードを送信するようになります。
要するに、LDAP 認証が使用されている場合、設定に関係なく、VPN を侵害した攻撃者は簡単に認証情報を取得してドメインに侵入できます。
不正な認証サーバーの登録
前述のとおり、リモートユーザーを認証するとき、VPN は適切な認証サーバーに接続して、提供された認証情報を検証します。私たちは、この認証フローを悪用して、 ユーザーによって VPN に 提供されたあらゆる認証情報 を侵害する方法を明らかにしました。
この手法は、ユーザー認証時に VPN で使用される不正な認証サーバーを登録することにより機能します。これがどのように実行され得るのかを理解していただくために、まず両方の VPN での認証プロセスについて詳しく説明します。
FortiGate のユーザーグループ
FortiGate ユーザーには、異なる権限を付与し、異なるポリシーを適用することができます。各ユーザーを個別に管理するのではなく、ユーザーをユーザーグループ（ポリシーや権限が適用されるユーザーの集合）に含めることができます。
このようなグループを設定する際に、リモートグループ（リモート認証サーバー上に存在するグループ）のユーザーを含めることができます。たとえば、特定の AD グループのユーザーを含めることができます（図 8）。
図 8：FortiGate のユーザーグループ設定
私たちは、リモートグループを使用しているときに興味深いふるまいが発生するのを観測しました。たとえば、ローカル FortiGate ユーザーと LDAP サーバー上に存在するリモートグループの 2 つのエンティティを含むユーザーグループを設定します。
認証に関しては、次のようなふるまいが予想されます。
グループのローカルメンバーが FortiGate に対して認証を行うと、FortiGate のローカル・ユーザー・データベースを使用して認証情報が検証されます。
リモートグループのメンバーが FortiGate に対して認証を行うと、リモートグループの LDAP サーバーを使用して認証情報が検証されます。
しかし、蓋を開けてみると、 実際にはそうではありません。 リモートグループをユーザーグループに追加した後、ユーザーグループの 任意の メンバーが認証を行うと必ず、FortiGate はローカル・ユーザー・データベース と リモート認証サーバーの両方を使用して認証情報の検証を試みます。さらに、ユーザーグループに複数のリモートサーバーを追加すると、FortiGate は 設定されたすべての認証サーバーを使用してユーザーの認証を試みます。
基本的に、FortiGate はユーザーとそのユーザーに適した認証方法のマッチングを行わず、すべての方法を試みます。そして、いずれかの方法が成功すればユーザーは認証されます。
Ivanti の認証レルム
Ivanti には、 認証レルムというユーザーグループと同様の機能があります。FortiGate のユーザーグループとは異なり、Ivanti の各認証レルムは単一の認証サーバーに制限されます。異なるサーバーのユーザーを管理するためには、別のレルムを使用する必要があります。
このような制限はありますが（私たちにとっては都合の良いことです）、Ivanti では「追加の認証サーバー」を設定できます（図 9）。このオプションは、特定の SSO 設定を有効にするためのものです。
図 9：Ivanti のユーザーレルムの追加認証サーバーを設定
追加の認証サーバーが設定されると、Ivanti は両方のサーバーを使用して認証情報を検証しようとします。認証は、 両方 のサーバーが承認した場合のみ成功します。
不正認証サーバーを作成し、認証情報を漏えい
攻撃者はこれらのふるまいを悪用し、任意の種類のリモート認証サーバーを使用して FortiGate または Ivanti への認証を行うユーザーの認証情報を漏えいさせる可能性があります。不正な認証サーバーをユーザーグループまたはレルムに追加することで、VPN サーバーから攻撃者が制御しているサーバーへの認証情報の漏えいを引き起こすことができます（図 10）。
図 10：不正な認証サーバーを追加して、クライアントの認証情報を侵害
これらの認証情報は、VPN に接続しているクライアント、または管理インターフェースに接続している管理者の認証情報である場合があります。 ユーザーグループまたはレルムを使用して管理されるあらゆる認証が、この方法を使用してハイジャックされる可能性があります。
FortiGate でこれを実行するために、私たちは不正なサーバーを使用するリモートグループを作成し、それをターゲット・ユーザー・グループに追加しました。Ivanti では単に、ターゲットレルムの追加認証サーバーとして不正なサーバーを追加しました。
これで、ターゲット・ユーザー・グループ／レルムのメンバーが認証を行うときは必ず、VPN が私たちのサーバーを使用して認証情報を検証するようになりました（図 11）。
図 11：不正な RADIUS 認証サーバーをユーザーグループに追加
認証情報を取得するためには、RADIUS 認証サーバーを使用します。このシナリオでは、次の 2 つの理由により RADIUS 認証が便利です。
認証情報は、最初の要求時にサーバーに送信されます。その際、初めにユーザーがサーバー上に存在するかどうかの検証は行われません。
認証情報は、攻撃者が決定したキーで暗号化されたサーバーに送信されるため、攻撃者はクリアテキストの認証情報を復元できます（図 12）。
図 12：RADIUS 認証メッセージ内の暗号化されたパスワード
次のスクリプト（RFC 2865 に基づく）で RADIUS パスワードを復号できます。
import hashlib
# Authenticator value can be obtained from the PCAP
authenticator = bytearray.fromhex("98f245b6e3724f5873fa74e576323c67")
enc = bytearray.fromhex("15644ca055b817ce683083fecebc2902016f2890660d0dfcaee214a0dbaa1046")
# Pre-shared key configured by the attacker when setting up the rogue server
secret = bytes("verygoodpsk", "utf-8")
chunk_len = 16
enc_chunks = []
dec = ""
for i in range(0, len(enc), chunk_len):
enc_chunks.append(enc[i:i+chunk_len])
for chunk in enc_chunks:
dec_chunk = b""
chunk_key = hashlib.md5(secret + authenticator ).digest()
i = 0
for enc_byte in chunk:
dec_chunk += (enc_byte ^ chunk_key[i]).to_bytes(1,"big")
dec += chr(enc_byte ^ chunk_key[i])
i+=1
authenticator = chunk
print(dec)
最後に注意事項があります。前述のとおり、Ivanti が追加の認証サーバーを使用する場合、認証を成功させるためには 両方 のサーバーがユーザーを承認する必要があります。供給された認証情報をサーバーが承認しない場合、ユーザーは Ivanti に対する認証を行えません。これを防止するために、提供されたすべての認証情報を RADIUS サーバーが承認するようにします。この設定は簡単に行えます。
設定ファイルのシークレットの抽出
最も懸念される調査結果は、VPN 設定ファイルに関することです。
設定ファイルにはさまざまな興味深い設定が見られますが、その中でも目を引くのがシークレットです。VPN は、多くのシークレットを設定に格納します。たとえば、ローカル・ユーザー・パスワード、SSH キー、証明書がありますが、最も興味深いのはサードパーティ・サービス・アカウントの認証情報です。
攻撃者は主に次の 2 つの方法でこれらの機密ファイルを取得できます。
VPN を制御した後、攻撃者は管理インターフェースを介してデバイス設定をエクスポートできます。
攻撃者は、共有フォルダーなどのパブリックロケーションに保存され、過去にエクスポートされた設定ファイルを見つけることができます。
それらを保護するために、シークレットは暗号化された形式で設定ファイルに格納されます。図 13 は、FortiGate の設定ファイル内の暗号化されたシークレットの例です。
図 13：FortiGate の設定ファイル内の暗号化されたパスワード
それでは、いくつかのシークレットを復号してみます。
FortiGate の設定ファイルから取得したシークレットの復号
シークレットはハッシュ化されているため復元できないと考える人もいるかもしれませんが、実際にはそうではありません。たとえば、統合パスワードがあります。クリアテキストパスワードはサードパーティへの接続に必要であるため、可逆暗号化を使用して保存する必要があります。
これは、FortiGate の パスワードの暗号化 プロセスについて詳しく調べた Bart Dopheide 氏のブログ記事で証明されました。FortiGate は AES を使用して、設定内のすべてのシークレットを暗号化します。この暗号化を実行するために、どのようなキーが使用されるのでしょうか。Dopheide 氏は、 ハードコードされた 1 つのキー がすべての FortiGate 機器で使用されていることを明らかにしました。このキーは変更できませんでした。元のブログ記事でそのキーは共有されていませんが、Google でちょっと検索すればすぐに見つかります。
Fortinet はこの問題に CVE 2019-6693 を割り当て、 修正を実装 し、ユーザーがハードコードされたキーをカスタムキーに変更できるようにしました。
この修正の後も、いまだにこの問題の重要性は極めて高いです。キーは変更されていないため、 デフォルトでは、FortiGate 機器は相変わらず同じキーを使用します。 つまり、攻撃者が FortiGate 機器の設定ファイルをデフォルト設定で取得すれば、デバイスに保存されているすべてのシークレットを復号できます。 このコード は復号プロセスを実行します。
それでは、FortiGate の管理者がベストプラクティスに従い、デフォルトキーではなくカスタムキーを使用した場合はどうなるでしょうか。攻撃者が VPN を制御していれば、シークレットを簡単に取得できることがわかりました。
カスタム暗号化キーを制御するためには、 private-data-encryption 設定を使用します。驚くべきことに、管理者は簡単にこの機能を無効化できます。これには 現在設定されているキーに関する情報は必要なく、すべてのシークレットの暗号化が元のハードコードキーに戻ります。
暗号化の巻き戻し
暗号化を元に戻すためには、次の FortiGate コマンドライン・インターフェース・コマンドを使用します。
FGT # config system global
FGT (global) # set private-data-encryption disable
FGT (global) # end
この時点で、前述のとおり既知のデフォルトキーを使用して設定ファイルをダウンロードし、シークレットを復号できます。
この方法により、多くの興味深いシークレットが侵害される可能性があります。FortiGate は、「外部コネクター」機能によってさまざまなアプリケーションとの統合をサポートしています。これらのコネクターはさまざまな目的に使用されますが、ほとんどに共通する重要な側面があります。それは、アプリケーションの認証情報が必要だということです（図 14）。
図 14：FortiGate の外部コネクターオプション
つまり、FortiGate には、クラウドプロバイダー、SAP、Kubernetes、ESXi などの重要なサービスの認証情報が含まれている可能性があります。
場合によっては、その認証情報にはそれぞれのアプリケーションに対する高い権限が必要です。たとえば、「Poll Active Directory Server」統合は ドメインコントローラーへの管理アクセス権限を持つアカウントの認証情報を必要とします。そのため、FortiGate への侵害は直ちに完全なドメイン侵害になる可能性があります。
Ivanti の設定ファイルから取得したシークレットの復号
Ivanti も似たような状況です。それどころか、FortiGate よりも状況は悪いかもしれません。
Ivanti も可逆暗号化を使用してシークレットを格納します。デバイスからコードを抽出して調べると、暗号化キーとして使用されるシークレット値（この場合も静的文字列）がすぐに見つかります（図 15）。
図 15：Ivanti の静的暗号化キー
キー全体をお見せすることはできませんが、その最初の部分を調べてみると、Juniper が最後に Connect Secure を所有していた 2015 年以降、変更されていない可能性があります。
Ivanti は、格納されているシークレットの保護に努めており、FortiGate よりも複雑な暗号化アルゴリズムを実装したようです。それにもかかわらず、このプロセスは明らかにまだ可逆的です。つまり すべての Ivanti インスタンスのシークレットは、変更できない 1 つの静的キーを使用して暗号化されます。攻撃者はこの知識を利用して、 Ivanti の設定ファイルを復号する可能性があります。
Ivanti にパスワードを復号させる
私たちがとった最初のアプローチは、暗号化プロセスのリバースエンジニアリングを行って、復号ツールを作成することでした。これは確かに可能ですが、数時間かけて逆コンパイルされたコードを調べた後、私たちは概念実証として別のアプローチを採用することにしました。その手間のかかるタスクを Ivanti に行わせたのです。
このアイデアの要点は、攻撃者が所有する専用の Ivanti インスタンスに暗号化されたパスワードを「フィード」し、それを復号させるということです（図 16）。
図 16：攻撃者のラボ環境における Ivanti パスワードの復号プロセス
この復号は、次の手順で実行できます。
暗号化されたパスワードを Ivanti の設定ファイルから取得します
ラボ環境で Ivanti インスタンスと LDAP サーバー（Active Directory を実行する Windows サーバーなど）をセットアップします
ラボ用 Ivanti インスタンスで、LDAP サーバーをシンプルな認証を使用する認証サーバーとして設定します
ラボ用 Ivanti 設定をファイルにエクスポートします
設定ファイル内にある既存の暗号化された LDAP パスワードを、復号しようとしている暗号化されたパスワードに置き換えます
変更した設定ファイルを Ivanti インスタンスにインポートし直します
これで、LDAP サーバーへの認証試行をトリガーすると、Ivanti が設定からパスワードを復号し、クリアテキストで LDAP サーバーに送信します。パケットをキャプチャすれば、復号されたパスワードを取得できます（図 17）。
図 17：供給されたパスワードを Ivanti が復号し、その結果を LDAP 経由で漏えい
復号プロセスの「インターフェース」として LDAP サーバー認証を使用しますが、LDAP パスワードに限定されないことに注意してください。私たちが行ったテストにより、この手法は 設定ファイルに保存されているすべてのシークレットに対して有効 であることが明らかになりました。それには AD パスワード、RADIUS 事前共有キー、API キーが含まれますが、これらに限りません。
MDM サーバーのクリアテキストパスワード
Ivanti は、認証方式としていくつかの一般的なモバイルデバイス管理（MDM）サーバーをサポートしています（図 18）。
図 18：Ivanti の MDM サーバー設定
他の認証サーバーと同様に、この統合には MDM サーバーの認証情報が必要です。MDM サーバー設定を調べると、2 つの興味深いフィールドが見つかります。それは、「password-encrypted」と「password-cleartext」です。その名前とは裏腹に、どちらのフィールドにもクリアテキストが格納されます（図 19）。♂️
図 19：クリアテキストパスワードを含む Ivanti の MDM 設定
実際に使用されている VPN Post-exploitation 手法
この記事で取り上げた手法のいくつかは、すでに実際に使用されている可能性があります。Ivanti 機器に対する一連の攻撃キャンペーンについて取り上げた Cutting Edge レポートで、Mandiant の研究者たちは、攻撃者が Ivanti デバイスに設定されている LDAP サービスアカウントを侵害できたことについて説明しています（図 20）。
図 20：LDAP アカウント侵害について言及した Mandiant のレポート
Mandiant のレポートでは、攻撃者がこれをどのように達成できたのかについて詳しく説明していませんが、私たちの考えでは、 このブログで取り上げた方法のいずれかを使用して攻撃者が認証情報を取得できた可能性はかなり高いです。 つまり、設定ファイルから認証情報を抽出したか、ネットワークトラフィックをスニフィングしたかのいずれかです。
このような手法を実行するのは簡単であり、どんな熟練度の攻撃者でも使用できるはずです。
VPN サーバーを使用する場合の推奨事項
VPN サーバーを使用する場合は、次に示す 4 つの原則に従うことが推奨されます。これにより、前述の手法によってもたらされるリスクを最小限に抑えることができます。
ゼロトラスト・ネットワーク・アクセス（ZTNA）を採用する
サービスアカウントの権限を制限する
VPN 認証専用のアイデンティティを使用する
設定の変更を監視する
1.ゼロトラスト・ネットワーク・アクセス（ZTNA）を採用する
従来の VPN の主な問題の 1 つは、ネットワークへのアクセス権限を付与する際に「オール・オア・ナッシング」のアプローチをとり、ユーザーを「IN」（ネットワークへの完全なアクセス権限を持つ）か「OUT」（何にもアクセスできない）のいずれかに分けることです。
この「IN」と「OUT」には、どちらも問題があります。一方ではユーザーに内部アプリケーションへのリモートアクセスを提供する必要があり、他方では VPN サーバーを侵害しようとしている攻撃者がネットワークへの完全なアクセス権限を取得できないようにする必要があります。
その課題を解決するのが、ゼロトラスト・ネットワーク・アクセス（ZTNA ）です。エンティティごとにネットワーク・アクセス・ポリシーを定義することで、ユーザーが承認されたリモート操作を実行できるようにすると同時に、侵害の可能性を低減できます。
Akamai Enterprise Application Access は、アイデンティティとコンテキストに基づいて、プライベートアプリケーションに正確なアクセスを提供する ZTNA ソリューションです。アイデンティティベースのポリシーと、ユーザーの所在地、時間、デバイスセキュリティなどのリアルタイムデータを使用して、ユーザーが必要なアプリケーションにのみアクセスできるようにし、ネットワークレベルのアクセスを排除します。Akamai MFA とシームレスに連携し、強力なユーザー認証を実現します。
2.サービスアカウントの権限を制限する
この記事で説明したとおり、VPN サーバーに保存されているサービスアカウントのクリアテキストパスワードを復元するのは簡単です。VPN ではクリアテキストパスワードを使用しなければならない場合があるため、これを回避する現実的な方法はありません。
発生し得る VPN 侵害の影響を軽減するために、権限を制限された（できれば読み取り専用）サービスアカウントを使用することが推奨されます。防御者は、攻撃者が VPN に保存されている認証情報をどのように悪用できるかを理解し、VPN 侵害によって他の重要な資産が侵害されないようにする必要があります。
一部の統合を運用するためには、強力な権限を持つサービスアカウントが必要ですが、可能であれば避けるべきです。
3.VPN 認証専用のアイデンティティを使用する
VPN を制御している攻撃者が VPN ユーザーの認証情報を侵害することは簡単であることがわかりました。AD などの既存の認証サービスを使用して VPN へのユーザー認証を行うことは魅力的かもしれませんが、それは避けてください。VPN を制御している攻撃者は、認証情報を取得し、それを使用して内部資産に侵入し、VPN を Single Points of Failure にすることができます。
そうではなく、別の専用の方法で VPN へのユーザー認証を行うことが推奨されます。たとえば、認証用に特別に発行された証明書を使用して、証明書ベースの認証を行います。
4.設定の変更を監視する
前述の手法はすべて、何らかの形でデバイスの設定に影響を及ぼします。ネットワークデバイスの設定は頻繁に変更されることはないため、これらの変更は侵害を検知するための絶好の機会となる場合があります。
設定の変更を特定するために、定期的にデバイス設定を「ゴールデンイメージ」と比較することが推奨されます。また、ほとんどのデバイスには、システムイベントおよびセキュリティイベントの内部ロギング機能があります。得られるログを収集して分析し、それらを使用してデバイス設定に対する疑わしい変更を特定することが推奨されます。
これらの 4 つの原則を要約すると、盲目的に VPN を信頼してはならないということです。
まとめ
攻撃者は VPN を狙っています。それが事実です。防御者は、攻撃者が VPN にアクセスするのは時間の問題であると考え、その前提に基づいて今すぐ行動する必要があります。防御者は、VPN 侵害が完全なネットワーク侵害につながることがないようにしなければなりません。
開示のタイムライン
Ivanti
2024 年 3 月 26 日 — ベンダーへの初期報告
2024 年 4 月 5 日 — Ivanti が報告内容を認め、修正に取り組んでいることを明言
2024 年 6 月 3 日 — 8 月 7 日に調査結果を発表する予定であることを Akamai が Ivanti へ初めて通知
2024 年 6 月 27 日 — 問題の修正に取り組んでいるが、調査結果発表日までに修正されるという確証を得られないことを Ivanti が表明
2024 年 7 月 8 日 — Ivanti が、ハードコードされたキーの問題と MDM クリアテキストパスワードに CVE-2024-37374 および CVE-2024-37375 を割り当てるが、パッチはまだリリースされない
2024 年 7 月 15 日 — 予定されているリリーススケジュールについて Ivanti へ追加通知
2024 年 8 月 7 日 — 調査結果を発表
Fortinet
2024 年 3 月 22 日 — ベンダーへの初期報告
2024 年 4 月 17 日 — Fortinet の初期対応が行われ、報告された問題のいずれも修正不要と結論付けられる
2024 年 4 月 21 日 — 8 月 7 日に調査結果を発表する予定であることを Akamai が Fortinet へ初めて通知
2024 年 4 月 30 日 — 報告されたカスタム暗号化キーのバイパスを修正する予定であることを Fortinet が Akamai へ通知
2024 年 7 月 15 日 — 予定されているリリーススケジュールについて Fortinet へ追加通知
2024 年 7 月 23 日 — 調査結果発表日より前にパッチをリリースできない可能性があることを Fortinet が表明
2024 年 8 月 2 日 — 追加検討の後、「セキュリティ境界を越えない」ため、カスタム暗号化キーのバイパスを修正しないことを決定したことを Fortinet が Akamai へ通知
2024 年 8 月 7 日 — 調査結果を発表