【Windows】証明書を利用した認証における脆弱性の対処について

ドメイン コントローラーでの証明書を利用した Kerberos 認証に関して、なりすましによる特権昇格の脆弱性が確認されました。

この脆弱性の影響への対処として、証明書を利用した Kerberos 認証の処理に対してセキュリティ強化が行われます。このセキュリティ強化では、Kerberos 認証において認証対象となるアカウントと証明書のマッピングの有無を確認する処理が追加されます。

この変更により、証明書を利用した Kerberos 認証への影響がでることが想定されます。無線 LAN 認証やリモートデスクトップ接続の認証など、証明書を利用した認証が失敗して、サービスが利用できない問題が発生する可能性があります。

このセキュリティ強化の変更が強制されるのは、2023 年 11 月のセキュリティ更新のタイミングと予定されています。そのため、2023 年 11 月までに必要な事前準備を完了していただく必要があります。

今回は、証明書を利用した認証における脆弱性の対処について紹介します。

証明書を利用した Kerberos 認証の脆弱性について

ドメイン コントローラー(Kerberos Distribution Center(KDC) サービス)で、証明書を利用した Kerberos 認証の要求を受け取った時に、なりすましによる特権昇格の脆弱性が発見されました。この脆弱性は、CVE-2022-34691、CVE-2022-26931 と CVE-2022-26923 の ID で管理されています。

これまで、証明書を利用した Kerberos 認証の処理において、コンピューター名の末尾の ‘$’ は考慮されていませんでした。これが要因で、なりすましで認証に通ることが可能でした。また、ユーザー プリンシパル名(UPN) と sAMAccountName の競合を利用した、他のなりすましを行うことができる脆弱性も確認されております。

この脆弱性の対処として、証明書を利用した Kerberos 認証の処理に対してセキュリティ強化が行われます。このセキュリティ強化では、認証の処理において認証対象となるアカウントと証明書のマッピングの有無を確認する処理が追加されます。この変更により、証明書を利用した Kerberos 認証への影響がでることが想定されます。

証明書を利用した Kerberos 認証を利用するシナリオの例は以下の通りです。

• ネットワーク ポリシー サーバー(NPS) 
• ルーティングとリモート アクセス サービス(RRAS)
• Radius サーバー
• EAP/PEAP
• スマートカード ログオン 

上記のサービスやシステムを利用している環境で、証明書を利用した認証を行っている場合、今回の脆弱性のセキュリティ強化の対処により認証に失敗するような影響がでる可能性が考えられます。

〇参考情報
タイトル：KB5014754—Certificate-based authentication changes on Windows domain controllers
URL:https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16

セキュリティ強化後の認証プロセス

この脆弱性の対処として、証明書を利用した Kerberos 認証のプロセスにおいてセキュリティ強化が行われます。

具体的には、ドメイン コントローラーにて証明書を利用した Kerberos 認証要求を受け取ったとき、認証の検証において、認証の対象となるアカウントと証明書が紐づけ(マッピング)されているかどうかを確認するプロセスが追加されます。もし、アカウントと証明書の紐づけがない場合は、ドメイン コントローラーでは認証は失敗する動作になります。

アカウントと証明書の紐づけされているかどうかの確認は、以下のマッピング情報の有無を確認します。

1. アカウントに証明書のマッピング情報があるか
2. 証明書にアカウントのマッピング情報があるか

① もしくは ② のいずれかの要件を満たしていれば、アカウントと証明書が紐づけされていると判断され、認証に成功します。① と ② の具体的な確認項目について説明します。

① アカウントに証明書のマッピング情報があるか

ユーザーやコンピューターなどの AD アカウントに、証明書のマッピング情報があるか確認します。

具体的には、認証の対象となる AD アカウントの altSecurityIdentities 属性の値を確認して、証明書の情報が登録されているかを確認します。AD アカウントの altSecurityIdentities 属性には、代替のセキュリティ識別子が登録されています。ドメイン コントローラーは認証要求を受け取ったら、認証の対象となる AD アカウントの altSecurityIdentities 属性値を確認し、認証要求時に提示された証明書の情報と一致するか確認します。

② 証明書にアカウントのマッピング情報があるか

証明書の拡張機能の項目に、ユーザーやコンピューターなどの AD アカウントのマッピング情報があるか確認します。

