寸_铁

这个屌丝很懒，什么也没留下！

热门标签

详细讲解kerberos认证全过程、黄金、白银票据_kerberos认证过程

作者：寸_铁 | 2024-08-19 22:49:27

踩

kerberos认证过程

Kerberos认证在域渗透的作用不容小觑，刚开始学的时候觉得挺复杂、挺难记的，仔细学了一段时间，自己梳理了整个流程之后对Kerberos认证具有更多的、更深入的认识，以下是我对与Kerberos认证的理解，内容包含了我在学习过程中的一些困惑，希望有助于各位对于Kerberos认证流程、黄金票据、白银票据的学习与记忆。

参与Kerberos认证的有三个角色：客户端（client简写c）、服务端（server简写s）、DC（域控），而DC中有一个叫密钥分发中心的组件即KDC，它负责处理用户身份验证和授权请求。KDC包含两个主要子组件：认证服务（AS）和票证授予服务（TGS）。以下是我画的Kerberos认证整个流程图，不好看大家见谅！！

第一步：客户端向DC的AS请求

此时客户端本机的Kerberos服务会向KDC的AS认证服务发送AS-REQ认证请求，请求内容包括了客户端的个人信息即principal如用户名，以及说明要请求什么服务、目标服务的主机名等信息，也告诉AS自己将与TGS通信。除此之外为了防止别人伪造这个客户端的身份，还要求发送一个认证因子authenticator，这个认证因子需要使用客户端的hash来加密一个时间戳。

为什么需要用自己的hash加密时间戳？

因为如果不用客户端的hash进行加密，那么攻击者可以伪造任意客户端的身份进行Kerberos认证，但是加上客户端hash进行加密，DC再进行解密，这使得攻击者的攻击加大难度，只有获取了用户的hash才能伪造客户端的身份。另外DC是域控，肯定是有客户端的hash的。

时间戳的作用是什么？

是为了一定程度上防止攻击者进行重放攻击。请求接收方会对这个时间戳做一个验证，在请求发送到请求接收的一定时间内，假设为5分钟，在这5分钟内接收方收到了请求，那么就相信其为安全的请求，反之如果超过了5分钟则怀疑受到了重放攻击。

第二步：DC的AS向客户端的请求做出响应

此时AS收到了客户端的请求之后，由于AS是在DC上面的，DC是有客户端的hash的，此时会查询AD目录找到该客户端的hash，然后对时间戳进行解密，如果解密失败说明用于加密的hash是错误的，同时验证是否为受到了重放攻击。

在AS验证通过之后，AS会生成一个login session key，并且使用用户的hash加密这个login session key，然后AS还会生成一个TGT，同使用过hash加密后的login session key以及一些其他相关信息打包发送给客户端。

什么是TGT？

是Kerberos认证中的一种加密票据，是由Kerberos认证服务器（AS）生成并加密的，该TGT包含了用户的身份信息、有效期限、密钥（login session key）和其他相关信息，不过这些信息是使用的krbtgt的hash进行加密的，不在是用户的hash了。

什么是krbtgt？

krbtgt是Kerberos中的一个特殊账户，用于存储和管理Ticket Granting Ticket（TGT）。在Kerberos认证系统中，krbtgt账户是一个系统级别的账户，用于生成TGT和使用自己的hash（krbtgt hash）加密TGT，并提供给用户进行身份验证和获取服务票据。那么如果攻击者获取到了这个hash（krbtgt hash），那么就可以任意的伪造TGT了，也就是黄金票据，拥有了黄金票据就可以跳过AS验证了。

为什么TGT要用krbtgt的hash加密？

因为在攻击者未获取krbtgt的hash时，使用krbtgt的哈希加密可以防止TGT在传输过程中被篡改或伪造。如果使用明文，还可能被中间人窃取数据包，获取一些敏感信息。

第三步：客户端向DC的TGS请求

此时客户端收到了DC的的响应包之后会将收到的TGT存储在本地，并使用自己的hash将对应使用自己的hash加密的信息进行解密，获取到AS生成的login session key，然后客户端使用login session key去加密时间戳然后与收到的TGT、需要的服务名字、自己的相关信息一同打包发送到DC的TGS。

为什么客户端收到TGT之后还要发送回去？

客户端发送TGT是发送给TGS的，在AS发送给客户端TGT之后，客户端需要将其发给TGS之后，TGS才会给客户端授予服务票据。

为什么客户端收到TGT之后要存储起来？

因为TGT是具有时效性的，不是永久的，也不是一次性的。只要在TGT过期之前，可以直接请求TGS申请服务票据，而不用在每次访问服务的时候都向AS请求TGT，减少了与AS的通信，提高了系统的性能和效率。

