Palo Alto Networks は、PAN-OS の KDC スプーフィング脆弱性に関する勧告を公開しました。この脆弱性は、 Silverfort 研究者ヨアブ・イエリン、 Yaron Kassner (NAIST) と Rotem Zachこの脆弱性は、サポートされているすべてのバージョンのPAN-OSと、Kerberosを使用するすべてのインターフェースに影響を与えました。認証プロファイル。脆弱性を公表した後、Palo Alto Networks はサポートされているすべてのバージョンの PAN-OS を修正し、アドバイザリーそれについて。この脆弱性により、攻撃者は Kerberos PAN-OSへの認証を行い、PAN-OSの管理インターフェースへのアクセス権を取得するとともに、キャプティブポータルを介してファイアウォールセッションへの認証を行います。

この脆弱性は、研究者らがCisco ASAでKDCスプーフィングの脆弱性を発見Kerberos認証プロトコルの実装が常に正しく完了しているとは限らず、システムが脆弱性を悪用される可能性があるようです。

Palo Alto Networksは、PAN-OSの全バージョンにおいてこの脆弱性を修正しました。悪用を防ぐため、このパッチを適用することを強くお勧めします。

この記事では、PAN-OSにおけるKDCスプーフィングの脆弱性について概説し、パスワードを知らなくても認証を回避するためにこの脆弱性がどのように悪用されるかを示します。また、Kerberosを実装する開発者、およびシステムにKerberos認証を使用している企業が、これらの脆弱性を回避する方法についても解説します。

脆弱性の説明

この脆弱性は、Palo Alto Networks の Kerberos 実装にあります。Kerberos は、オンプレミス認証で最も一般的な認証プロトコルです。企業ネットワークで広く利用されています。 Active Directoryまた、NTLMのような脆弱な認証プロトコルよりも好ましい。

Palo Alto Networksは、多くのPAN-OSインターフェース（SSL VPN、キャプティブポータル、管理者ログインなど）でKerberos認証プロトコルを使用しています。そのため、Kerberos認証をバイパスすることで、攻撃者はPalo Alto Networks Strataを管理し、セキュリティを回避して、他のネットワークへのアクセス権を取得することが可能になります。

Kerberosプロトコルが機能するためには、次の3つのことが起こる必要があります。

ユーザーがサーバーに対して認証を行う
サーバーはクライアントに対して認証を行う
KDCはサーバーに対して認証を行う

KDCによるサーバー認証は、しばしば見落とされがちです。おそらく、認証を必須にすると設定が複雑になるためでしょう。しかし、KDCがサーバー認証を行わない場合、プロトコルのセキュリティは完全に損なわれ、ネットワークトラフィックを乗っ取った攻撃者が、誤ったパスワードであっても、任意のパスワードでPAN-OSに認証できてしまいます。

PAN-OSの脆弱性の発見

追加しようとしたときに脆弱性を発見しました SilverfortSSL VPN、キャプティブポータル、管理者ログインなど、Kerberosプロトコルに依存するインターフェイスへのMFAを設定します。これを設定するには、認証方法としてKerberosを設定し、対応するMFAポリシーを構成 Silverfort 補足。KerberosプロトコルとKDCスプーフィングに関する詳細な説明は、この記事の最後に記載されています。
以下に示すように、ネットワークキャプチャにはAS-REQとAS-REPは含まれていますが、TGS-REQは含まれていません。

TGS-REQはプロトコルで必須ですが、認証プロセスで欠落していたにもかかわらず、認証は成功しました。 Cisco ASAにも同様の脆弱性がある私たちはこれを検証したかったのです。

私たちはPalo Alto NetworksのKerberos認証設定ガイドを改めて確認しました。以下は、その時点でのガイドのスクリーンショットです。

設定プロセスのどの段階においても、キータブやサービスパスワードを設定する必要がないことに気づきました。PAN-OSにはキータブを設定するオプションがありますが、これは任意です。しかし、キータブを設定しても、前述のインターフェースへの認証プロセスには使用されないことがわかりました。キータブやパスワードがない場合、PAN-OSはKDCの正当性を検証するために必要な認証情報を持っていません。つまり、PAN-OSはKDCのなりすまし攻撃に対して脆弱であるということです。