具体的には、認証要求において提示された証明書の拡張機能の項目である、”1.3.6.1.4.1.311.25.2” という OID の項目名を確認します。”1.3.6.1.4.1.311.25.2″ には、証明書に紐づくユーザーもしくはコンピューターの SID が含まれています。ドメイン コントローラーは認証要求を受け取ったら、提示された証明書の “1.3.6.1.4.1.311.25.2” の項目を確認し、記載されている SID の情報が、認証の対象となる AD アカウントの SID と一致するか確認します。

アカウントと証明書のマッピング

この脆弱性の対処として、ドメイン コントローラーでは証明書を利用した Kerberos 認証において、アカウントと証明書のマッピングを確認するようになります。マッピング情報の確認として、①アカウントに証明書のマッピング情報があるか、②証明書にアカウントのマッピング情報があるかを確認して、いずれかでマッピング情報が確認できれば、セキュリティ強化が行われた後も Kerberos 認証に成功します。

そのため、脆弱性の対処に必要な作業として、アカウントと証明書のマッピング情報を登録する必要があります。以下のいずれかの方法で、アカウントと証明書のマッピング情報を登録します。

(1) アカウントに証明書をマッピング

ユーザー アカウントもしくはコンピューター アカウントに、そのアカウントが利用する証明書をマッピングします。具体的には、アカウントの altSecurityIdentities 属性に証明書に関する情報を登録します。

altSecurityIdentities 属性に登録する、証明書のマッピング情報の記述形式には複数の種類が用意されています。いずれの種類の記述形式で、証明書の情報を登録しても問題はありませんが、種類ごとにセキュリティの強度が異なっております。

セキュリティ強化が行われた後に、ドメイン コントローラーにて Kerberos 認証に成功するには、altSecurityIdentities 属性にセキュリティ強度が “強” となっている記述形式でマッピング情報が登録されている必要があります。マイクロソフトが推奨している記述の種類は “X509IssuerSerialNumber” となります。

X509IssuerSerialNumber のマッピング情報を登録するには、証明書の「発行者」と「シリアル番号」の情報が必要です。アカウントと証明書のマッピングの登録の手順は以下の通りです。

1. 証明書の情報の確認

ユーザー アカウントもしくはコンピューター アカウントと証明書をマッピングするために、マッピング情報の登録に必要な証明書の「発行者」と「シリアル番号」を確認します。アカウントが利用する証明書を開いて、[詳細] タブより「発行者」と「シリアル番号」を確認します。

上図の証明書の場合、「発行者」と「シリアル番号」は以下の通りとなります。

2. 発行者のデータを加工

X509IssuerSerialNumber の記述形式でマッピング情報に含める発行者のデータは、証明書に記載されているデータを逆順で並べ替えたデータである必要があります。発行者の名前をカンマ(,)で区切り、逆順に並べ替えを行います。例えば、発行者名が A,B,C,D の場合は、D,C,B,A というように逆順に並べ替えをします。

上図の例の「発行者」を並べ替えをすると以下のようになります。

3. シリアル番号のデータを加工

X509IssuerSerialNumber の記述形式でマッピング情報に含めるシリアル番号のデータは、証明書に記載されているデータをバイトスワップ(１バイトずつ区切って逆順に並べること)します。

上図の例の「シリアル番号」をバイトスワップすると以下のようになります。

4. アカウントの altSecurityIdentities 属性にマッピング情報を登録

X509IssuerSerialNumber の記述形式に従って、成形したデータを当てはめると以下の通りとなります。

(2) 証明書にアカウントをマッピング

証明書にユーザー アカウントやコンピューター アカウントの情報をマッピングします。具体的には、証明書の “1.3.6.1.4.1.311.25.2” という項目に、AD アカウントの SID の情報を登録します。

証明書を発行するエンタープライズの証明機関に、2021 年 5 月以降のセキュリティ更新プログラム(KB5014754)を適用します。KB5014754 の更新プログラムは、発行する証明書に “1.3.6.1.4.1.311.25.2” という拡張項目を含めることができる機能を追加しております。

エンタープライズ CA は Active Directory と連携して動作するため、証明書の発行要求を行ったアカウントの情報も把握できます。そのため、証明書の発行要求がきたら、ドメイン コントローラーからアカウントの SID 情報を自動で入手して、”1.3.6.1.4.1.311.25.2” という拡張項目に含めた証明書を発行するという動作になります。

