hacktricks/windows-hardening/active-directory-methodology/kerberos-authentication.md
2023-08-03 19:12:22 +00:00

14 KiB
Raw Blame History

Kerberos身份验证

☁️ HackTricks云 ☁️ -🐦 推特 🐦 - 🎙️ Twitch 🎙️ - 🎥 YouTube 🎥

此信息摘自文章:https://www.tarlogic.com/en/blog/how-kerberos-works/

KerberosIKerberos是如何工作的- 理论

2019年3月20日 - 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(应用程序服务器),提供用户所需的服务。
  • KDC密钥分发中心Kerberos的主要服务负责发行票证安装在DC域控制器上。它由AS认证服务支持AS发行TGT。

加密密钥

Kerberos处理多个结构如票证。这些结构中的许多是加密或签名的以防止被第三方篡改。这些密钥包括

  • KDC或krbtgt密钥派生自krbtgt帐户的NTLM哈希。
  • 用户密钥派生自用户的NTLM哈希。
  • 服务密钥派生自服务所有者的NTLM哈希可以是用户或计算机帐户。
  • 会话密钥在用户和KDC之间协商。
  • 服务会话密钥,在用户和服务之间使用。

票证

Kerberos处理的主要结构是票证。这些票证交付给用户以便用户在Kerberos领域中执行多个操作。有两种类型

  • TGS(票证授予服务)是用户可以用来对服务进行身份验证的票证。它使用服务密钥进行加密。
  • TGT票证授予票证是提交给KDC以请求TGS的票证。它使用KDC密钥进行加密。

PAC

PAC特权属性证书是几乎每个票证中包含的结构。此结构包含用户的特权并使用KDC密钥进行签名。

服务可以通过与KDC通信来验证PAC尽管这种情况并不经常发生。然而PAC验证仅包括检查其签名而不检查PAC内部的特权是否正确。

此外客户端可以通过在票证请求的_KERB-PA-PAC-REQUEST_字段中指定来避免将PAC包含在票证中。

消息

Kerberos使用不同类型的消息。最有趣的是以下几种

  • KRB_AS_REQ用于向KDC请求TGT。
  • KRB_AS_REP由KDC交付TGT使用。
  • KRB_TGS_REQ使用TGT向KDC请求TGS。
  • KRB_TGS_REP由KDC交付TGS使用。
  • KRB_AP_REQ使用TGS对用户进行身份验证。
  • KRB_AP_REP:(可选)由服务用于对用户进行身份验证。
  • KRB_ERROR:用于通信错误条件的消息。

此外即使它不是Kerberos的一部分但是NRPCAP还可以使用KERB_VERIFY_PAC_REQUEST消息向KDC发送PAC的签名并验证其是否正确。

下面是执行身份验证的消息序列的摘要

Kerberos消息摘要

认证过程

在本节中,将研究执行认证所需的消息序列,从没有票证的用户开始,直到对所需服务进行身份验证。

KRB_AS_REQ

首先用户必须从KDC获取TGT。为此必须发送一个KRB_AS_REQ

KRB_AS_REQ消息结构图

_KRB_AS_REQ_包含以下字段之一

  • 使用客户端密钥加密的时间戳,用于验证用户身份并防止重放攻击
  • 已验证用户的用户名
  • krbtgt帐户关联的服务SPN
  • 用户生成的Nonce

注意:只有在用户需要预身份验证时,才需要加密时间戳,这是常见情况,除非在用户帐户中设置了DONT_REQ_PREAUTH标志。

KRB_AS_REP

收到请求后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返回一个包含TGS的_KRB_TGS_REP_

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 🎥