脆弱性を悪用しようとする

PAN-OSに脆弱性があることが判明したため、PAN-OSとKDC（この場合はドメインコントローラー）間のトラフィックをポート88（Kerberosポート）で自社のWindows Serverにリダイレクトすることで、攻撃をシミュレートしました。Windows Server上に偽のドメインを設定し、実際のドメインのPAN-OS管理者と同じユーザープリンシパル名（UPN）を持つユーザーが存在することを確認しました。この例では、そのユーザーを「Bob」と呼びます。偽のドメインでは、そのユーザーのパスワードを「1」に設定しました。

次に、以下の状況を試してみました。

通常ログイン（トラフィックの迂回なし） – 予想通り、ボブの元のパスワードでログインできました。パスワード「1」を試したところ、ログインに失敗しました。
トラフィックを偽のドメインコントローラーに迂回させてログインを試みたところ、ボブの元のパスワードではログインに失敗しましたが、パスワード「1」ではログインできました。

予防と緩和

セキュリティ専門家向けのリスク軽減策

まず最初に、PAN-OS を固定バージョンにアップグレードし、必要な構成変更を行ってください。 Palo Alto Networks アドバイザリ.
Kerberos認証を継続的に監視してください。AS_REQのみを要求するリソースを探してください。TGS_REQが全くない場合は、危険信号です。
　 Silverfortのオープンソースツールサービスチケットを要求しないサービスを認証ログから検索する。
Kerberosを実装する社内開発アプリケーション、およびご自身で構成したシステムについては、開発者向け推奨事項を参照してください。
Silverfort 顧客はPalo Alto Networksのステップアップ認証機能を活用しており、 Silverfort MFA PAN-OSをアップグレードした後、TGTポリシーからサービスチケットポリシーにポリシーを変更しました。

開発者として

KDCスプーフィングの影響を受けないようにするために、以下の手順をお勧めします。