発行される証明書に “1.3.6.1.4.1.311.25.2” という拡張項目を含めるには、証明書の発行に利用する証明書テンプレートにて、[サブジェクト名] タブにて “Active Directory の情報から構築する” が有効になっている必要があります。この設定になっている証明書テンプレートを指定して証明書を発行すると、発行される証明書には、”1.3.6.1.4.1.311.25.2″ という OID の拡張機能に、証明書の発行要求を行ったアカウントの SID が追加されます。

エンタープライズ CA に KB5014754 を適用した後、”1.3.6.1.4.1.311.25.2″ という OID の拡張機能を含む証明書を再発行してください。

※ AD アカウントの SID の情報がマッピングされた証明書です。
“1.3.6.1.4.1.311.25.2” の拡張項目の値にアカウントの SID のデータが含まれております。

セキュリティ強化に関する段階的なスケジュール予定

2022 年 5 月では “互換モード” として脆弱性対処に必要な各対処を行うための展開フェーズ、2023 年 11 月(仮)に “強制モード” として脆弱性の対処を行うために、マッピングが確認できない Kerberos 認証を拒否する試行フェーズの 2 段階のスケジュールで対処が行われます。

互換モード(2022 年 5 月 10 日以降)

2022 年 5 月のセキュリティ更新プログラム(KB5014754)をドメイン コントローラーに適用すると、証明書を利用した Kerberos 認証の処理において、以下のような動作変更が行われています。2022 年 5 月のセキュリティ更新プログラムの段階では、”互換モード” の移行フェーズであるため、強制モードのフェーズに向けて必要な作業を進めるための期間となります。

ドメイン コントローラーは、証明書を利用した Kerberos 認証の要求を受け取ると、認証要求を行ったアカウントと提示された証明書のマッピング情報があるかどうかをチェックします。そのチェックの結果、アカウントと証明書のマッピングの情報の有無で、以下の通りの動作を行います。

アカウントと証明書のマッピング情報がある場合

「①アカウントに証明書のマッピング情報があるか」、「②証明書にアカウントのマッピング情報があるか」を確認した結果、アカウントと証明書のマッピングの情報がある場合は、問題なく Kerberos 認証は成功します。

アカウントと証明書のマッピング情報がない場合

「①アカウントに証明書のマッピング情報があるか」、「②証明書にアカウントのマッピング情報があるか」を確認した結果、アカウントと証明書のマッピング情報がない場合、強制モードに移行した後には Kerberos 認証に失敗する動作となってしまいます。

強制モードに向けて、アカウントと証明書のマッピングを行っていく必要がありますが、互換モードにおいては以下のような動作となります。

▶ アカウントが証明書より先に作成されていた場合

アカウントが証明書よりも先に作成されている場合は、互換モードでは Kerberos 認証に成功します。

ただし、マッピング情報がないため、2023 年 11 月以降、強制モードに移行すると Kerberos 認証は拒否されるようになります。そのため、マッピング情報がない、Kerberos 認証要求があったことを記録して、ドメイン管理者がアカウントと証明書のマッピングが進められるように、警告イベント ログを記録する動作となります。(記録される警告イベント ログの詳細は、”各イベント ログの詳細” にて紹介します)

「アカウントが証明書よりも先に作成されている」というのは、アカウントの whenCreated 属性にセットされている日時と、証明書の有効期間の開始日を比較して、アカウントと証明書のどちらが先に作成されたのかを判断しています。

アカウントの作成日 (whenCreated 属性)

証明書の作成日(有効期間の開始)

▶ 証明書がアカウントより先に作成されていた場合

証明書がアカウントより先に作成されている場合は、互換モードでも Kerberos 認証に失敗します。

このケースに該当して、証明書を利用した Kerberos 認証が失敗した場合の対処策としては、アカウントと証明書のマッピングの作業を実施してください。

また、問題の回避策として、脆弱性対策のためのセキュリティ強化(KB5014754 によるKerberos 認証における動作変更)を無効化することで、アカウントとマッピングされていない証明書を利用した Kerberos 認証に失敗する事象を回避することができます。KB5014754 によるセキュリティ強化による影響が大きい場合は、以下のレジストリを設定して、セキュリティ強化を無効化してください。

