只有在域内才存在Kerberos认证。

kerberos协议介绍

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

在以上情况下,kerberos作为一种可信任的第三方认证服务,是通过传统的密码技术(如:共享密钥)执行认证服务。

Kerberos协议角色组成

Kerberos协议中存在三个角色,分别是:

1、客户端(client):发送请求的一方。

2、服务端(server):接收请求的一方。

3、密钥分发中心(Key Distribution Center, KDC),而密钥分发中心一般又分为两部分分别是:

AS(Authentication Server):认证服务器,专门用来认证客户端的身份并发放客户用于访问TGS的TGT(票据授予票据)。

TGS(Ticket Granting Server):票据授予服务器,用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据(Ticket)。

Kerberos的认证流程

  1. 客户端带着相关认证信息访问AS服务

  2. 认证成功后返回TGT票据给客户端

  3. 客户端拿着TGT票据来访问TGS服务

  4. TGS通过认证TGT票据,认证成功返回客户端ST票据

  5. 客户端拿着ST票据来访问服务端

  6. 服务端通过验证ST票据,返回请求数据

客户端和AS通信过程

客户端通过,提供身份信息的数据包AS-REQ访问AS。

认证通过后,AS提供一张访问TGS的票据TGT,该票据包含在AS-REP数据包中。

客户端和AS通信数据包分析

机器名

登录用户

机器版本

ip

zp-pc

zs(客户端)

2008

192.168.40.20

ls-pc

ls(服务端)

2008

192.168.40.30

用于测试的工具:

[kekeo]  https://github.com/gentilkiwi/kekeo/releases/tag/2.2.0-20211214 

使用工具发起对AS服务发起AS-REQ并返回AS-REP:

kekeo.exe工具命令:

tgt::ask /user:[用户名] /domain:[域名] /password:[密码] #申请TGT票据
tgs::ask /tgt:[票据名] /service:cifs/[域名地址:ls-pc.abc.com] /ptt #如果不加/ptt则申请ST票据,如果加/ptt则直接将票据注入内存中。

使用WireShark获取到请求(AS-REQ)和响应(AS-REP)的数据包:

其中AS-REQ数据包如下:

  1. PA-DATA PA-ENC-TIMESTAMP中的padata-value的值是通过用户的hash或者AES key加密时间戳生成的value

  2. kdc-options协商字段

  3. cname请求的用户名

  4. realm域名

  5. sname请求服务器名

AS-REP数据包如下:

当KDC的AS服务收到AS-REQ之后,解密PA-DATA PA-ENC-TIMESTAMP如果成功就返回AS-REP。

使用用户HASH加密的信息:

  • Time

  • TGSname

  • TGT有效时间

  • CT_SK

使用KrbtgtHash值进行加密的信息:

  • Name

  • IP

  • Time

  • TGSNAME

  • TGT有效时间

  • CT_SK

将AS-REP数据包中的两个加密的部分合起来就是TGT票据。

客户端和TGS通讯数据包分析

使用上述kekeo工具执行如下命令,并观察数据包:

tgs::ask /tgt:[票据名] /service:cifs/[域名地址:ls-pc.abc.com]

TGS-REQ:客户端发送给TGS的数据包,其中大体如下:

  1. authenticator:使用CT_SK加密内容

  2. ticket:原始的TGT使用Krbtgt加密

  3. cname:请求用户名

  4. sname:请求服务名

这里对比以下AS-REP和TGS-REQ中的使用krbtgt的值是否一致:

TGS-REQ其中数据包中,就是用户通过从新封装TGT票据然后发送给TGS,但是票据中经过krbtgt的hash值加密的数据没有变。

TGS:TGS发送给客户端的数据包,大体如下:

  1. ticket:内容

  2. sname-enc-part:ticket中的part是使用服务秘钥机密内容

  3. enc-part:外层的part是使用CT_SK加密

内部和外部的enc-part的加密内容中多了CS_SK。

这部分发给客户端的数据包的加密部分合在一起即为ST票据。

发送给客户端后,客户端使用CT-SK解密外部enc-part部分,然后获取到加密内容中的CS_SK,然后对解密后的内容进行修改再使用CS_SK加密之前解密的部分对ST票据进行重新封装。

客户端和服务端通讯数据包分析

使用工具kekeo将生成的票据注入内存中,并访问服务端共享文件服务查看数据包:

tgs::ask /tgt:[票据名] /service:cifs/[域名地址:ls-pc.abc.com] /ptt #将票据注入内存中
net \\ls-ps.abc.com\c$  #访问服务端共享服务

注:这里使用的TGT票据为Administrator用户的,普通用户票据没权限。

客户端和服务端通讯数据包走的就不是Kerberos协议了:AP-REQ、AP-REP

发现通过认证后,请求和接收请求转为了NTLM认证:

AP-REQ:

将AP-REQ的ticket的enc-part的值跟TGS-REP的ticket的enc-part的值进行对比:

经过对比发现两者值一样。即证明TGS通过TGS-REP发送给客户端的ST票据中,使用服务端Hash值进行加密的数据没有改变。

AP-REP则是,服务端发送给客户端的信息,包含了客户端验证服务端的信息:

注:我们使用客户端使用票据连接服务端的时候要使用Administrator的票据或域内普通管理员的票据。因为普通用户的票据就算申请了,也是没有权限访问对方电脑的。

相关

Windows认证机制

NTML认证抓包分析

NTLM协议Challenge和Response分析