概述

介绍

Kerberos是一种网络身份验证协议,在通过密钥加密技术为客户端/服务器应用程序提供身份验证,主要用在域环境下的身份验证，支持windows和linux，使用88端口进行认证，使用464端口进行密码重设

Kerberos的角色

1.提供认证服务的KDC(密钥分发中心)，KDC主要提供两种服务：AS认证和 TGS认证，服务账户为krbtgt（密码是系统随机生成的，无法正常登陆主机）

2.Client：客户端，例如打开文件、查询数据库或打印文档都会进行身份验证
3.Server：域内提供服务的服务端，服务端都有一个独一的SPN

大致流程

当 Client 想要访问 Server 上的某个服务时,需要先向 AS 证明自己的身份,验证通过后AS会发放一个TGT（用于购买ST服务票据）,随后Client再次向TGS证明自己的身份,验证通过后TGS会发放一个ST服务票据,最后Client向 Server 发起认证请求,这个过程分为三块：

1.Client 与 AS 的交互(AS Exchange)
2.Client 与 TGS 的交互(TGS Exchange)
3.Client 与 Server 的交互 (CS Exchange)

AS认证

Client 与 AS 的交互  

准备：用户在Client中输入账号密码后，Client会对密码进行hash code，就是NTML-Hash

请求

Client 先向KDC 的 AS 发送 Authentication Service Request认证信息（AS_REQ），为了确保AS_REQ仅限于自己和KDC知道，Client使用自己的NTML-Hash对其的主体部分进行加密。（KDC可以通过Domain 的Account Database获得该Client的NTML-Hash）其大体内容为：

  • Pre-authentication data：包含用以证明自己身份的信息。说白了，就是证明自己知道自己声称的那个account的Password。它的内容是一个被Client的NTML-Hash（或者用户的密码AES Key）加密过的Timestamp（时间戳）

  • Client name & realm: 简单地说就是用户信息

  • Server Name：注意这里的Server Name并不是Client真正要访问的Server的名称，TGT是和Server无关的（Client只能使用ST票据，而不是TGT去访问Server）。这里的Server Name实际上是KDC的Ticket Granting Service的Server Name

  • 还有一些版本号、消息类型、票据有效时间、是否包含PAC等等东西

响应

1.AS接收到AS_REQ后，会根据Client提交的用户名在AD数据库中寻找是否在白名单中，然后查询到该用户名的密码，并提取Client对应的NTML-Hash作为密钥对TimeStamp进行解密，如果是一个合法的Timestamp，就证明了Client提供的用户名和密码是存在AD中的，并且AS提取到的Timestamp不能超过5分钟，否则AS就会直接拒绝Client的请求。

2.TimeStamp验证通过后，KDC便生成一个字符串（主要包含的内容是认证时间、认证到期时间、域名、请求的服务名）作为临时密钥用于下一阶段与TGS的通信，叫Login Session Key(登录会话密钥) ，AS将一份Authentication Service Response（AS_REP）发送给Client，KRB_AS_REP主要包含两部分：一个由Client的NTML-Hash加密过的Logon Session Key和一个TGT(client-server-ticket)。TGT又包含 Logon Session Key、TimeStamp(时间戳)、域名、PAC特权属性证书（以后会讲到、简单来说就是鉴定用户权限的）、用户信息、TGT到期时间，整体经过KDC中的krbtgt的密码HASH加密
Client收到响应之后，通过自己的NTML-Hash解密第一部分获得Logon Session Key，然后携带着TGT进入下一步TGS认证

TGS认证

大体为Client 和票据生成服务器（TGS）通信验证去访问目标站点的权限，如果有返回一个ticket（st服务票据）给Client

请求

Client向KDC中的TGS发送Ticket Granting Service Request（TGS_REQ），其大体内容为：

  • TGT：Client通过AS认证获得的Ticket Granting Ticket，TGT是被KDC的密码hash进行加密。

  • Authentication：用以证明当初TGT的拥有者是否就是自己，使用Login Session Key加密的时间戳。

  • Client name & realm: 简单地说就是用户信息。

  • Server name & realm: 简单地说就是服务信息，这回是Client想要访问的那个Server信息。

  • 还有一些版本号、消息类型、票据有效时间等等东西

响应

1.TGS收到TGS_REQ后，先确认Client提供的那个TGT是否是AS颁发给它的。于是它不得不通过Client提供的Authentication来证明。Authentication是通过Logon Session Key进行加密的，而自己并没有保存这个Logon Session Key。所以TGS先得通过自己的密码HASH对Client提供的TGT进行解密，从而获得这个Logon Session Key和PAC（此时并不会鉴定用户权限，只会验证PAC有没有被篡改，无论客户端是否有权限访问，均会发放Ticket），再通过这个Logon Session Key解密Authentication进行验证。
2.验证通过会先生成一个Service Session Key(服务会话密钥、SS会话密钥)和Ticket，然后向对方发送Ticket Granting Service Response（TGS_REP）。这个TGS_REP有两部分组成：