強制モード(2023 年 11 月 14 日以降)

2023 年 11 月のセキュリティ更新プログラムをドメイン コントローラーに適用すると、強制モードに移行します。強制モードに移行後は、証明書を利用した Kerberos 認証の処理において、アカウントと証明書のマッピングが確認できない場合は認証に失敗します。そのため、Kerberos 認証に成功するには、アカウントとマッピングの作業が必要です。

強制モードとなる 2023 年 11 月のセキュリティ更新プログラムの公開までに、マッピングの作業を完了させておいてください。

各イベント ログの詳細

2022 年 5 月以降のセキュリティ更新プログラムを適用すると、”互換モード” における移行作業を進めるために、新たなイベント ログが記録されるようになります。アカウントと紐づいていない証明書を利用して Kerberos 認証の要求を受け取ったことを記録するイベント ログです。

ドメイン コントローラーに2022 年 5 月以降のセキュリティ更新プログラムを適用した後に、以下に紹介するイベント ログが記録されている場合、強制フェーズに向けたマッピング作業が必要となります。各イベント ログの意味と対処策について詳細を紹介します。

イベント ID 40 (Windows Server 2008 R2 は ID 48)

イベント ID 40 (Windows Server 2008 R2 の場合はイベント ID 48)は、アカウントにマッピングされていない証明書で Kerberos 認証にした場合に記録されます。認証に使用された証明書は、ユーザー アカウントやコンピューター アカウントよりも先に作成されています。

このエラー イベント ログが記録された場合、互換モードと強制モードのどちらの場合でも、認証は失敗してブロックされます。

対処策について

イベント ID 40 が記録された場合の対処策は以下の通りです。

1. アカウントと証明書のマッピング作業を行う
2. 証明書を再発行して、アカウントよりも後に作成された証明書を展開(※補足)

※補足
証明書の再発行を行う場合は、OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書を発行することをご検討ください。OID 1.3.6.1.4.1.311.25.2 拡張がない証明書でも、互換モードにおいては認証可能とはなりますが、後述するイベント ID 39 (Windows Server 2008 R2 の場合は ID 41) の警告ログが記録されます。また、強制モードに移行した後には認証はブロックされます。

イベント ID 39 (Windows Server 2008 R2 は ID 41)

イベント ID 39 (Windows Server 2008 R2 の場合はイベント ID 41)は、アカウントにマッピングされていない証明書で Kerberos 認証にした場合に記録されます。イベント ID 40 との差分は、認証に使用された証明書は、ユーザー アカウントやコンピューター アカウントよりも後に作成されています。

このイベント ログは、互換モードの期間においては警告イベント ログを警告するのみで、実際の認証動作に影響はありません。しかしながら、強制モードになると、この認証はブロックする動作に変更されます。

対処策について

イベント ID 39 が記録された場合の対処策は以下の通りです。

1. アカウントの altSecurityIdentities 属性に証明書の情報を登録することで、手動でマッピングを行う
2. OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書を発行する (※補足)

※補足
証明書を発行する証明機関がサード パーティ製の証明機関である場合は、OID 1.3.6.1.4.1.311.25.2 拡張を付与する手順は別途ご確認ください。もし、OID 1.3.6.1.4.1.311.25.2 拡張を含めることができない場合は、ドメイン コントローラー上でアカウント の altSecurityIdentities 属性に証明書の情報を登録して、手動でマッピングする必要があります。

イベント ID 41 (Windows Server 2008 R2 は ID 49)

イベント ID 41 (Windows Server 2008 R2 の場合はイベント ID 49)は、Kerberos 認証に使用された証明書に OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書が使用されているものの、認証要求を行っているアカウントの SID と証明書の OID の拡張に記載されている SID が異なる場合に記録されます。

このエラー イベント ログが記録された場合、互換モードと強制モードのどちらの場合でも、認証は失敗してブロックされます。

対処策について

イベント ID 41 の対処策も、イベント ID 39 と同様に対処策は以下の通りです。

1. アカウントの altSecurityIdentities 属性に証明書の情報を登録することで、手動でマッピングを行う
2. OID 1.3.6.1.4.1.311.25.2 拡張が付与された証明書を発行する