介绍

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

概述

Kerberos的角色

1.提供认证服务和发送票据的KDC(Kerberos Distribution Center，密钥分发中心)，KDC作为domain controller，主要提供两种服务： Authentication Service (AS) 和 Ticket-Granting Service (TGS)，服务帐户为krbtgt（密码是系统随机生成的，无法正常登陆主机），一个域只有一个krbtgt账户

2.Client：客户端，例如打开文件、查询数据库或打印文档一些操作都会进行身份验证

3.Server：域内提供服务的服务端，服务端都有一个独一的SPN

大致流程

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

1.客户端与AS的交互(AS Exchange)

2.客户端与TGS的交互(TGS Exchange)

3.客户端与Server的交互 (CS Exchange)

AS认证

准备

用户在客户端中输入账号密码后，客户端会对密码进行hash code，就是NTML-Hash

请求

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

• Pre-authentication data：包含用以证明自己身份的信息，它的内容是一个被用户的NTML-Hash（或者用户的密码AES Key）加密过的Timestamp（时间戳）

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

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

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

响应

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

2.TimeStamp验证通过后，KDC便生成一个字符串（主要包含的内容是认证时间、认证到期时间、域名、请求的服务名）作为临时密钥用于下一阶段与TGS的通信，叫Login Session Key(登录会话密钥) ，AS将一份Authentication Service Response（KRB_AS_REP）发送给客户端，KRB_AS_REP主要包含两部分：

（1）一个由用户的NTML-Hash加密过的Logon Session Key
（2）一个TGT(client-server-ticket)。TGT又包含 Logon Session Key、TimeStamp(时间戳)、域名、PAC特权属性证书（以后会讲到、简单来说就是鉴定用户权限的）、用户信息、TGT到期时间，整体经过KDC中的krbtgt的密码HASH加密

3.客户端收到响应之后，通过自己的NTML-Hash解密第一部分获得Logon Session Key，然后携带着TGT进入下一步TGS认证

TGS认证

请求

客户端向KDC中的TGS发送Ticket Granting Service Request（KRB_TGS_REQ），其大体内容为

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

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

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

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

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

响应

1.TGS收到KRB_TGS_REQ后，先确认客户端提供的那个TGT是否是AS颁发给它的。于是它需要通过客户端提供的Authentication来证明。Authentication是通过Logon Session Key进行加密的，而自己并没有保存这个Logon Session Key。所以TGS先得通过自己的密码HASH对客户端提供的TGT进行解密，从而获得这个Logon Session Key和PAC（此时并不会鉴定用户权限，只会验证PAC有没有被篡改，无论客户端是否有权限访问，均会发放Ticket），再通过这个Logon Session Key解密Authenticator进行验证。

2.验证通过会生成一个Service Session Key(服务会话密钥、SS会话密钥)和Ticket，然后向对方发送Ticket Granting Service Response（KRB_TGS_REP）。这个KRB_TGS_REP有两部分组成：

（1）使用Logon Session Key加密过的Service Session Key。

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

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

• Client name & realm: 用户信息。

• End time: Ticket的到期时间。

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

通过Ticket访问服务器

请求

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

响应、双向认证

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

2.Kerberos一个重要的优势是它能够提供双向认证（这一步是可以选择的），是NTLM协议没有的，如果客户端需要对他访问的Server进行认证，会在它向Server发送的凭证中设置mutual-required协商选项为True。Server在对客户端认证成功之后，会把Authentication中的Timestamp提取出来，通过Service Session Key进行加密发给客户端，当客户端接收到并使用Service Session Key进行解密之后，如果确认Timestamp和原来的完全一致，那么他可以信任Server。

3.至此，客户端与服务器就完成了一次完整的握手过程，建立了TCP连接，在之后的访问过程中，客户端只要在请求数据包中携带加密的Ticket信息，即可无需再进行认证。

PAC

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

安全问题

域用户枚举

在Kerberos协议第一步AS认证中，通过发送AS-REQ，AS会校验用户名，用户名是否正确就有不同的响应，就可以根据AS-REP来判断问题：

PTH和PTK

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

金票

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

银票

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

MS14-068

MS14-068漏洞的原因是KDC无法正确检查PAC中的有效签名，由于其实现签名的加密运行所有的签名算法，只要客户端指定任意签名算法，KDC服务器就会使用指定的算法进行签名验证，因此可以利用不需要相关密钥的算法，如MD5，实现内容的任意更改，导致用户可以构造一张PAC，伪造用户的SID和所在的组。那么可以通过伪造PAC，加入域管相关信息，访问域控服务，KDC会认为当前用户有权限，从而把这个用户当作域管组的成员，进而达到提升为域管理员的效果。微软给出的补丁为KB3011780

委派

简单来说就是客户端会将从KDC处得到的TGT发送给访问的service1（可以是任意服务），service1拿到TGT之后可以通过TGT访问该用户有权限访问的服务，而我们可以将域用户通过注册SPN变为服务账户来进行利用，这种属于非约束性委派，微软为了解决这个问题设置了约束委派，利用起来相对复杂一点，以后再详解怎么利用。

4A评测 - 免责申明

本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。

不得将上述内容用于商业或者非法用途，否则一切后果请用户自负。

本站信息来自网络，版权争议与本站无关。您必须在下载后的24个小时之内，从您的电脑或手机中彻底删除上述内容。

如果您喜欢该程序，请支持正版，购买注册，得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解！

程序来源网络，不确保不包含木马病毒等危险内容，请在确保安全的情况下或使用虚拟机使用。

侵权违规投诉邮箱：4ablog168#gmail.com（#换成@）