kerberos协议介绍及分析

一.kerberos认证过程

 

 

二.服务作用

KDC(key distributed center)
作用:整个安全认证过程的票据生成管理服务,其中包含两个服务,AS和TGS

AS(authentication service)
作用:为client生成TGT的服务

TGS(ticket granting service)
作用:为client生成某个服务的ticket

AD(account database)
作用:存储所有client的白名单,只有存在于白名单的client才能顺利申请到TGT

TGT(ticket-granting ticket)
作用:用于获取ticket的票据

client
想访问某个server的客户端

server
提供某种业务的服务

 三.步骤详解

(AS-REQ)Client 发送用户名 Tom 到 KDC (Key Distribution Center)以向 AS (Authentication Service)请求 TGT 票据等信息。

(AS-REP)收到请求后,AS 生成随机字符串 Session Key,使用 Tom 的 NTLM Hash 对 Session Key 加密得到密文 A,再使用账号 krbtgt 的 NTLM Hash 对 Session Key 、 Client Info和 timestamp 加密得到 TGT,A 和 TGT 一起返回给 Client。

(TGS-REQ) Client 收到请求后,使用自身的 NTLM Hash 解密 A 就能得到 Session Key,然后使用 Session Key 对 Client Info 和 timestamp 加密得到 B,加上 TGT ,发送给 KDC中的 TGS。

(TGS-REP)TGS 收到请求后,使用 krbtgt 的 NTLM Hash 解密 TGT,得到 Session Key 和 timestamp 以及 Client Info,同时,使用 TGT 解密出的 Session Key 解密密文B,得到Client Info 和 timestamp。 比对这两部分解密得到的内容以验证是否通过。通过后,生成一个新的随机数 Server(Sever Session key),并用它加密 client info 和 timestamp 得到密文 enc-part;使用服务器计算机的NTLM Hash 对 Server(Sever Session key) 和 client info 以及 timestamp 加密得到最终的 Ticket,返回给 Client。

(AP-REQ)Client 使用 Ticket 和 enc-part 直接请求某服务。

(AP-REP) 对Ticket 和 enc-part 解密后进行验证授权。

三、详细分析

AS-REQ

开始先会进行kerberos预身份认证(为了防止爆破)kerberos v4 默认不会进行预认证。

 

第一部分:当中pvon代表的是kerberos协议类型的版本,这里5代表是kerberos v5.因为kerberos v4的缺陷默认不会预认证,kerberos v5则加了预认证,msg-type表示了消息类型为krb--as-req

第二部分: kdc-options代表各种票证的标志及属性。客户端信息cname代表请求的用户,relalm代表派发该票据的域名称

第三部分:被请求的服务名称,这里它是windows域名,till:(到期时间,rubeus和kekeo都是20370913024805Z,这个可以作为认证来检测工具),nonce:用来防止数据包重放(随机生成的一个数kekeo/mimikatz nonce是12381973,rubeus nonce是1818848256,这个也可以用来作为特征检测工具。)

第四部分:etype加密类型,KDC通过etype中的加密类型选择用户对应的hash进行解密

AS-REQ

接着KDC相应告诉客户端它需要更多信息来证明

 

在AS-REQ里面cname 是请求的用户,这个用户名存在和不存在,AS-REP返回的包有差异,可以用于枚举域内用户名

AS-REQ

用户向KDC发起AS_REQ,请求凭据是用户 hash加密的时间戳。请求凭据放在PA_DATA里面

这一步骤:用户登录输入的密码经过hash作为加密算法的密钥,加密时间戳加密后的value发送给AS服务器,AS服务器会去数据库中查找用户(administrator)对应的hash去解密PA-DATA PA-ENC-TIMESTAMP(时间戳加密结果),如果能解密成功,而且时间在一定范围内,PAC requests true,KDC根据include的值来判断返回的票据中是否携带PAC。 

32355402fd6aa4f403f50854886c72aeeaa8be7a764ca86bac8ed927adc2cb68bfff5a48e5aa68bfe3ab39ba57078b411008fd850e00a485就是加密后的结果。

AS-REP

KDC存有对应用户的密码 hash, 所以KDC在收到请求后会解出里面的时间戳, 如能正常解密, KDC 则会认为客户端提供的密码 hash 正确, 随后KDC会向客户端返回两个东西, 一个是用用户密码 hash 加密的会话密钥(session key),另外一个是TGT只有KDC能解密,因为用的krbtgt hash进行加密

 

第一部分:在AS_REQ请求里面是使用krbtgt的hash进行加密的客户端无法解密只有KDC能解密,解密出来的内容用户名、域、会话密钥、时间戳、存活周期、 PAC 数据,如果获取到了krbtgt的hash就可以自己制作一个ticket(黄金票据)

第二部分:由客户端用户密码 hash 加密, 客户端可直接解密,解密后得到Encryptionkey(会话密钥),TGS 服务名称默认 krbtgt,域,Encryptionkey(会话密钥),时间戳,Encryptionkey里面最重要的字段是session key,作为下阶段的认证密钥。两个步骤中使用的会话密钥为同一个。

TGT-REQ

当客户端用户到收到返回的会话密钥和TGT,会先用自己的密码hash解密出会话密钥,客户端无法解密TGT,客户端会把TGT存到自己缓存中备用,有了TGT接着向KDC要访问指定服务的票据,请求的内容包含TGT、身份认证信息、SPN信息。

 

第一部分:这个ticket用于AP_REQ的认证,使用krbtgt的hash进行加密的,而在TGS_REQ里面是使用要请求的服务的hash加密的。因此如果我们拥有服务的hash就可以自己制作一个ticket,白银票据。

第二部分:这个是可以解密使用key是上一轮AS_REP里面返回的session_key。

TGT-REP

KDC收到请求后,会用krbtgt密码hash解密TGT,获取用户名,会话密钥和时间戳,接着再用会话密钥去解密身份验证信息(authenticator)中的用户名和时间戳,将此处两个用户和时间戳进行对比,并确定TGT是否还在生命周期内,如果正常,KDC会创建个TGS,然后将TGS和另外一段会话密钥(Server Session Key)加密的数据返回给客户端,客户端和KDC通信结束。

第一部分:是TGS由服务hash加密而成,解密内容包含:服务会话密钥,用户名,域,时间戳,域,生存周期,PAC信息。

第二部分:由会话密钥加密包含:服务会话密钥,时间戳,生存周期

AP-REQ

客户端会拿着返回的 TGS和身份验证信息(由服务会话密钥加密)向服务端请求

 

AP-REP

服务收到请求后,会先用自己的密码 hash 解密服务票证,提取其中的服务会话密钥(Server Session Key), 用户名和时间戳,然后再使用服务会话密钥解密身份验证信息中的用户名和时间戳,将两处解密的用户名和时间戳进行对比,检查生存周期,如一切正常,则整个身份验证过程完

成,验证过后,下一步就是最终授权,而授权则取决于票据中的 pac 信息。

 

参考

 

   https://www.t00ls.net/viewthread.php?tid=55987&highlight=kerberos

   https://blog.csdn.net/lovebomei/article/details/79814979

   https://green-m.me/2019/01/24/play-with-kerberos/

 

posted @ 2019-07-23 15:45  aoaoaoao  阅读(3029)  评论(1编辑  收藏  举报