hacktricks/windows-hardening/active-directory-methodology/kerberos-authentication.md
2023-07-07 23:42:27 +00:00

16 KiB
Raw Blame History

Kerberos認証

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

この情報は、次の投稿から抽出されました: https://www.tarlogic.com/en/blog/how-kerberos-works/

KerberosIKerberosはどのように機能するのか - 理論

20 - MAR - 2019 - ELOY PÉREZ

この一連の投稿の目的は、攻撃を紹介するだけでなく、Kerberosがどのように機能するのかを明確にすることです。これは、多くの場合、いくつかのテクニックがなぜ機能するのか、しないのかが明確ではないためです。この知識を持つことで、ペンテストでこれらの攻撃のいずれかを使用するタイミングを知ることができます。

したがって、ドキュメントにダイビングし、トピックに関するいくつかの投稿を読んだ後、Kerberosプロトコルを利用するための重要な詳細をこの投稿にまとめました。

この最初の投稿では、基本的な機能のみが議論されます。後の投稿では、攻撃の実行方法やより複雑な側面(委任など)の動作方法について説明します。

説明が不十分なトピックについて疑問がある場合は、コメントや質問を残すことを恐れないでください。それでは、トピックに移りましょう。

Kerberosとは

まず、Kerberosは認証プロトコルであり、認可ではありません。つまり、ユーザーを識別するために秘密のパスワードを提供することができますが、このユーザーがどのリソースやサービスにアクセスできるかを検証しません。

KerberosはActive Directoryで使用されます。このプラットフォームでは、Kerberosは各ユーザーの特権に関する情報を提供しますが、各サービスはユーザーがリソースにアクセスできるかどうかを判断する責任があります。

Kerberosの要素

このセクションでは、Kerberos環境のいくつかのコンポーネントについて説明します。

トランスポート層

Kerberosは、データをクリアテキストで送信するUDPまたはTCPをトランスポートプロトコルとして使用します。そのため、Kerberosは暗号化を提供します。

Kerberosが使用するポートはUDP/88およびTCP/88であり、これらはKDC次のセクションで説明しますでリッスンする必要があります。

エージェント

Kerberosでは、認証を提供するためにいくつかのエージェントが連携して動作します。これらは次のとおりです。

  • サービスにアクセスしたいクライアントまたはユーザー
  • ユーザーが必要とするサービスを提供するAP(アプリケーションサーバー)。
  • Kerberosの主要なサービスであるKDCキー配布センター。チケットを発行する責任があり、DCドメインコントローラーにインストールされています。AS認証サービスによってサポートされており、TGTを発行します。

暗号化キー

Kerberosでは、チケットなどのいくつかの構造が処理されます。これらの構造の多くは、第三者による改ざんを防ぐために暗号化または署名されています。これらのキーは次のとおりです。

  • KDCまたはkrbtgtキーは、krbtgtアカウントのNTLMハッシュから派生します。
  • ユーザーキーは、ユーザーのNTLMハッシュから派生します。
  • サービスキーは、サービス所有者のNTLMハッシュから派生します。サービス所有者はユーザーアカウントまたはコンピューターアカウントである場合があります。
  • セッションキーは、ユーザーとKDCの間で交渉されます。
  • サービスセッションキーは、ユーザーとサービスの間で使用されます。

チケット

Kerberosが処理する主要な構造はチケットです。これらのチケットは、ユーザーに配布され、Kerberosレルムで複数のアクションを実行するために使用されます。2つのタイプがあります。

  • TGS(チケットグラントサービス)は、ユーザーがサービスに対して認証するために使用できるチケットです。サービスキーで暗号化されています。
  • TGTチケットグラントチケットは、TGSを要求するためにKDCに提示されるチケットです。KDCキーで暗号化されています。

PAC

PAC特権属性証明書は、ほとんどのチケットに含まれる構造です。この構造にはユーザーの特権が含まれており、KDCキーで署名されています。

サービスは、KDCと通信してPACを検証することができますが、これはあまり頻繁には行われません。ただし、PACの検証は、PAC内の特権が正しいかどうかを検査せずに、その署名のみをチェックすることで行われます。

認証プロセス

このセクションでは、認証を実行するためのメッセージのシーケンスが、チケットを持たないユーザーから目的のサービスに対して認証されるまでの手順について調査されます。

KRB_AS_REQ

まず、ユーザーはKDCからTGTを取得する必要があります。これを実現するために、KRB_AS_REQを送信する必要があります。

KRB_AS_REQスキーマメッセージ

_KRB_AS_REQ_には、以下のフィールドが含まれます。

  • ユーザーを認証し、リプレイ攻撃を防ぐために、クライアントキーで暗号化されたタイムスタンプ
  • 認証されたユーザーのユーザー名
  • krbtgtアカウントに関連付けられたサービスSPN
  • ユーザーが生成したNonce

注意:ユーザーアカウントでDONT_REQ_PREAUTHフラグが設定されていない限り、暗号化されたタイムスタンプはユーザーが事前認証を要求する場合にのみ必要です。

KRB_AS_REP

リクエストを受け取った後、KDCはタイムスタンプを復号化してユーザーの身元を検証します。メッセージが正しい場合、KDCは_KRB_AS_REP_で応答する必要があります。

KRB_AS_REPスキーマメッセージ

_KRB_AS_REP_には、次の情報が含まれます。

  • ユーザー名
  • TGTは以下を含みます
  • ユーザー名
  • セッションキー
  • TGTの有効期限
  • KDCによって署名されたユーザーの特権を持つPAC
  • ユーザーキーで暗号化されたいくつかのデータが含まれています:
  • セッションキー
  • TGTの有効期限
  • ユーザーのリプレイ攻撃を防ぐためのNonce

これでユーザーはTGTを持っており、TGSを要求し、その後サービスにアクセスすることができます。

KRB_TGS_REQ

TGSを要求するためには、KDCに_KRB_TGS_REQ_メッセージを送信する必要があります。

KRB_TGS_REQスキーマメッセージ

_KRB_TGS_REQ_には、以下が含まれます。

  • セッションキーで暗号化されたデータ
  • ユーザー名
  • タイムスタンプ
  • TGT
  • 要求されたサービスのSPN
  • ユーザーが生成したNonce

KRB_TGS_REP

_KRB_TGS_REQ_メッセージを受け取った後、KDCは_KRB_TGS_REP_内のTGSを返します。

KRB_TGS_REPスキーマメッセージ

_KRB_TGS_REP_には、以下が含まれます。

  • ユーザー名
  • TGSには以下が含まれます
  • サービスセッションキー
  • ユーザー名
  • TGSの有効期限
  • KDCによって署名されたユーザーの特権を持つPAC
  • セッションキーで暗号化されたデータ
  • サービスセッションキー
  • TGSの有効期限
  • ユーザーのリプレイ攻撃を防ぐためのNonce

KRB_AP_REQ

最後に、すべてがうまくいった場合、ユーザーは既に有効なTGSを使用してサービスとやり取りすることができます。それを使用するために、ユーザーはAPに_KRB_AP_REQ_メッセージを送信する必要があります。

KRB_AP_REQスキーマメッセージ

_KRB_AP_REQ_には、以下が含まれます。

  • TGS
  • サービスセッションキーで暗号化されたデータ
  • ユーザー名
  • リプレイ攻撃を防ぐためのタイムスタンプ

その後、ユーザーの特権が正しい場合、ユーザーはサービスにアクセスできます。通常は起こりませんが、APはKDCに対してPACを検証する必要があり、相互認証が必要な場合は_KRB_AP_REP_メッセージでユーザーに応答します。

参考文献

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