*****ヨアヴ・イェリン著 Yaron Kassner、ドール・シーガル＆ Rotem Zach, Silverfort*****
KDC スプーフィングはいつの時代も健在です。KDC スプーフィングの脆弱性については、 Cisco ASA (NAIST) と パロアルトネットワークス PAN-OS 2020年5月に報告しました。現在では、IBM QRadarも脆弱性があることをお伝えできます。 Kerberos が実装されました。
KDCスプーフィングの脆弱性により、攻撃者はQRadarへのKerberos認証を回避し、結果としてシステムへの管理者アクセス権を取得できます。当社はこの問題の解決に向けてIBMのエンジニアと緊密に協力しており、その結果、最近リリースされた修正プログラムが完成しました。 セキュリティ情報 このブログ記事では、脆弱性の概要、Kerberosを実装する開発者としてこれらの脆弱性を回避する方法、およびQRadarやKerberosを使用するその他のシステムを使用している組織向けの緩和策について説明します。
脆弱性の説明
IBM QRadarセキュリティ情報およびイベント管理（SIEM）は、セキュリティチームが企業全体の脅威を検知して優先順位付けするのに役立ち、インシデントの影響を軽減するためにチームが迅速に対応できるようにする重要な洞察を提供します。
この脆弱性は、IBMのKerberosプロトコルの実装にあります。Kerberosは、オンプレミス認証で最も一般的な認証プロトコルです。その人気から、企業ネットワークで広く使用されています。 Active Directoryまた、NTLMのような脆弱な認証プロトコルよりも好ましい。
IBMは、管理者アクセス認証にKerberos認証プロトコルを使用しています。そのため、Kerberos認証を迂回することで、攻撃者は正当な認証情報なしにIBM QRadarへの管理者アクセス権を取得し、機密情報を閲覧したり、ログを改ざんしたりすることが可能になります。
Kerberosプロトコルが機能するためには、次の3つのことが起こる必要があります。
- ユーザーがサーバーに対して認証を行う
- サーバーはクライアントに対して認証を行う
- KDCはサーバーに対して認証を行う
KDCによるサーバー認証は、しばしば見落とされがちです。おそらく、認証を必須にすると設定が複雑になるためでしょう。しかし、KDCがサーバー認証を行わない場合、プロトコルのセキュリティは完全に損なわれ、ネットワークトラフィックを乗っ取った攻撃者が、誤ったパスワードであっても、任意のパスワードでQRadarに認証できてしまいます。
Kerberosの用語やKDCスプーフィング攻撃の仕組みに関する背景情報については、このブログ記事の最後をご覧ください。
QRadarの脆弱性を発見した経緯
QRadarへの管理者アクセスは、不正アクセスやシステム改ざんを防ぐために強力な認証で保護する必要があります。Active Directory認証を使用する方法はよく用いられます。
管理者が QRadar に認証を行う際、管理者を認証するためにいくつかのパラメータが使用されます (以下は実装ガイドのスナップショットです)。 こちらまず、QRadar は AD から TGT を要求します。TGT を受け取った後、QRadar はドメイン コントローラーに対して LDAP 認証用のサービス チケットを要求します。認証が成功すると、QRadar は SASL を使用して LDAP で DC に対して認証を行います。サービス チケットを使用してユーザーの身元を証明します。
Kerberos/SASL認証のなりすまし
攻撃者がこの種の認証を回避するために DC を偽装する手順は次のとおりです。QRadar と DC 間のネットワーク通信をハイジャックできると仮定します。この場合、管理者のユーザー名と同一のユーザー名と任意のパスワードを持つ偽の DC を作成できます。次に、選択したユーザー名とパスワードを使用して QRadar への認証を開始します。QRadar は Kerberos で認証しますが、Kerberos 通信をハイジャックして、選択したパスワードに対応する AS_REP と、選択したサービス セッション キーで暗号化されたサービス チケットと、選択したパスワードで暗号化されたセッション キーで構成される TGS_REP を返します。これらの段階では、QRadar 側で行われる検証は選択したパスワードのみに依存するため、この時点では QRadar は認証を拒否しないはずです。QRadar がサービス チケットを受信したので、DC に対して LDAP リクエストを開始できます。LDAP トラフィックもハイジャックします。現時点で、私たちには2つの選択肢があります。
1. LDAPがTLSなしで使用されている場合、LDAPトラフィックをハイジャックできます。QRadarは、取得したサービスチケットを含むKerberos AP_REQメッセージを使用して、ドメインコントローラーにバインド要求を送信します。選択したサービスセッションキーに基づいてAP_REPを返すと、QRadarはそれを受け入れます。
2. LDAPSが構成済みです。この場合、TLSを使用してDCを認証するため、DCに代わって応答を返すことはできません。これは、証明書がQRadar側に構成されていることを前提としています。
QRadarにおけるKerberos/SASL/LDAPS認証の偽装
オプション2を諦める前に、次のような奇妙な動作に気づきました。サーバーURLとしてIPアドレスを設定すると、認証がまだ機能します。理論的には、IPアドレスによる認証は機能しないはずです。 Kerberosは、SPNが明示的に設定されていない限り、IPアドレスに対する認証を許可しません。
TGS_REQ を送信すると、QRadar は ldap/ へのチケットを要求します。DC にはその名前のサービス プリンシパル名 (SPN) がないため、KRB_ERR_S_PRINCIPAL_UNKOWN エラーが返されます。Kerberos プロトコルによれば、QRadar はこの時点で認証を拒否するはずです。しかし、ネットワーク キャプチャによると、エラー発生後も LDAP リクエストが開かれ、QRadar によってすぐにリセットされます。その後、ユーザーはログインできるようになります。このことから、QRadar は Kerberos アプリケーション交換が完了する前でも認証が成功したとみなしていることがわかります。これは簡単に悪用できます。攻撃者は、AS_REP を偽装した直後に KRB_ERR_S_PRINCIPAL_UNKOWN を送信することで、任意のパスワードによる認証を QRadar に受け入れさせることができます。攻撃の手順を以下に示します。
QRadarには、存在しないユーザーに対してActive Directory（AD）への認証を要求するバグが存在します。QRadarにはローカル管理者ユーザーが組み込まれています。QRadarは、この管理者ユーザーで認証を試みる際に、まずKerberosを使用してドメインコントローラー（DC）への認証を試みます。このユーザー名はADに存在する必要はありません。そのため、攻撃者は事前にユーザー名を知っているため、攻撃が容易になります。
さらに、このバグはそれ自体が脆弱性とみなされる可能性があります。KDCスプーフィングとは関係なく、攻撃者がヘルプデスクアカウントを乗っ取るなどしてActive Directoryでユーザーを作成する権限を取得できれば、攻撃者はActive Directoryに「admin」という名前のユーザーを作成できます。そして、攻撃者はそのユーザーを使用してQRadarへの認証を行うことができます。
搾取
QRadarに脆弱性があることが判明したため、QRadarとKDC（この場合はドメインコントローラー）間のポート88（Kerberosポート）のトラフィックを自社のWindows Serverにリダイレクトすることで、攻撃をシミュレーションしました。Windows Server上に偽のドメインを設定し、実際のドメインにQRadar管理者と同じUPNを持つユーザーが存在することを確認しました。偽のドメインでは、そのユーザーのパスワードを「1」に設定しました。
次に、以下の状況を試してみました。
– 通常ログイン（トラフィックの迂回なし） – 予想通り、管理者の元のパスワードでログインできました。パスワード「1」を試したところ、ログインに失敗しました。
– トラフィックを偽のドメインコントローラーに迂回させてログインする – 管理者の元のパスワードでログインすると失敗しましたが、パスワード「1」でログインすると成功しました。
IBMの緩和策
IBMのこの脆弱性対策は、シンプルかつ安全です。QRadarへの認証機能はLDAPSでも全く同じように実現できるため、推奨される対策はKerberos認証からLDAPS認証に切り替えることです。その後、IBMが提供するパッチをインストールしてください。パッチは認証がLDAPSに設定されていることを検証し、LDAPS認証に切り替えていない場合はエラーとなります。これは、パッチ適用後にシステムが安全であることを保証するためです。
あなたが使っているなら Silverfort QRadarへの認証を保護するには、 Silverfort QRadarのポリシーとして、Kerberos TGTリクエストではなくLDAPS認証を保護するように設定する。
予防と緩和
セキュリティ専門家向けのリスク軽減策
1. スイッチ認証KerberosからLDAPSへのQRadar
2. QRadarを固定バージョンにアップグレードしてください。
3. アップデートする Silverfort QRadarのポリシーはそれに応じて適用されます
4. Kerberos認証を継続的に監視してください。AS_REQのみを要求するリソースを探してください。TGS_REQがない場合は、危険信号です。
5。 使用 Silverfortのオープンソースツール サービスチケットを要求しないサービスを認証ログから検索する。
6. Kerberosを実装する社内開発アプリケーション、およびご自身で構成したシステムについては、開発者の推奨事項を参照してください。
開発者として
KDCスプーフィングの影響を受けないようにするために、以下の手順をお勧めします。
1. Kerboros の実装にパスワードまたはキータブが必要であることを検証します。DC を検証するには、何らかの共有シークレットを使用する必要があります。ソリューションでキータブ ファイルの構成、または サービスアカウント パスワードの場合、アプリケーションは間違いなくKDCスプーフィングに対して脆弱です。
2. Wiresharkを実行する – Wiresharkを使用して、認証中に送信されるKerberosリクエストを確認します。TGS_REQがない場合は、問題があります。
3. 認証プロトコルを独自に実装する場合は、プロトコルのRFC（Request for Comments）を厳密に遵守する必要があります。より簡単な方法として、既存のプロトコル実装を利用することをお勧めします。
4. サードパーティライブラリを適切に使用する – 一部のサードパーティライブラリは、KDC スプーフィングを回避するために特定の構成を必要とします。たとえば、Kerberos でよく使用される pam-krb5 というライブラリは、正しく動作するためにキータブを構成する必要があります。ドキュメントからの関連段落は次のとおりです (https://github.com/rra/pam-krb5/blob/master/README.md)
次は何ですか？
KDCのなりすましに関する新たな脆弱性を発見しました。ベンダーがパッチを公開するまでは記事にしませんが、近いうちに記事を公開する予定です。それまでは続報をお待ちください。
経歴
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 Spoofing Vulnerability. 8月28日.）。
彼は、Kerberosクライアントの特定の実装と構成では、クライアント/サーバー間の交換が実行されず、以前の交換の成功に基づいて認証が許可されてしまうことを発見しました。残念ながら、この動作は安全ではなく、攻撃者によって悪用される可能性があります。クライアントとドメインコントローラー間の通信を乗っ取ることができる攻撃者は、以下の手順を実行できます。
1. 偽のKDCを作成します。
2. 攻撃対象のサービスへのアクセス権限を持つユーザー名を取得します。
3. 偽のKDCに、攻撃者が選択したパスワードを持つユーザーを作成します。説明のために、このパスワードを「1」としましょう。
4. 取得したユーザー名とパスワード「1」を使用してサービスに認証します。
5. クライアントから DC への通信を乗っ取り、偽の KDC に転送する。
6. AS Exchange の実行中に、パスワード「1」、偽の KDC キー、および偽のログオン セッション キーに対応する AS_REP を返します。
7. TGS交換中にTGS_REPを返します。
8. クライアントは、アプリケーションの交換を行うことなく認証を受け入れます。
KDC スプーフィング攻撃は、攻撃者が KDC との間のトラフィックをハイジャックし、KDC の代わりに応答できることを前提としています。これはさまざまな手法を使用して実行できます。たとえば、攻撃者がクライアントと同じ物理ネットワークセグメント内にいる場合、ネットワークセキュリティハック (ロックハート2007別の方法としては、スイッチやルーターなどのネットワーク機器を乗っ取り、そこから通信を制御するという方法もあります。
