kerberos

0x00 简介

Kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos作为一种可信任的第三方(KDC)认证服务，是通过传统的密码技术(对称加密)执行认证服务的。

在Kerberos协议中主要是有三个角色的存在：

1. 访问服务的Client
2. 提供服务的Server
3. KDC（Key Distribution Center）密钥分发中心

0x01 基础概念

• DC（Domain Controller) : 域控制器
• KDC (Key Distribution Center) : 密钥分发中心，负责管理票据、认证票据、分发票据。包含两个服务：AS 和TGS
• AS (Authentication Server) : 身份认证服务
• TGS (Ticket Granting Server) : 票据授予服务,该服务提供的票据也称为 TGS 或者叫白银票据
• AD (Account Database) : 账户数据库，存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT。
• TGT (Ticket Granting Ticket) : 由身份认证服务授予的票据(比如黄金票据)，用于身份认证，默认有效期为10小时（临时凭证）
• Tickket : 票据，是访问网络对象的凭证
• krbtgt账户：每个域控制器都有一个 krbtgt 的用户账户，是 KDC的服务账户，用来创建票据授予服务(TGS)加密的密钥

0x02 认证过程粗略介绍

1. client向kerberos服务请求，希望获取访问server的权限。 kerberos得到了这个消息，首先得判断client是否是可信赖的， AS通过在AD中存储黑名单和白名单来区分client。认证成功后，AS返回TGT给client。
2. client得到了TGT后，继续向kerberos请求，希望获取访问server的权限。kerberos又得到了这个消息，这时候通过client消息中携带的TGT完成验证，然后给client发送访问server的权限ticket。
3. client得到ticket后，终于可以成功访问server。这个ticket只是针对这个server，其他server需要重新向TGS申请。

Server 和 Service 也可以当作一个东西，就是Client想要访问的服务器或者服务

0x03 认证过程

1.用户登录

• 用户登录阶段，通常由用户输入[用户名]和[密码]信息
• 在客户端侧，用户输入的[密码]信息被通过一个单向Hash函数生成一个[Client密钥]

2.请求身份认证

2.1 客户端向AS发送认证请求(KRB_AS_REQ)

1. 客户端为执行登录操作的用户向AS发送认证请求。请求中带有[用户名]等信息，用户名以明文形式发送到服务端。
2. AS收到用户认证请求之后，根据请求中的[用户名]信息，从数据库中查找该用户名是否存在。
3. 如果[用户名]存在，则对应的[密码]也可以从数据库中获取到。AS利用相同的单向Hash函数为[密码]生成一个秘钥，如果第1步中用户提供的[密码]信息正确，该秘钥与用户登录章节中的[Client密钥]相同，就可以解开Client发送的经过加密的时间戳。

2.2 AS确认Client端登陆者用户身份(KRB_AS_REP)

1.AS为Client响应如下消息：

• Msg A 使用[Client密钥]加密的[Client/TGS SessionKey]
• Msg B 使用[TGS密钥]加密的TGT(Ticket-Granting-Ticket)，因此该消息Client不可解析。
  TGT中包含如下信息：
  • [Client/TGS SessionKey]
  • Client ID
  • TGT 有效时间
  • Client网络地址

2.Client 使用[Client密钥]解密Msg A获得[Client/TGS SessionKey]

3.由于Msg B是使用[TGS密钥]加密的，而Client没有没有[TGS密钥]，所以无法对其解密

Note
1. AS响应的消息中Msg A是属于Client的，但Msg B却属于TGS。
2. Client/TGS SessionKey出现了两个Copy，一个给Client端，一个给TGS端（在TGT中）。
3. TGS密钥 == KDC Hash == krbtgt用户的NTLM Hash，这几个可能有时候叫法不一样但是是一个东西。
4. Client/TGS SessionKey 是AS随机生成的。
5. Client ID是在AS分配生成的 。
6. 本文中提及的加密，如无特殊说明，均采用的是对称加密算法。

3.请求服务授权

3.1 客户端向TGS发送请求服务授权请求(KRB_TGS_REQ)

1.Client继续向TGS发送请求，请求中包含如下两个消息：

• Msg C
  • 要请求的服务ID, 即[Service ID]
  • 上一步2.2中由AS为Client提供的TGT
• Msg D
  • 使用[Client/TGS SessionKey]加密的Authenticator 1

2.TGS此时如果能使用自己的TGS密钥来成功解密TGT，获得TGT中的[Client/TGS SessionKey]，说明这个TGT
是可信任的，因为Client无法修改TGT。TGS同时会验证TGT是否过期

3.TGS服务使用[Client/TGS SessionKey]解密Msg D获得Authenticator 1 ，与解密TGT得到的身份信息进行比对，如果能成功解密并且比对成功，说明这个Client是可信任的

3.2 TGS为Client响应服务授权票据(KRB_TGS_REP)

