『杂项』Kerberos协议（一）

点击蓝字

关注我们

日期：2022-03-25

作者：pbfochk

介绍：梳理一下kerberos协议的基本原理。

0x00 前言

之前域相关的文章讲到过黄金票据、白银票据等认证手段，其中票据的识别利用大多依赖于kerberos协议来完成，这里首先梳理一下kerberos协议的基本原理，为下一篇域环境内的委派攻击做一下铺垫。

0x01 Kerberos

1.1 Kerberos 协议

Kerberos 协议是一种计算机网络授权协议，用来在非安全网络中，对个人通信以安全的手段进行身份认证。其设计目标是通过密钥系统为客户机与服务器应用程序提供强大的认证服务。该协议的认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的。Kerberos 协议在在内网域渗透领域中至关重要，白银票据、黄金票据、攻击域控等都离不开 Kerberos 协议。

1.2 Kerberos 协议认证过程

认证过程中会用到的基本服务：

KDC(Key Distribution center)：密钥分发中心，在域环境中，KDC服务默认会安装在域控中。
AS(Authentication Service)：认证服务，验证client的credential(身份认证信息)，发放TGT。
TGT(Ticket Granting ticket)：票据授权票据，由KDC的AS发放，客户端获取到该票据后，以后申请其他应用的服务票据(ST)时，就不需要向KDC的AS提交身份认证信息(credential)，TGT具有一定的有效期。

简单来说，kerberos协议认证大概分为以下几个流程：

（1）首先Client向域控发送请求，域控遍历 AD 活动目录中查找该Client身份，并验证其是否可信。

（2）验证通过后即返回给该Client对应的TGT，Client获取到TGT后可以凭借 TGT向域控请求相应服务。

（3）域控首先判断Client是否具有访问权限，如果有，则给Client访问服务的权限ST。

（4）Client获取到ST后，利用该服务票据去访问该服务，该票据有且只有对该服务的访问权限。至此Client利用该票据与服务建立通信。

1.3 Kerberos 协议中的域委派

1.委派

委派简单来说就是在一个环境中，A具有访问C的权限，A与B因为某些事情需要合作，这时A就需要B从C那里拿到相应的数据，但是B没有权限获取C的数据，这时A可以委派B利用自己的身份从C获取数据，B利用A赋予它的票据向C申请数据，C在验证B提供的A的票据通过后，将数据提供给B。

2.非约束委派

非约束委派即不收任何约束，简单来说就是A把从KDC获取的TGT发送给B，B可以通过该TGT访问域内任意服务，即非约束委派。

具体流程如下：

1、用户通过发送KRB_AS_REQ消息请求可转发 TGT（forwardable TGT，为了方便我们称为TGT1）。
2、KDC在KRB_AS_REP消息中返回TGT1。
3、用户再通过TGT1向KDC请求转发TGT（forwardedTGT，我们称为TGT2）。
4、在KRB_TGS_REP消息中返回转发TGT2。
5、用户使用TGT1向KDC申请访问Service1的ST（ServiceTicket）。
6、TGS返回给用户一个ST。
7、用户发送KRB_AP_REQ请求至Service1，这个请求中包含了TGT1和ST、TGT2、TGT2的SessionKey。
8、Service1使用用户的TGT2通过KRB_TGS_REQ发送给KDC，以用户的名义请求能够访问Service2的票据。
9、KDC在KRB_TGS_REP消息中返回Service2到Service1的票据。
10、Service1以用户的名义像Service2发送KRB_AP_REQ请求。
11、Service2响应步骤10中Service1的请求。
12、Service1响应步骤7中用户的请求。
13、在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请求任意服务。
14、KDC返回步骤13中请求的票据。
15和16即为Service1通过模拟用户来访问其他Service。

3.约束委派

约束委派与非约束委派的差异在于把A发送给B的TGT做了限制，不允许B利用获取到的TGT去访问其他服务，实现该功能利用到了S4U2Self（Service for User to Self）和S4U2Proxy（Service forUser to Proxy）的Kerberos协议扩展。

注：

（1）S4U2self 使得服务可以代表用户获得针对服务自身的kerberos服务票据。这使得服务可以获得用户的授权，然后将其用于后期的认证(主要是后期的s4u2proxy)，这是为了在用户以不使用 Kerberos 的方式对服务进行身份验证的情况下使用。 s4u2self的工作过程如下：

（2）s4u2proxy 使得服务1可以使用来自用户的授权，然后用该TGS(放在AddtionTicket里面)向KDC请求访问服务2的TGS，并且代表用户访问服务2，而且只能访问服务2。 s4u2proxy的工作过程如下：

具体流程如下：

1、用户向Service1发送请求。
2、这时在官方文档中的介绍是在这一流程开始之前Service1已经通过KRB_AS_REQ得到了用户用来访问Service1的TGT，然后通过S4U2self扩展模拟用户向KDC请求ST。
3、KDC这时返回给Service1一个用于用户验证Service1的ST（我们称为ST1），并且Service1用这个ST1完成和用户的验证过程。
4、Service1在步骤3使用模拟用户申请的ST1完成与用户的验证，然后响应用户，其中获取到的TGT权限受S4U2Self扩展的限制。
5、用户再次向Service1发起请求，此时Service1需要以用户的身份访问Service2。
6、Service1代表用户向Service2请求一个用于认证Service2的ST（我们称为ST2）。用户在ST1中通过cname（client name）和crealm（client realm）字段标识。
7、KDC在接收到步骤6中Service1的请求之后，会验证PAC（特权属性证书，在第一篇中有说明）的数字签名。如果验证成功或者这个请求没有PAC（不能验证失败），KDC将返回ST2给Service1，不过这个ST2中cname和crealm标识的是用户而不是Service1。
8、Service1代表用户使用ST2请求Service2。Service2判断这个请求来自已经通过KDC验证的用户。
9、Service2响应Service1的请求。
10、Service1响应用户的请求。

如下图所示，约束委派可指定该TGT被获取后可访问的服务。

0x02 总结

刚开始接触域环境渗透的内容时并没有第一时间去了解相关协议的原理，现在回过头来学习一下域环境中票据的传递方法及协议原理。在参考了很多文章后，算是对协议的认证方法有了初步的了解，后续利用Kerberos协议的安全问题测试一下域委派的相关内容。

参考链接

https://www.freebuf.com/articles/system/198381.html

https://www.cnblogs.com/sup3rman/p/13710236.html

免责声明：本文仅供安全研究与讨论之用，严禁用于非法用途，违者后果自负。

宸极实验室

Cyber Security Lab

宸极实验室隶属山东九州信泰信息科技股份有限公司，致力于网络安全对抗技术研究，是山东省发改委认定的“网络安全对抗关键技术山东省工程实验室”。团队成员专注于 Web 安全、移动安全、红蓝对抗等领域，善于利用黑客视角发现和解决网络安全问题。

团队自成立以来，圆满完成了多次国家级、省部级重要网络安全保障和攻防演习活动，并积极参加各类网络安全竞赛，屡获殊荣。

对信息安全感兴趣的小伙伴欢迎加入宸极实验室，关注公众号，回复『招聘』，获取联系方式。

原文始发于微信公众号（宸极实验室）：『杂项』Kerberos协议（一）