今更だが Active Directory の暗号アルゴリズムについて改めて整理したのでメモ
はじめに
Active Directory の暗号アルゴリズムは AES、RC4 などあり、AES256 が一番強度としては高いのは認識していたが、どこでその暗号アルゴリズムが使われているかなど、仕様面の理解が甘かったので、自分の調べたことをメモがてらまとめます。私の理解が誤っている可能性もあるので、間違いがあれば指摘のコメントいただけると助かります。
なお、本記事では Kerberos の基本的なプロトコルの説明は含みません。
暗号アルゴリズムが関連する点
AES256 を適用するのがセキュリティ的には望ましいという話はされるものの、具体的な適用される個所を分かっていなかったが、調べたところ、オンプレミスの Active Directory で管理者が意識するべき暗号アルゴリズムがかかわる場所は以下の箇所だと理解しました。
- Active Directory のデータベース(ntds.dit)や Windows PC のローカル SAM に保存されるクレデンシャル情報を安全に保存する為の暗号化
- Kerberos の AS 時の事前認証や KDC から返答されるセッション キーを安全に受け渡すための暗号化
- Kerberos の Service Ticket の暗号化
いずれの箇所も暗号強度の高い AES256 を暗号アルゴリズムとして利用するようにするのが当然望ましい。
各暗号プロトコルの詳細
1. Active Directory のデータベース(ntds.dit)や Windows PC のローカル SAM に保存されるクレデンシャル情報を安全に保存する為の暗号化
Active Directory で管理されるユーザーのパスワードは Active Directory のデータベース(ntds.dit)にハッシュ化されて保存されます。またドメイン メンバー サーバーや Windows クライアントのローカル ユーザー アカウントのパスワード ハッシュは、レジストリにあるローカルのセキュリティ アカウント マネージャー (SAM) データベースに格納されます。この Active Directory のデータベース(ntds.dit) やローカルの SAM データベースに保存されるパスワード ハッシュは暗号化され保存されますが、その際の暗号アルゴリズムが OS バージョンによって異なります。以下の公開情報に記載の通り Windows Server 2016/Windows 10 以降のバージョンでは、最初に DES を使用して暗号化し、次に CNG BCrypt AES-256 で暗号化します。それ以前の Windows バージョンでは、DES と RC4 の 2 つの暗号化レイヤーで暗号化されます。この暗号プロトコルは Windows のバージョンにより決定しますので最新の OS を利用していれば最新の AES-256 の利用の設定を意識する必要は基本的にありません。
関連 AES に用いられるパスワードから派生する Hash 情報
RC4 暗号化の際の鍵は NT Hash を利用されますが、AES の鍵は何なのか分かっていませんでしたが AD に格納されるパスワードは NT Hash 以外に、supplementalCredentials という項目があり、その中のプロパティ名 "Primary:Kerberos-Newer-Keys" の値の中に保存されている事が調べている中で分かりました。
2.Kerberos の AS 時の事前認証や KDC から返答されるセッション キーを安全に受け渡すための暗号化
Kerberos 認証では、まずクライアントから時刻をパスワードを元に暗号化した Authenticator(事前認証データ)を生成し、ドメイン コントローラーにリクエストを送付します。正しいパスワードで Authenticator が送付されている事をドメイン コントローラーは確認すると、TGT とセッションキーを返答します。その際にセッションキーは認証してきたアカウントのパスワードを元に暗号化しレスポンスを返します。
ここのやり取りでまず Authenticator の暗号化はクライアントの OS 構成に基づいて暗号アルゴリズムを決定します。こちらも基本的に最新の OS を利用していれば最新の AES-256 の利用の設定を意識する必要はないはずです。一方ドメイン コントローラーから返送されるセッション キーはクライアントからの KRB_AS_REQ 内で宣言されたサポートされる暗号アルゴリズムと AD 上のアカウントで設定されている、msDS-SupportedEncryptionTypes 属性で指定されている暗号アルゴリズムでクライアントとドメイン コントローラーがともにサポートできる暗号プロトコルを利用します。msDS-SupportedEncryptionTypes 属性が指定されていない場合は、AES がサポートされていなかったが、"CVE-2022-37966" の対応が完了しているドメイン コントローラーは AES256 がサポートされるようになります。
参考:https://jpwinsup.github.io/blog/2022/12/29/ActiveDirectory/Authentication/kerberos-protocol-changes-related-to-cve-2022-37966/
なお、TGT もチケット自体は暗号化されておりますが、認証するアカウントではなく、krbtgt のアカウントに紐づくパスワードで暗号化され、その際利用される暗号アルゴリズムは AD をドメイン機能レベル2003以前より利用しており、ドメイン機能レベルが2008以降になった後も一度も krbtgt のパスワード変更を実施していない場合を除き、最新の OS、機能レベルの環境であれば AES256 が利用されます。
3.Kerberos の Service Ticket の暗号化
Kerbros 認証ではリソースにアクセスする際はドメイン コントローラーに TGT を提示し、Service Ticket を要求します。このサービス チケットはアクセス先のコンピューター アカウントまたは、リソースをホストするために利用されるサービス アカウントのパスワードを元に暗号化されます。このサービスチケットの暗号化はそれらのコンピューターまたはサービス アカウントの msDS-SupportedEncryptionTypes 属性に基づいて暗号化されます。(AES が設定されている場合は暗号アルゴリズムは AES が選択される。) msDS-SupportedEncryptionTypes 属性が設定されていない場合は、2.と同様、標準では RC4 が選択され、"CVE-2022-37966" の対応が完了している場合は AES が選択されます。
Kerberoasting や AS-REP Roasting 攻撃への備え
Kerberos の暗号アルゴリズムを調べるきっかけは Kerberoasting や AS-REP Roasting 攻撃への対応を深く理解する為でした。AS-REP Roasting については Kerberos 事前認証を必須にすることで対策になりますが、 Kerberoasting への対応としては各サービス アカウントでの AES の有効化、強固なパスワードの設定が重要という事を理解できました。
Kerberoasting や AS-REP Roasting 攻撃の詳細な説明は本記事では割愛します。
参考:
参考
Kerberos の暗号化については以下のブログがとても勉強になりました。
Discussion