1. 验证通过后，TGS为Client响应的消息包括：Msg E

• Msg E 使用[Service密钥]加密的Client-To-Server Ticket, 该Ticket中包含了如下信息:
  • [Client/Server SessionKey]
  • Client网络地址
  • Ticket有效时间
  • Client ID
• Msg F 使用[Client/TGS SessionKey]加密的[Client/Server SessionKey]。

1. 而Msg E使用了[Service密钥]加密，该消息可视作是TGS给Service Server的消息，只不过由Client一起携带。
2. Msg F使用了[Client/TGS SessionKey]加密，因此，该消息对Client可见。Client对其解密以后可获取到[Client/Server SessionKey]。

Note
1. TGS响应的消息中Msg F是属于Client的，但Msg E却属于Server。
2. Client/Server SessionKey出现了两个Copy，一个给Client端，一个给Server端（在Client-To-Server 
Ticket中）。

4. 发送服务请求

4.1 Client向SS(Service Server)发送服务请求(KRB_AP_REQ)

1. Client向Server发送的消息中包括：
   • Msg E 上一步3.2中，TGS为Client响应的消息Msg E。该消息可以理解为由Client为SS携带的消息。
   • Msg G 由[Client/Server SessionKey]加密的Authenticator 2，包含{Client ID, Timestamp}信息。
     这里的Authenticator 2区别于前面3.1步骤中的Authenticator 1。
2. Server收到客户端的服务请求之后，先利用自身的[Service密钥]对Msg E进行解密，提取出Client-To-ServerTicket, 在3.2步骤中，提到了该Ticket中包含了[Client/Server SessionKey]以及Client ID信息。
3. Server使用[Client/Server SessionKey]解密Msg G，提取Client ID信息，而后将该Client ID与Client-ToServer Ticket中的Client ID进行比对，如果匹配则说明Client拥有正确的[Client/Server SessionKey]。

4.2 SS响应Client(KRB_AP_REP)

1. SS向Client响应Msg H(包含使用[Client/Server SessionKey]加密的Timestamp信息)。
2. Client收到SS的响应消息Msg H之后，再使用[Client/Server SessionKey]对其解密，提取Timestamp信息，然后确认该信息与Client发送的Authenticator 2中的Timestamp信息一致。如上信息可以看出来，该交互过程起到了Client与SS之间的“双向认证”作用。

0x05 说明

1. Client 密钥 TGS密钥 和 Service 密钥 均为对应用户的NTLM Hash。

1. Client/(TGS/Server) Sessionkey 可以看作客户端与TGS服务和尝试登陆的Server之间会话时用来加密的密钥，而(Client/TGS/Service)密钥(上面提到的三个实际为NTLM Hash的密钥)是用来加密会话密钥的密钥，为了保证会话密钥的传输安全，这些加密方式均为对称加密。也就是说，参与认证的三个角色的NTLM Hash是三个密钥，这三个NTLM Hash的唯一作用是确保会话密钥Sessionkey的安全传输。
2. Service 和 TGS 通过对TGT 和 Ticket （TGT 和 Ticket中包含会话密钥Sessionkey和客户端的身份信息）使用自己的NTLM Hash进行解密获取到会话密钥，再使用这个会话密钥解密客户端通过这个会话密钥加密发来的验证信息。通过解密客户端发来的验证信息，可以得到客户端的身份验证信息，再与使用自己的NTLM Hash进行解密TGT或者Ticket得到的客户端身份信息进行比较来完成对客户端身份的验证。

0x06 相关安全问题

黄金票据：KDC返回的Msg B：使用 TGS密钥(KDCHASH/KRBTGT用户NTLMHASH) 加密的TGT(TicketGranting-Ticket)，当我们获取到krbtgt用户的NTLM哈希后，便可主动使用krbtgt用户的NTLM哈希做为TGS密钥来生成TGT发送给KDC，这样KDC如果通过解密伪造TGT获取到伪造的 [CLIENT/TGS SESSIONKEY] 可以成功解密Authenticator 1 并完成与TGT中的数据进行比对，便成功骗过了KDC，也就是成功伪造了黄金票据

白银票据：客户端向服务器发送的为使用 SERVICE密钥(服务器的NTLMHASH) 加密的 CLIENT-TO-SERVERTICKET Ticket中包含用来供服务器解密Authenticator 2的 CLIENT/SERVER SESSIONKEY 。如果获取到了ServiceServer的NTLM Hash，便可伪造Ticket，和Authenticator 2 ，Service Server在接收到Ticket和Authenticator 2后可以使用自己的NTLM Hash正常解密完成比对，也就是成功伪造了白银票据

除了上面介绍的两个安全问题，还有pass the key、用户名枚举、Password Spraying、AS-REPRoasting、pass the ticket、kerberosting等其他相关安全问题。