第四步：DC的TGS向客户端的请求做出响应

当TGS接收到请求之后，会检查自身是否存在客户端请求的服务，如果存在就会拿ktbtgt hash解密TGT（由于TGS是在DC上的，所有具有krbtgt的hash），解密到的信息中包含了login session key，别忘了客户端发过来的时间戳就是利用login session key加密的，此时就可以用其解密获取到时间戳了，然后验证时间戳。

然后KDC会生成一个新的名叫service session key，用于客户端和服务端直接的安全通信，并且为客户端生成ST服务票据，该票据是由客户端信息+service session key打包后用后用服务端的hash加密的（KDC在DC上，故DC拥有服务端的hash）。除此之外会将service session key用之前是login session key加密同ST一同打包发送给客户端。

为什么service session key要用login session key加密？

因为是service session key是要发给客户端的，客户端拥有login session key，可以解密后获取到service session key，也保证了service session key的安全性。

为什么要生成一个service session key？

这个是为了用于接下来的客户端与服务端的安全通信，作用类似于login session key。

为什么要用服务端的hash加密service session key？

因为为了保证service session key不被窃取不可明文传输且后期客户端和服务端要使用service session key进行安全通信，而服务端没有login session key，DC就使用服务端的hash进行加密，同时还可以防止非目标服务器窃取这个service session key，因为只有知道服务端的hash才能获取service session key，进一步保证了service session key的安全。如果攻击者窃取了服务端的hash那么就可以任意伪造ST也就是白银票据了，就可以不经过KDC了。

第五步：客户端向服务端请求

此时客户端接收到了TGS的响应，然后利用login session key解密获取到service session key，然后用于与服务端通信，同时将ST存储起来，然后客户端用service session key加密客户端信息和时间戳同ST（服务端hash加密的相关信息+service session key）打包一起发送给服务端验证。

第六步：服务端向DC的KDC的请求

客户端收到服务端发送过来的信息之后，用自己的hash即服务端hash解密ST，而ST中包括有service session key，那么再用service session key去解密使用service session key加密的信息包括有客户端相关信息和时间戳，再去验证这个时间戳，判断是否安全，判断是否为真实身份。

除此之外服务端还要向DC请求，使用PAC（Privilege Attribute Certificate）将客户端的属性信息发送给KDC进行验证客户端是否安全是否具有获取该服务的资格。

什么是PAC？

PAC是一个包含了客户端属性信息的数据结构，它包括了客户端的授权信息、组成员资格和其他相关属性。服务端在收到客户端的票据后，会从票据中提取出PAC，并将其发送给KDC进行验证。

验证过程是什么？

1.服务端从客户端的票据中提取出PAC。

2.服务端将PAC发送给KDC，请求对客户端的属性信息进行验证。

3.KDC收到PAC后，会验证其中的属性信息是否与KDC中存储的客户端属性信息一致。

4.如果属性信息一致，KDC将返回一个验证成功的响应给服务端。

5.服务端根据KDC的响应，判断客户端的属性信息是否有效，并根据需要进行授权或其他操作。

第七步：DC的KDC向服务端响应

此时KDC将会对服务端发来的PAC进行一个验证，验证流程如下

1.KDC首先会检查PAC中的票据（Ticket）是否有效，即检查票据的签名是否正确、是否过期等。这是基本的票据验证过程，确保票据本身是合法的。

2.KDC会从PAC中提取出客户端的属性信息，如授权信息、组成员资格等。

3.KDC会与自身存储的客户端属性信息进行比对，以验证PAC中的属性信息是否与KDC中存储的信息一致。这样可以确保客户端的属性信息没有被篡改或伪造。

4.如果PAC中的属性信息与KDC中存储的信息一致，KDC将认为PAC是有效的，并返回一个验证成功的响应给服务端。反之如果PAC中的属性信息与KDC中存储的信息不一致，KDC将认为PAC是无效的，并返回一个验证失败的响应给服务端。

第八步：服务端向客户端响应

此时服务端会生成一个票据，该票据包括客户端身份信息，以及服务端的身份信息，并使用之前获得的service session key去加密该票据信息并发送给客户端，然后客户端就可以正常获取到服务端的服务了。

为什么要使用service session key去加密该票据信息？

因为之前KDS已经给客户端发送过了service session key，而service session key就是用来二者安全通信的，故客户端可以使用service session key去解密获取到票据信息。service session key加密同时也保障了票据信息不被窃取和修改伪造。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/寸_铁/article/detail/1004024