域渗透之初识Kerberos认证过程

Kerberos 是一种由麻省理工学院提出的一种网络身份验证协议,它通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

Kerberos协议中的角色

在Kerberos协议中主要是有三个角色:

  • 访问服务的客户端 Client

  • 提供服务的服务端 Server

  • 密钥分发中心KDC(Kerberos协议的核心组成)

KDC 服务会默认安装在域控中,而Client和Server分别是域内的客户和服务,在Kerberos中Client是否有权限访问Server端的服务,是由KDC发放的票据来决定的。

KDC中分成两个部分:

  • 身份验证服务AS:验证Client的身份,验证通过之后,AS就会发放TGT票据给Client。

  • 票据授予服务TGS:当Client获取的TGT票据后,TGS会给Clinet换取访问Server端的ST服务票据。

关键名词

  • DC 域控制器 Domain Controller

  • KDC 密钥分发中心 Key Distribution Center

  • AS 身份验证服务 Authentication Service

  • TGS 票据授予服务 Ticket Granting Service

  • TGT 认证票据 Ticket Granting Ticket

  • ST 服务票据 Service Ticket

  • PAC 特权属性证书 Privilege Attribute Certificate

  • AD 账户数据库 Account Database(存储所有Client的白名单)

  • krbtgt账户(KDC的服务账户)

Kerberos协议的工作流程

  1. 客户端向KDC的AS认证服务请求TGT票据

  2. 客户端通过AS认证后,KDC将会给客户端发放TGT票据

  3. 客户端带上TGT票据,向TGS认证服务请求ST服务票据

  4. 客户端通过TGS认证后,TGS将会给客户端发放ST服务票据

  5. 客户端使用ST服务票据向服务端请求服务

  6. PAC校验:服务端拿到PAC询问KDC客户端是否有权限,KDC将客户端的权限信息返回给服务端,判断客户端是否有权限访问该服务,并把结果返回给客户端

举个例子:

下面来具体地了解Kerberos工作流程,强烈建议使用 windows_protocol 项目开发的Kerberos发包工具来模拟Kerberos认证的过程,从而加强理解。

Kerberos发包工具地址:https://github.com/daikerSec/windows_protocol/tree/master/tools

AS_REQ & AS_REP

首先是客户端与KDC中AS之间的认证,使用 AS_REQ & AS_REP 模块:

AS_REQ

AS_REQ指的是客户端向KDC发起AS认证服务请求TGT票据,请求凭据是客户端hash加密的时间戳。

这里ENC_TIMESTAMP是预认证,就是用客户端用户hash加密时间戳,发送给AS服务器。在AS服务器中有用户hash,然后使用用户hash进行解密,获得时间戳。如果能解密,并且时间戳在一定的范围内,则认证通过。

这里PA_PAC_REQUEST是启用PAC支持的扩展,PAC信息将包含在AS_REP中。这里的value对应的是include=true或者include=false(KDC根据include的值来判断返回的票据中是否携带PAC)。

AS_REP

AS_REP指的是AS预认证通过,接着AS认证服务会返回用krbtgt hash加密的TGT票据和用户hash加密的session key及其他信息。

这里ticket就是用于向TGS认证服务请求ST服务票据的认证,ticket中的这个enc-part是由krbtgt hash加密的,用户不可读取。

而在ticket下方的这个enc_part是使用用户hash加密的一个session key,用户解密后可以拿到这个session key作为下阶段的认证密钥。

TGT票据凭据里面最核心的东西就是krbtgt hash加密的ticket和用户hash加密的session key。

在AS_REP里面的ticket中的enc-part是使用krbtgt hash加密的。所以如果我们拥有krbtgt的hash,就可以给我们自己签发任意用户的TGT票据,这个票据也被称为黄金票据。

TGS_REQ & TGS_REP

当客户端获取TGT票据之后,可以去向KDC的TGS申请特定服务的访问权限,使用 TGS_REQ & TGS_REP 模块:

TGS_REQ

TGS_REQ指的是客户端带上从AS那里获得TGT票据,向TGS认证服务请求ST服务票据。

这里ar-req这部分会携带AS_REP里面获取到的TGT票据。图中可以看到ar-req中的ticket和AS_REP的ticket部分是完全一致的。TGS通过krbtgt的hash解密TGT票据,然后验证客户端的身份。

TGS_REP

TGS_REP指的是客户端通过了TGS认证服务后,TGS将会给客户端用户发放ST服务票据。TGS生成的ST服务票据其中包括ticket和一个新的session key。

这里ticket就是最终用户用于请求特定服务AP_REQ的认证(ST票据),里面的enc_part也是加密的,是使用要请求的服务的hash加密的,用户不可读取。

在ticket下方的enc-part这部分是可以解密的,密钥就是上一轮AS_REP里面返回TGT票据中的session key,解密以后的这个新session key同样用来作为下阶段的认证密钥。

在TGS_REQ里面是使用要请求的服务(host)的hash加密的。因此如果我们拥有服务的hash就可以自己制作一个ticket,既白银票据。

AP_REQ

AP_REQ指的是最后客户端用户使用ST票据去访问特定的服务。

客户端首先将ST票据中解密后的session key缓存,然后客户端将ST服务票据和session key加密的时间戳一起发送给服务端。

服务端使用自己的hash解密ST票据提取session key,然后使用session key验证加密的时间戳,确认客户端的身份并建立会话。

PAC

TGS_REP这里其实存在一个隐患:在这一步中,不论用户是否有权限访问服务,只要TGT解密无误,都将返回ST服务票据。那么任何一个用户,只要hash正确,就可以请求域内任何一个服务的票据。

为了解决上面的这个问题,微软引进了PAC(Privilege Attribute Certificate)即特权属性证书,用来验证用户权限和模拟用户操作的凭证。

引进PAC之后的kerberos流程变成:

  1. 用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳,KDC使用用户hash进行解密,如果结果正确返回用krbtgt的hash加密的TGT票据,TGT票据里面包含PAC,PAC包含用户的sid,用户所在的组。

  2. 用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求,KDC使用krbtgt的hash进行解密,如果结果正确,就返回用服务hash加密的ST票据。

  3. 用户拿着ST票据去请求服务,服务使用自己的hash解密TGS票据。如果解密正确,就拿着PAC去KDC那边询问用户有没有访问权限,域控解密PAC。获取用户的sid,以及所在的组,再判断用户是否有访问服务的权限。

总结

以上就是Kerberos工作流程的三个主要部分简单分析,Kerberos还有很多细节内容值得学习,包括PAC,委派等,还有在认证的过程中引发的一系列安全问题,比如常听到的黄金票据和白银票据等。持续学习!

参考文章:
https://daiker.gitbook.io/windows-protocol/kerberos
https://xz.aliyun.com/t/8187?time__1311=n4%2BxuDgDBDyGKiKPe05DK3hrDcDAo42u%2BGirD&alichlgref=https%3A%2F%2Fxxe.icu%2F
https://xxe.icu/domain-security.html#域用户名枚举
https://zhuanlan.zhihu.com/p/266491528


若有错误,欢迎指正!o( ̄▽ ̄)ブ

热门相关:美食萌后:皇上,喂不饱!   不负荣光,不负你   驭房之术   遥望行止   【戏说台湾】天公点鸳鸯