内网学习-Windows认证-Kerberos认证

最近整理、改正、补充了一些之前学习内网的笔记，后面陆续更新到博客。如有问题请大佬留言指正

什么是Kerberos

麻省理工学院研发Kerberos协议来保护雅典娜工程（Project Athena）提供的网络服务器。这个协议以希腊神话中的人物Kerberos（或者Cerberus）命名，他在希腊神话中是Hades的一条凶猛的三头保卫神犬。目前该协议存在一些版本，版本1-3都只有麻省理工内部发行。

Kerberos认证中的三种角色

Kerberos认证与他的命名缘由一样，需要三方一起完成认证。

  1. 访问服务的客户端：每个Kerberos的客户端在访问资源前都会请求身份验证。
  2. 提供服务的服务端：每个服务端都拥有唯一的SPN。
  3. 提供认证服务的KDC：KDC是一种网络服务，它向活动目录域内的用户和计算机提供会话票据和临时会话密钥，服务账户为krbtgt。KDC作为活动目录域服务的一部分运行在每一个域控制器上。

认证流程

流程图如下
图片
Kerberos是一种基于票据的认证方式。和我们日常生活中买票和检票验证基本一致，只是票据（ST）不能直接购买，需要有一张认购权证（TGT）才可以。

说人话：

  1. 客户想要获取服务端的资源，先向域控的KDC请求认购权证（TGT）。
  2. 域控身份验证通过后返回TGT。
  3. 客户有了买票资格，向域控的KDC请求服务票据（ST）。
  4. 域控身份验证通过后返回ST。
  5. 拿票（ST）进站，请求服务端资源。
  6. 服务端验票（ST），通过后返回资源给客户。

Kerberos使用TCP/UDP 88端口进行认证，TCP/UDP 464端口进行密码重设。

PAC

PAC包含授权、附加凭据、配置文件和策略信息等。被用于鉴别用户身份和权限。

在一次正常Kerberos认证中，域控上的KDC返回TGT和ST中都带有PAC。所以后续对资源的访问中，服务端接收客户端请求的时候不需要在想KDC提供完整授权信息来对用户权限进行判断。只需要将请求中含有的PAC信息直接与本地资源的ACL相比较来做出裁决。

各阶段的流程及安全问题

PAC安全问题

KDC默认不验证PAC签名，是白银票据攻击成功的前提。
域内提权漏洞：MS14-068，允许域内任何一个普通用户，将自己的权限提升至域管理员权限。

AS-REQ & AS-REP阶段

AS-REQ

完整的AS-REQ包有很多个字段，这里只记录可能产生安全问题的字段。

  1. PA-DATA pA-ENC-TIMESTAMP：预认证，将用户的Hash加密时间戳作为value发送到KDC的AS。KDC从活动目录查询出用户Hash，使用用户Hash解密，如果能解密，得到的时间戳在一定范围内，则认证通过。由于使用用户密码Hash加密的时间戳，所以造成了PTH（Pass The Hash，即哈希传递）攻击。
    这一步中也可能是使用用户密码的AES Key加密时间戳，当获取到的不是用户密码Hash而是用户密码的AES Key时，可以进行PTK（Pass The Key，即密钥传递）攻击。
  2. PA-DATA pA-PAC-REQUEST：根据include值确定返回票据中是否携带PAC。
  3. include-pac：True代表包含PAC。
  4. cname：请求的用户名，这里用户名存在或不存在，返回包有差异，类似web测试时在登录功能点存在指向性信息，如：用户名不存在、用户名错误等提示信息，所以可以用于枚举域内用户名。而当用户名存在时，密码正确与否也会影响返回包，也类似web测试中登陆功能点响应：密码错误、密码不正确等指向性信息。所以也可进行密码喷洒。
  5. sname：请求的服务，AS-REQ中sname始终为krbtgt。

AS-REP

KDC的AS收到客户端的AS-REQ后，AS从活动目录数据库中取出该用户的密钥，然后用密钥对预认证部分解密，如得到的时间戳在一定范围内，则验证通过。发送AS-REP包给客户端。
完整的AS-REQ包有很多个字段，这里只记录可能产生安全问题的字段。
ticket：认购权证票据
ticket中的enc-part：TGT中的加密部分，这部分是用krbtgt的密码Hash加密的。所以如果我们获取到了krbtgt 的Hash，就可以自己制作一个ticket，也就造成了黄金票据传递攻击。
AS-REP阶段中，Logon Session Key是用用户密码的Hash加密的，对于域用户，如果设置了“Do not Kerberos preauthentication”（不需要预认证）选项。攻击者向域控88端口发送AS-REQ，此时域控不会验证身份便会返回TGT和该用户Hash加密的Logon Session Key返回。这样攻击者就可以将这部分数据进行离线破解，如破解成功则可得到用户明文密码。这种攻击方式被称为AS-REP Roasting攻击。

TGS-REQ & TGS-REP阶段

TGS-REP

KDC的TGS服务收到TGS-REQ后

  1. 使用krbtgt密钥解密TGT中的加密部分，得到Logon Session Key和PAC等信息。解密成功说明TGT是KDC颁发的。
  2. 验证PAC签名，签名正确说明未经篡改。
  3. 使用Logon Session Key解密authenticator得到时间戳等信息，如能解密成功并票据时间在有效范围内，则验证了会话安全性。
    完成上述检测后，KDC的TGS完成了对客户端认证，TGS发送回复包给客户端。
    TGS-REP中的ST是使用服务的Hash进行加密的，如果我们有服务的Hash就可以签发任意用户的ST，这个票据被称为白银票据。
    如果我们能获取到ST，也可以对ST进行破解，得到服务的Hash，造成Kerberoasting攻击。
S4u2Self & S4u2Proxy

这两个协议的出现是为了在Kerberos协议层面对约束性委派进行支持。S4u2Self可以代表任意用户请求针对自身的服务票据，S4u2Proxy可以用上一步获得的ST以用户的名义请求针对其他指定服务的ST。
安全问题：非约束性委派攻击，约束性委派攻击，基于资源的约束性委派攻击。

KB2871997补丁对PTH与PTK攻击的影响

PTH：没打补丁前任意用户都可以连接，打了补丁只能使用administrator连接。
PTK：打了补丁才能任意用户连接，采用aes256连接。

参考资料

Kerberos的维基百科
谢公子的《域渗透攻防指南》，jd购买链接。
永信至诚霄壤实验室 Nu1L Team主编的《内网渗透体系建设》
北京大学出版社出版的杨湘和等著的《Kerberos域网络安全从入门到精通》
内网渗透-PTH&PTT&PTK

Q.E.D.

正在加载今日诗词....