从0到1的熟悉掌握——Kerberos协议

Kerberos协议简述

Kerberos 是 MIT 提出的一种网络身份验证协议，它通过密钥加密技术验证用户或主机的身份。Kerberos 默认使用 UDP 端口88。

​ Kerberos，作为第三方网络认证协议，在客户端需要与服务端通信时，通过使用加密技术为客户端/服务端应用程序提供强大的认证服务。Kerberos协议在内网域渗透领域至关重要，白银票据、黄金票据、攻击域控等都离不开Kerberos协议。

​ Kerberos协议是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。其设计目标是通过密钥系统对客户端和服务器应用程序提供强大的认证服务。该协议的认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上的所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。

在Windows Domain（域）环境中：

DC（Domain Controller）域控充当KDC（Client和Server共同信任的第三方机构）

KDC维护存储着该Domin中所有账户的Account Database（由Active Directory维护），存储着所有每一个Account的名称和派生于该Account Password的Mater Key（Hash Code）

Kerberos词汇扩展

简称角色作用
Client客户端，指用户
Server服务端、服务器
DCDomain Controller域控制器，一台计算机，实现用户和计算机的统一管理
KDCKey Distribution Center密钥分发中心，默认按照在域控里，包括AS和TGS
ASAuthentication Service身份验证服务，用于KDC对Client认证
TGSTicket Granting Service票据授予服务，用于KDC对Client和Server分发Session Key（临时密钥）
ADActive Directory活动目录，用于存储用户、用户组、域相关的信息
TGTTicket Granting Ticket认证票据：相当于入场卷，用来获取ST的临时凭证
STService Ticket用来访问某种服务所必须使用的票据
PACPrivilege Attribute Certificates特权访问证书，是微软为了访问控制而引进的一个扩展

Kerbros认证整体流程

  1. AS_REQ & AS_REP

    -Client向KDC申请TGT（AS身份验证服务）

  2. TGS_REQ & TGS_REP

    -Client通过获得的TGT向KDC申请用于访问Server的Ticket（TGS票据发放服务）

  3. AP-REQ & AP-REP

    Client最终向Server提交Server为了验证自己身份的Ticket（通过认证的客户端和服务建立连接）

img

1、AS_REQ & AS_REP

​ 该阶段为Client和AS的认证，通过认证的客户端获得TGT认购权证。

​ 当域内某个客户端用户试图访问域内的某个服务，于是输入账户密码，此时客户端本机Kerberos服务就会向KDC的AS认证服务发送一个AS_REQ认证请求。

​ AS接收到客户端信息后，并不是立即接受而是先在AD数据库中查找是否存在该用户记录。如果存在，则用该用户的密码HASH并对AS_REQ请求中加密的时间戳进行解密，如果解密成功，则证明客户端提供的密码正确，如果时间戳在五分钟之内，则预认证成功。然后AS会生成一个临时密钥 Session-Key AS（用于确保客户端和KGS之间的通信安全），并使用客户端用户的NTLM-Hash加密临时密钥作为响应的一部分内容。

​ 还有一部分是TGT：使用KDC的一个特定账户的Hash对临时密钥、时间戳、Client-info进行的加密。这个特定的账户是创建域控时自动生成的Krbtgt用户，然后将这俩部分以及PAC等信息回复给Client。

image-20220420225034651

2、TGS_REQ & TGS_REP

​ 该阶段是Client和TGS的认证，通过认证的客户端将获得ST服务票据。

​ Client收到AS回复的AS_REP后获得TGT和加密的Session-Key AS。首先用自己的Hash解密得到原始的临时密钥，然后在本地缓存TGT和原始的临时密钥。当需要访问某服务时，就凭借这张TGT认购凭证向KGS购买相关的ST服务票据（Ticket）。

​ 此时 Client 会使用 Session-Key AS 加密时间戳、Client-info、Server-info 等数据作为一部分。由于 TGT 是用 Krbtgt 账户的 Hash 加密的，Client 无法解密，所以 Client 会将 TGT 作为另一部分继续发送给 TGS。两部分组成的请求被称为TGS_REQ。

​ TGS 收到该请求，用 Krbtgt 用户的 NTLM-hash 先解密 TGT 得到 Session-key AS、时间戳、Client-info 以及 Server-info。再用 Session-key AS 解密第一部分内容，得到 Client-info、时间戳。然后将两部分获取到时间戳进行比较，如果时间戳跟当前时间相差太久，就需要重新认证。TGS 还会将这个 Client 的信息与 TGT 中的 Client 信息进行比较，如果两个相等的话，还会继续判断 Client 有没有权限访问 Server，如果都没有问题，认证成功。认证成功后，KGS 会生成一个 Session-key TGS，并用 Session-key AS 加密 Session-key TGS 作为响应的一部分。此 Session-key TGS 用于确保客户端和服务器之间的通信安全。

​ 另一部分是使用服务器 Server 的 NTLM-Hash 加密 Session-key TGS、时间戳以及 Client-info 等数据生成的 ST。然后 TGS 将这两部分信息回复给 Client，即TGS_REP。

image-20220420225351786

3、AP-REQ & AP-REP

​ 这一阶段是Client和TGS的认证，通过认证的客户端和服务器建立连接。

​ 客户端Client收到TGS_REP之后，获得了ST和加密的Session-Key TGS。它首先使用本地缓存的Session-Key AS解密出原始的Session-Key TGS。然后在本地缓存此ST和原始Session-Key TGS，当客户端需要访问某服务时再向服务器发出请求。它将AP_REQ发送给Server。

​ AP_REQ包含俩部分：一、使用Session-Key TGS加密Client-info、时间戳等信息；二、ST（因为ST是使用Server的Hash进行加密的，无法解密）

​ Server在收到AP_REQ请求后，用自身的Hash解密ST，得到Session-Key TGS，再加密出Client-info、时间戳（有效时间一般为8小时）等数据，进行一一对比。通过客户端身份验证后，Server会拿着PAC去询问DC该用户是否有访问权限，DC拿到PAC后进行解密，通过PAC中的SID判断用户组信息，用户权限等，然后将结果返回Server，Server再将信息域用户请求的服务资源的ACL进行对比，通过认证即可给用户提供相应服务，Server将返回最终的AP-REP并与Client建立通信。

image-20220420223820666

Kerberos的缺陷

​ 虽然Kerberos的认证模式已经能满足大多数企业的安全需求了，但这样还是不够的。其中还存在很多威胁。AD域的攻击行为，很多都与Kerberos相关。

​ 在认证流程中，如果没有PAC的访问控制作用的话，任何一个经过身份验证的用户都可以访问任何服务。为了解决这个问题，微软引进了PAC。PAC包含的是用户的SID、用户所在组等一些信息。但是有些服务并没有验证PAC，这也是白银票据能成功的前提。

​ 从认证过程我们可以发现，Kerberos认证完全依赖于KDC的密钥（即krbtgt用户的密钥）。因此，如果攻击者拿到了krbtgt账号的hash的话，那么他就可以访问域中任何以kerberos协议做身份认证的服务。这就产生了票据传递攻击(Pass The Ticket)。