Kerboros の実装にパスワードまたはキータブが必要であることを確認します。DC を検証するには、何らかの共有シークレットを使用する必要があります。ソリューションでキータブファイルの構成が有効になっていない場合、またはサービスアカウントパスワードの場合、アプリケーションは間違いなくKDCスプーフィングに対して脆弱です。
Wiresharkを実行してください。Wiresharkを使用して、認証中に送信されるKerberosリクエストを確認します。TGS_REQが存在しない場合は、問題があります。
認証プロトコルを独自に実装する場合は、プロトコルのRFC（Request for Comments）を厳密に遵守する必要があります。より簡単な方法として、既存のプロトコル実装を利用することをお勧めします。
3を使用^rd パーティライブラリを適切に – 3つ^rd パーティライブラリは、KDC スプーフィングを回避するために特定の構成が必要です。たとえば、Kerberos で使用される一般的なライブラリである pam-krb5 は、正しく動作するためにキータブを構成する必要があります。以下は、ドキュメントからの関連する段落です (https://github.com/rra/pam-krb5/blob/master/README.md)

経歴

Kerberosプロトコルの概要

Kerberos認証プロトコルは、1980年代にスティーブ・ミラーとクリフォード・ニューマンによって開発されました。これは、管理されたネットワークでのシングルサインオン（SSO）を可能にし、 Active Directory （AD）の実装により、オンプレミスの企業環境における主要な認証プロトコルとなった。

このプロトコルは、ユーザーとアクセス先のサーバー間の相互認証を行うための3つの交換から構成されています。ユーザーがログインすると、認証情報を入力し、認証サービス（AS）交換が行われます。ユーザーはチケット発行チケット（TGT）を取得し、これは後にチケット発行サービス（TGS）交換中に特定のサービスへのチケットを取得するために使用されます。その後、このチケットはクライアント/サーバー交換中に使用され、認証が完了します。

1. 認証サービス (AS) Exchange

AS 交換中、ユーザーはキー配布センター (KDC) で認証を行います。その見返りとして、ユーザーは認証情報を再入力することなく、ネットワーク内のサービスで認証するために必要なチケットとキーを取得します。ユーザーが最初に認証情報を入力すると、クライアントは KDC の認証サービス (AS) 機能に AS_REQ を送信します。AS_REQ は、ユーザーのパスワードの関数であるマスターキーで署名されたメッセージです。KDC の一部である認証サービスは、KDC も利用できるマスターキーに従って AS_REQ を検証します。AS_REQ の検証後、KDC はログオンセッションキーと、KDC のキーで暗号化されたチケット発行チケット (TGT) を含む AS_REP を返します。AS 交換の概要を以下に示します。TGT は、TGS 交換で特定のサービスへのアクセス権を取得するために使用されます。

2. チケット発券サービス（TGS）交換

ユーザーがネットワーク上のサービスにアクセスしようとすると、KDC のチケット発行サーバー (TGS) 機能に TGS_REQ が送信されます。このメッセージは、AS Exchange で取得されたログオンセッションキーで暗号化されます。TGS_REQ は TGS によって検証され、TGS_REP が返されます。TGS_REP には、サービスセッションキーとサービスチケットが含まれており、サービスチケットは、サービスをホストするサーバーのマスターキーで暗号化されています。Unix ベースのシステムでは、サーバーのマスターキーはキータブファイルと呼ばれるファイルで構成されます。メンバサーバーのマスターキーは、コンピューターアカウントのパスワードから生成されます。TGS Exchange の概要を以下に示します。

3. クライアント/サーバー交換

これでクライアントはサービス認証に必要なすべての情報を手に入れました。クライアントはサービスセッションキーで暗号化されたAP_REQをサービスに送信します。サービスはサービスセッションキーを復号してAP_REQを検証します。その後、サーバーはAP_REPメッセージを返し、認証が完了します。クライアントとサーバー間のやり取りの概要は以下のとおりです。

なりすまし防止プロトコル

Kerberosプロトコルが正しく実装されている場合、KDCになりすまそうとする攻撃者は認証を回避できません。なぜなら、攻撃者が乗っ取ったAS_REQに対して有効なAS_REPを正常に作成したとしても、有効なサービスチケットを偽造することは決してできないからです。サービスチケットはサーバーキーで暗号化されており、攻撃者はそのキーを持っていないため、それは不可能です。

KDCスプーフィングとは何ですか？

2000年、後にDuoセキュリティを共同設立したDug Songは、技術状況によっては、Kerberosプロトコルを回避するために使用される。

彼は、Kerberosクライアントの特定の実装と構成では、クライアント/サーバー間の交換が実行されず、以前の交換の成功に基づいて認証が許可されてしまうことを発見しました。残念ながら、この動作は安全ではなく、攻撃者によって悪用される可能性があります。クライアントとドメインコントローラー間の通信を乗っ取ることができる攻撃者は、以下の手順を実行できます。

偽のKDCを作成する。
攻撃対象のサービスへのアクセス権限を持つユーザー名を取得してください。
偽のKDCに、攻撃者が選択したパスワードを持つユーザーを作成します。ここでは例として、このパスワードを「1」とします。
取得したユーザー名とパスワード「1」を使用してサービスに認証してください。
クライアントからデータセンターへの通信を乗っ取り、偽のキーデータセンターに転送する。
AS Exchange の実行中に、パスワード「1」、偽の KDC キー、および偽のログオンセッションキーに対応する AS_REP を返します。
TGS交換中は、TGS_REPを返してください。
クライアントは、アプリケーションの交換を行うことなく認証を受け入れます。

KDCスプーフィング攻撃は、攻撃者がKDCとの間のトラフィックをハイジャックし、KDCに代わって応答できることを前提としています。これはさまざまな手法を使用して実行できます。たとえば、攻撃者がクライアントと同じ物理ネットワークセグメント内にいる場合、Network Security Hacksで説明されているようにARPスプーフィング攻撃を実行できます。ロックハート2007別の方法としては、スイッチやルーターなどのネットワーク機器を乗っ取り、そこから通信を制御するという方法もある。