ToB企服应用市场:ToB评测及商务社交产业平台

标题: 域渗出之初识Kerberos认证过程 [打印本页]

作者: 老婆出轨 时间: 2024-6-19 23:10
标题: 域渗出之初识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协议的工作流程

客户端向KDC的AS认证服务请求TGT票据
客户端通过AS认证后，KDC将会给客户端发放TGT票据
客户端带上TGT票据，向TGS认证服务请求ST服务票据
客户端通过TGS认证后，TGS将会给客户端发放ST服务票据
客户端使用ST服务票据向服务端请求服务
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流程变成：

用户向KDC发起AS_REQ，请求凭据是用户hash加密的时间戳，KDC使用用户hash进行解密，假如结果精确返回用krbtgt的hash加密的TGT票据，TGT票据内里包罗PAC，PAC包罗用户的sid，用户所在的组。
用户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求，KDC使用krbtgt的hash进行解密，假如结果精确，就返回用服务hash加密的ST票据。
用户拿着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(￣▽￣)ブ

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)