セキュリティ研究者 Silverfortエージェントレス認証プラットフォームを提供する企業は、ハッカーがCisco Adaptive Security Appliance（ASA）を制御できる深刻な脆弱性を発見しました。すべてのASAバージョンが影響を受けます。Ciscoに脆弱性を報告した後、CiscoはサポートされているすべてのバージョンのASAと 勧告を発表しました この脆弱性（CVE-2020-3125）には、CVSSリスクスコアが10点満点中8.1点と割り当てられており、「高」とみなされています。これは、この脆弱性により攻撃者が Kerberos Cisco ASAへの認証。 Silverfort この脆弱性を発見した研究者は、ヨアブ・イエリン、 Yaron Kassner、ドール・シーガル＆ Rotem Zach.
CiscoはASAの全バージョンでこの脆弱性を修正しました。企業の皆様には、この脆弱性を悪用されるのを防ぐため、最新のASAバージョンへのアップグレードを強くお勧めします。
この記事では、KDCスプーフィングの脆弱性について概説し、Cisco ASAへの認証を回避するためにこの脆弱性がどのように悪用されるかを示します。また、Kerberosを実装する開発者、および既にネットワークにこれらのソリューションを導入している企業向けに、これらの脆弱性を回避する方法についても解説します。
脆弱性の説明
脆弱性は、CiscoのKerberos実装にあります。Kerberosは、オンプレミス認証で最も一般的な認証プロトコルです。企業ネットワークで広く利用されています。 Active Directoryまた、NTLMのような脆弱な認証プロトコルよりも好ましい。
Ciscoは、VPN、ファイアウォールセッションの開設、Web管理コンソールまたはSSH経由の管理アクセスなど、多くのASAインターフェースでKerberos認証プロトコルを使用しています。そのため、Kerberos認証をバイパスすることで、攻撃者はCiscoアプライアンスを乗っ取り、セキュリティを回避し、他のネットワークへのアクセス権を取得することが可能になります。
Kerberosプロトコルが機能するためには、次の3つのことが起こる必要があります。
- ユーザーがサーバーに対して認証を行う
- サーバーはクライアントに対して認証を行う
- KDCはサーバーに対して認証を行う
KDCによるサーバー認証は、しばしば見落とされがちです。おそらく、認証を必須にすると設定が複雑になるためでしょう。しかし、KDCがサーバー認証を行わない場合、プロトコルのセキュリティは完全に損なわれ、ネットワークトラフィックを乗っ取った攻撃者が、誤ったパスワードであっても、任意のパスワードでCisco ASAに認証できてしまう可能性があります。
経歴
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年、Dug SongはKerberosプロトコルに影響を与える脆弱性を報告した（Song, Dug.2000）。 Kerberos KDCスプーフィングの脆弱性。 8月28日
彼は、Kerberosクライアントの特定の実装と構成では、クライアント/サーバー間の交換が実行されず、以前の交換の成功に基づいて認証が許可されてしまうことを発見しました。残念ながら、この動作は安全ではなく、攻撃者によって悪用される可能性があります。クライアントとドメインコントローラー間の通信を乗っ取ることができる攻撃者は、以下の手順を実行できます。
- 偽のKDCを作成する。
- 攻撃対象のサービスへのアクセス権限を持つユーザー名を取得してください。
- 偽のKDCに、攻撃者が選択したパスワードを持つユーザーを作成します。ここでは例として、このパスワードを「1」とします。
- 取得したユーザー名とパスワード「1」を使用してサービスに認証してください。
- クライアントからデータセンターへの通信を乗っ取り、偽のキーデータセンターに転送する。
- AS Exchange の実行中に、パスワード「1」、偽の KDC キー、および偽のログオン セッション キーに対応する AS_REP を返します。
- TGS交換中は、TGS_REPを返してください。
- クライアントは、アプリケーションの交換を行うことなく認証を受け入れます。
KDCスプーフィング攻撃は、攻撃者がKDCとの間のトラフィックをハイジャックし、KDCに代わって応答できることを前提としています。これはさまざまな手法を使用して実行できます。たとえば、攻撃者がクライアントと同じ物理ネットワークセグメント内にいる場合、Network Security Hacksで説明されているようにARPスプーフィング攻撃を実行できます。 ロックハート2007別の方法としては、スイッチやルーターなどのネットワーク機器を乗っ取り、そこから通信を制御するという方法もある。
Cisco ASAの脆弱性を発見した経緯
私たちは追加する方法を探していました 多要素認証 Cisco ASAおよびAnyconnect VPNにアクセスする管理者に対してMFA（多要素認証）を実施しました。CiscoをKerberosを認証プロトコルとして使用するように構成した後、認証ログを調べました。 Silverfortのコンソール。 Silverfort ネットワーク内のすべての認証アクティビティを完全に可視化します。 Silverfortログによると、Cisco ASAはサービスチケットを要求せずにTGTを要求していた。
設定ガイドに戻りました シスコ。2007年。 PIX/ASA：ASDM/CLIによるVPNクライアントユーザー向けKerberos認証およびLDAP認可サーバーグループの設定例。 30月XNUMX日。 そして、Kerberos認証を設定するために必要なパラメータを確認しました。
上記のとおり、Kerberos認証用のパスワードやキータブの設定を入力する場所がありません。パスワードまたはキータブは、KerberosがKDCに対して信頼できる方法で認証を行うために使用する「秘密鍵」を作成するため、正しく実装するには必須です。「秘密鍵」がないと、認証は暗号学的に信頼できるものとはなりません。
他のCiscoインターフェースでも同様のテストを行ったところ、ファイアウォールセッションのオープン時、管理者認証時、さらにはSSHを使用してVMにアクセスする場合でも、同じ脆弱性が存在することが確認されました。Ciscoがサポートするさまざまな認証プロトコルをまとめた表のKerberosの列を以下でご確認ください。
搾取
次に、この脆弱性が悪用できるかどうかを確認したかった。そのため、ドメインコントローラー（DC）宛てのKerberosトラフィックをハイジャックし、自社サーバーに転送した。独自のKDCロジックを開発する代わりに、不正サーバーにAD Domain Servicesをインストールし、自社サーバーをドメインコントローラーに昇格させた。もちろん、元のドメインの管理者権限は持っていないため、新しい偽ドメインを作成した。
最初のドメインのCisco管理者のユーザー名（この例ではBob）がわかっているので、偽のドメインにBobという名前のユーザーを作成しました。偽のドメインでのそのユーザーのパスワードを「1」に設定しました。
次に、以下の状況を試してみました。
- 通常ログイン（トラフィックの迂回なし） – 予想通り、ボブの元のパスワードでログインできました。パスワード「1」を試したところ、ログインに失敗しました。
- トラフィックを偽のドメインコントローラーに迂回させてログインを試みたところ、ボブの元のパスワードではログインに失敗しましたが、パスワード「1」ではログインできました。
予防と緩和
セキュリティ専門家向けのリスク軽減策
- まず最初に、Cisco ASA を修正済みバージョンにアップグレードし、必要な設定変更を行ってください。 シスコの勧告
- Kerberos認証を継続的に監視してください。AS_REQのみを要求するリソースを探してください。TGS_REQが全くない場合は、危険信号です。
- Silverfortさん Silverfortのオープンソースツール サービスチケットを要求しないサービスを認証ログから検索する。
- Kerberosを実装する社内開発アプリケーション、およびご自身で構成したシステムについては、開発者向け推奨事項を参照してください。
- Silverfort 顧客はPalo Alto Networksのステップアップ認証機能を活用しており、 Silverfort PAN-OSのアップグレード後、MFAポリシーをTGTポリシーからサービスチケットポリシーに変更しました。
開発者として
KDCスプーフィングの影響を受けないようにするために、以下の手順をお勧めします。
- Kerberos の実装にパスワードまたはキータブが必要であることを検証します。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)