（1）使用Logon Session Key加密过的Service Session Key。
（2）使用服务器密码的Hash进行加密的Ticket（只有域控制器和服务器能够进行解密）。该Ticket又包含以下一些内容：

  • Service Session Key：服务会话密钥、SS会话密钥。

  • Client name & realm: 用户信息。

  • End time: Ticket的到期时间。

Client收到TGS_REP，使用Logon Session Key解密第一部分后获得Service Session Key。有了Service Session Key和Ticket，Client就可以和Server之间进行交互，而无须再通过KDC做中间人了。

通过Ticket访问服务器

请求
客户端向服务器发送Ticket和用Service Session Key加密的Authentication信息

响应、双向认证

服务器收到消息之后，会用自己的密码Hash对Ticket进行解密，获取到Ticket中的Service Session Key，然后使用Service Session Key对Authentication进行解密，如果解密成功，则认证了用户身份（此时服务端从Ticket中取出PAC中代表用户身份权限信息的数据，然后与请求的服务ACL做对比，生成相应的访问令牌）。否则拒绝。

Kerberos一个重要的优势是它能够提供双向认证（这一步是可以选择的），是NTLM协议没有的
如果Client需要对他访问的Server进行认证，会在它向Server发送的凭证中设置mutual-required协商选项为True。Server在对Client认证成功之后，会把Authentication中的Timestamp提取出来，通过Service Session Key进行加密发给Client，当Client接收到并使用Service Session Key进行解密之后，如果确认Timestamp和原来的完全一致，那么他可以信任Server。
至此，客户端与服务器就完成了一次完整的握手过程，建立了TCP连接，在之后的访问过程中，客户端只要在请求数据包中携带加密的Ticket信息，即可无需再进行认证。

PAC
在Kerberos最初只是说明了如何证明客户端的真实身份，但是并没有鉴定客户端的权限，在域中不同权限的用户能够访问的资源是不同的。为了解决权限这个问题，就引入了 PAC (Privilege Attribute Certificate，特权属性证书) 的概念，KDC在收到客户端发来的AS-REQ请求后，从请求中取出cname字段，然后查询活动目录数据库，找到sAMAccountName属性为cname字段的值的用户，用该用户的身份生成一个对应的PAC。

安全问题

域用户枚举

在Kerberos协议第一步AS认证中，发送AS-REQ请求中包含用户的姓名，不同的情况会返回不同的AS-REP

响应类型

结果

AS-REP响应

账号存在且开启了"不要求Kerberos预身份验证"选项

KRB-ERROR: PREAUTH-REQUIRED

账号存在未开启"不要求 Kerberos 预身份验证"

KRB-ERROR: CLIENT-REVOKED

账号存在但是处于锁定状态

KRB-ERROR: UNKNOWN-PRINCIPLE

账号不存在

PTH和PTK

在AS认证第一步AS-REQ请求阶段，是用用户的NTLM Hash或AES Key加密的时间戳。因此当只获得了用户NTLM Hash时，也可以发起AS-REQ请求，所以也就造成了PTH哈希传递攻击；当只获得用户密码的AES Key时，也可以发起AS-REQ请求，所以也就造成了PTK密钥传递攻击。

AS-REP Roasting攻击

 在AS-REP阶段，Login session key是用用户密码 Hash 加密的。对于域用户，如果设置了“Do not require Kerberos preauthentication”不需要预认证选项，此时攻击者向域控制器的 88 端口发送 AS_REQ 请求，此时域控不会做任何验证就将 TGT认购权证 和 该用户Hash加密的Login Session Key返回。因此，攻击者就可以对获取到的用户Hash加密的Login Session Key进行离线破解，如果破解成功，就能得到该用户的密码明文，这种攻击方式被称为 AS-REP Roasting攻击。

金票

在认证过程中，经过Client与AS的通信会得到TGT，带着TGT向TGS请求，得到票据ticket，用这个ticket可以来访问应用服务器。而这个黄金票据就是自己生成的TGT，在生成TGT的过程中，user、domain、timestamp、还有权限等信息会经过krbtgt（该账号不自动更新）账户hash的加密，所以获取到用户、域、SID、krbtgt的hash值就可以生成黄金票据（一般拿到krbtgt需要域管权限，生成的票据当然也是域管账号的，这样就控了整个域，而且有了金票据，免除了as验证username、password的阶段，所以也不担心域管密码修改）。

银票

第二阶段的认证过程中，最后客户端拿到了Service Session Key以及加密的Ticket，这个Ticket使用服务器密码的Hash进行加密，那么如果拥有服务器密码的Hash，就可以伪造一个加密的Server Ticket，利用这个伪造的Ticket，参与第三阶段的认证过程。在这个阶段被伪造的Server Ticket被称为白银票据（Silver Ticket）。

免责声明

本文仅用于技术讨论与学习，利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，本平台和发布者不为此承担任何责任。