基于赛宁网络靶场的内网渗透一:Kerberos认证基础

  XCTF联赛小秘       2020-07-15 15:25:19 871  0

天虞实验室正式成立于2020年6月,是赛宁网安旗下以攻防技术研究为目标的安全团队,目前拥有20位专业的安全研究员,专注于渗透测试、安全开发、IOT安全、工控安全等方面。从本周开始,天虞实验室将基于赛宁网络靶场开展内网渗透系列教学,敬请关注。

在古希腊神话中Kerberos指的是:一只三头犬守护在地狱之门外,禁止任何人类闯入地狱之中。而现实中的Kerberos是一种网络认证协议,其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务,域环境中默认优先使用Kerberos进行认证。



下面请看Kerberos 协议框架:


通过上图可以看到整个认证流程有三个重要的角色,分别为Client、Server和KDC。

 下面介绍下几个相关的名词:

1、访问服务的 Client。


2、提供服务的 Server。


3、KDC(Key Distribution Center):密钥分发中心。

在KDC中又分为两个部分:Authentication Service(AS,身份验证服务)和Ticket Granting Service(TGS,票据授权服务)。


4、DC(Domain Controller):即域控制器;AD(Active Directory):即活动目录。


DC中有一个特殊用户叫做:krbtgt,它是一个无法登录的账户,是在创建域时系统自动创建的,在整个kerberos认证中会多次用到它的Hash值去做验证。


AD会维护一个Account Database(账户数据库). 它存储了域中所有用户的密码Hash和白名单。只有账户密码都在白名单中的Client才能申请到TGT。


举个简单的栗子:如果把Kerberos中的票据一类比作一张门禁卡,那么Client端就是住客,Server端就是房间,而KDC就是小区的门禁。住客想要进入小区,就需要手里的门禁卡与门禁相对应,只有通过门禁的验证,才能打开门禁进入小区,整个过程就相当于一个缩减版的Kerberos认证。 


Kerberos 详细认证流程:




当 Client 想要访问 Server 上的某个服务时,需要先向 AS 证明自己的身份,验证通过后AS会发放的一个TGT,随后Client再次向TGS证明自己的身份,验证通过后TGS会发放一个ST,最后Client向 Server 发起认证请求,这个过程分为三块: 


※ Client 与 AS 的交互

※ Client 与 TGS 的交互

※ Client 与 Server 的交互



Client 与 AS 的交互



一、准备:

用户在Client中输入账号密码后,Client会对密码进行哈希加密,我们叫做Master key。


1、请求:Client 先向 KDC 的 AS 发送 Authenticator(认证者),我们叫它Authenticator1,为了确保Authenticator1仅限于自己和KDC知道,Client使用自己的Master Key对其的主体部分进行加密。


其内容为:

1)、经过 ClientMaster Key(用户的NTLM Hash)加密的TimeStamp(一个当前时间的时间戳)。

2)、Client的一些信息(info),比如用户名。 



二、响应:

1、AS接收到Authenticator1后,会根据Client提交的用户名在AD中寻找是否在白名单中,然后查询到该用户名的密码,并提取到Client对应的Master key,对TimeStamp进行解密,如果是一个合法的Timestamp,就证明了Client提供的用户名和密码是存在AD中的,并且AS提取到的Timestamp不能超过5分钟,否则AS就会直接拒绝Client的请求。


2、TimeStamp验证通过后,AS会给Client发送一个由Client的Master key加密过的Logon Session Key和一个TGT(client-server-ticket)。TGT的内容:经过KDC中的Master Key(krbtgt NTLM Hash)加密的 Logon Session Key(临时会话密钥) 和 TimeStamp、TGS会话密钥、用户信息、TGT到期时间。


当Client通过AS的验证,并顺利拿到TGT就完成了Kerberos的第一步认证。


这里需要理解Logon Session Key:


1、Logon Session Key是什么:

即临时会话秘钥a,Client向KDC发起对TGT的申请说自己要去访问Server上的摸个服务,KDC在收到该请求后,会生成一个用于该Client和KDC进行安全通信的Session Key(SKDC-Client,也被称为Logon Session Key)。这里KDC不会保存SKDC-Client。


需要注意的是SKDC-Client是一个临时会话秘钥,所以它具有自己的生命周期,同时TGT和Session相互关联,当Logon Session Key过期,TGT也就失效了。


2、 到了第二步还有一个Session Key(临时会话秘钥b),是用于Client和Server之间通信的Session Key(SServer-Client),这里Server也不会保存SServer-Client。



Client 与 TGS 的交互

Client使用TGT从KDC获得基于某个Server的Ticket



一、请求:

Client通过自己的Master key对第一部分解密获得Logon Session Key之后,携带着TGT对TGT发送请求。Client是解不开TGT的,它作为一个Client通过身份验证的票提交给TGS。 


请求的内容:

1、TGT:Client通过与AS交互获得的TGT,TGT 被 KDC 的 Master Key 进行加密。

2、Authenticator2:Client端使用 Logon Session Key对其进行加密,Authenticator2实际上就是关于Client的一些信息和当前时间的一个Timestamp,用以证明当初 TGT 的拥有者是否就是自己。



二、响应--TGS验证通过后发放ST(Service Ticket)票:

TGS收到Client请求,验证其真实身份:


TGS 在发给Client真正的Ticket之前,会检查自身是否存在 Client 所请求的服务,如果服务存在,还得确定Client提供的那个TGT是否是AS颁发给它的,于是它得通过 Client 提供的 Authenticator2 来证明。但是 Authentication2 是通过 Client的 Logon Session Key 进行加密的,而TGS并没有保存这个 Logon Session Key 。所以 TGS 先得通过自己的 Master Key(krbtgt的密码hash处理) 对 Client 提供的 TGT 进行解密,从而获得Client Info和 Logon Session Key(SKDC-Client),再通过这个Logon Session Key解密 Authenticator2,获得Client Info,对两个Client Info进行比较进而验证对方的真实身份


 响应内容:

认证通过后TGS会生成一个经过Logon Session Key(SKDC-Client)加密的用于Client和Server之间通信的Session Key(SServer-Client),和经过KDC的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 name\Client。Ticket的到期时间。


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



Client 与 Server 的交互与双向验证: 


  Server验证Client:Client通过与TGS交互获得访问Server的Session Key,然后为了证明自己就是ST(Service Ticket)的真正所有者,会将Authenticator和时间戳提取出来,并使用Session Key进行加密。最后将这个被加密过的Authenticator3 和ST作为请求数据包发送给Server。此外还包含一个Flag用于表示Client是否需要进行双向验证。


Server接收到Request之后,首先通过自己的Master Key(krbtgt的NTLM Hash处理)解密ST,从而获得Session Key。然后通过解密出来的Session Key再去解密Authenticator3 ,进而验证对方的身份。如果验证成功,就让 Client 访问对应的资源,否则就会直接拒绝对方的请求。 


到目前为止,服务端已经完成了对客户端的验证,但是,整个认证过程还没有结束。接下来就是Client对Server进行验证以确保Client所访问的不是一个钓鱼服务。 


Server需要将Authenticator3中解密出来的Timestamp再次用Session Key进行加密,并发送给Client。Client再用缓存Session Key进行解密,如果Timestamp和之前的内容完全一样,则可以证明此时的Server是它想访问的Server。



到这里就完成了整个Kerberos认证

下一篇会为大家带来

黄金票据和白银票据的攻击原理和相关操作

敬请期待


请先登录
+1 已点过赞
0
分享到:
登录后才能发贴或参与互动哦! 点击登录

全部评论 (0)