Kerberos协议探索系列之票据篇

阅读量688552

|评论1

发布时间 : 2019-03-08 11:30:24

 

 

0x00 前言

在上一篇中说明了Kerberos的原理以及SPN的扫描和Kerberoasting的攻击方式,本章具体说一下Kerberos曾经爆出的一个经典的漏洞MS14068和金银票据的原理和利用方式。MS14068是一个比较经典的漏洞,曾经也有同学在平台上说明过,本文炒一次冷饭并且对增强型的金票据做一个说明。

 

0x01 MS14068

MS14068是一个能够使普通用户提权到域控权限的权限提升漏洞。攻击者可以通过构造特定的请求包来达到提升权限的目的。首先我们来说一下利用方式。

1 利用方式

实验环境:

域:YUNYING.LAB

域控:Windows Server 2008 R2 x64(DC)

域内主机:Windows 7 x64(s1):域帐户ts1

所需工具:

Pykek

mimikatz

攻击流程:

实验之前需要在域控主机查看是否安装了KB3011780补丁,可通过systeminfo来查看。

一、首先在域内主机s1上通过dir来访问域控的共享文件夹,示拒绝访问。

二、通过Pykek工具利用漏洞,我这里使用的是将python脚本编译之后的exe文件。

参数说明:

-u 域账号+@+域名称,这里是ts1+@+yunying.lab

-p 为当前用户的密码,即ts1的密码

-s为ts1的SID值,可以通过whoami /all来获取用户的SID值

-d为当前域的域控

脚本执行成功会在当前目录下生成一个ccache文件。

三、使用mimikatz导入生成的ccache文件,导入之前cmd下使用命令klist purge或者在mimikatz中使用kerberos::purge删除当前缓存的kerberos票据。

再次dir访问域控共享已经可以成功访问。

2 漏洞原理

MS14068工具在使用过程中抓包可以看到s1和域控192.168.254.130(实质上是与安装在域控上的KDC)有KRB_AS_REQ、KRB_AS_REP、KRB_TGS_REQ、KRB_TGS_REP四次交互。

下面根据流程和源码来看漏洞是如何利用的:

KRB_AS_REQ

首先程序通过build_as_req函数构建AS_REQ,在这里可以看到,参数pac_request设置为false。

也就是说设置了这个参数之后会向KDC申请一张不包含PAC的TGT票据,这是微软默认的设计,在下列链接中有详细说明。

https://docs.microsoft.com/en-us/previous-versions/aa302203(v=msdn.10)#security-considerations

通过PCAP包可以更直观的看到在AS-REQ请求中的include-pac:False字段。这是造成这个漏洞的第一个因素。

KRB_AS_REP

在AS发起请求之后,KDC(AS)将返回一张不包含有PAC的TGT票据给Client。在这里是tgt_a。

抓包可以看到这个以268fdb开头的TGT票据。

KRB_TGS_REQ

攻击脚本使用了两个关键函数来实现这个过程,首先通过build构造PAC,然后通过build_tgs_req函数构造TGS-REQ的内容。

build_pac

当Client接收到AS返回的不带有PAC的TGT之后通过脚本中的build_pac函数开始构造PAC。

这里我们重点关注一下PAC中的chksum1和chksum2,也就是“PAC的引入”中提到的PAC的两个数字签名PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM。

注意一下其中第一个参数server_key[0]和kdc_key[0]的值其实是程序指定的RSA_MD5,而Key的值为None,但原则上来说这个加密方式是应该由KDC来确定的。也就是说加密PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM这两个数字签名的Key应该分别是Server密码HASH和KDC密码HASH,在这里却直接使Key为None,然后直接使用RSA_MD5方式加密。

这是漏洞形成的第二个因素,查看checksum函数即可验证这一点。

同时在这个过程中我们也需要关注一下user_sid这个参数,build_pac函数会将其分割,然后重新构造高权限的sid的值。在这里user_sid的值为S-1-5-21-4249968736-1423802980-663233003-1104,分割之后domain_sid为S-1-5-21-4249968736-1423802980-663233003,user_id为1104。

其中512、520、518、519分别为不同的组的sid号。513为DOMAIN USERS组。通过这种方式构造了包含高权限组SID的PAC。

build_tgs_req

在build_tgs_req函数的参数中,authorization_data对应的为build_pac生成的pac。

这里将PAC传入build_tgs_req之后使用subkey将其加密。

而通过下图可以看到subkey其实是函数generate_subkey生成的一串16位的随机数。

那现在为止出现的问题有:

A、在域中默认允许设置Include-pac的值为False(不能算漏洞,应该是微软对于某些特定场景的特殊考虑设计出的机制)。

B、PAC中的数字签名可以由Client端指定,并且Key的值可以为空。

C、PAC的加密方式也可以由Client指定,并且Key的值为generate_subkey函数生成的16位随机数。

D、构造的PAC中包含高权限组的SID内容。

也就是说通过这几点Client完全伪造了一个PAC发送给KDC,并且KDC通过Client端在请求中指定的加密算法来解密伪造的PAC以及校验数字签名,并验证通过。

通过抓包可以看到在这个过程中将接收的TGT(268fdb开头)和加密方式为ARCFOUR-HMAC-MD5的PAC内容。

KRB_TGS_REP

KDC在根据对伪造的PAC验证成功之后,返回给Client端一有新的TGT,并且这个TGT会将Pykek生成的PAC包含在其中,这里正常情况下返回的其实是一张用于发送给Server端做认证的ST票据。

当Pykek工具接收到新的TGT之后就将其保存生成ccache文件。也就是说这时Client已经获得了一张包含有高权限PAC内容的正常的TGT票据(564eab开头)。

使用Mimikatz利用TGT访问DC共享文件夹

这时我们通过mimikatz来导入票证,并且用dir \\dc.yunying.lab\c$来访问域控的共享文件夹。

抓包可以看到这时Client端发起了两次TGS-REQ请求,重点关注一下第一次,此时用的票据就是使用mimikatz导入的TGT,也就是上面KRB_TGS_REP过程中返回的那个tgt_b(564eab开头)。

请求之后返回了一张针对dc.yunying.lab(域控)的CIFS票据也就是正常流程中的ST(Service Ticket)票据(234062开头):

这时在抓的包中发现并没有AP_REQ这个流程,是因为在Kerberos中AP_REQ这个过程放在了服务的第一次请求中,这里是放在SMB的Session Setup Request中(其他协议同理,比如HTTP协议是放在GET请求中)。

然后在SMB的Session Setup Response中做出响应,也就是AP-REP这个流程。

到此为止Client能够越权访问域控的共享文件夹。

3 防御与检测

此漏洞是一个14年的漏洞,多数产生在windows server 2008和windows server 2003的域环境中,所以安全补丁早已可以下载安装,用户可以通过在域控上安装KB3011780补丁来规避风险。

同时可以根据上文中提到的标记include-pac为False的特征来初步的筛选。

也可以通过windows日志来发现,如ID为4624登录到目标服务器、ID为5140表示网络共享对象被访问等等。

在这个漏洞中主要的问题是存在于KDC会根据客户端指定PAC中数字签名的加密算法,以及PAC的加密算法,来校验PAC的合法性。这使得攻击者可通过伪造PAC,修改PAC中的SID,导致KDC判断攻击者为高权限用户,从而导致权限提升漏洞的产生。

 

0x02 Golden Ticket

简介

Golden Ticket(下面称为金票)是通过伪造的TGT(Ticket Granting Ticket),因为只要有了高权限的TGT,那么就可以发送给TGS换取任意服务的ST。可以说有了金票就有了域内的最高权限。

制作金票的条件:

1、域名称

2、域的SID值

3、域的KRBTGT账户密码HASH

4、伪造用户名,可以是任意的

实验环境

域:YUNYING.LAB

域控:Windows Server 2008 R2 x64(DC)

域内主机:Windows 7 x64(s1):用户ts1

所需工具

Mimikatz

实验流程

金票的生成需要用到krbtgt的密码HASH值,可以通过mimikatz中的

lsadump::dcsync /domain:yunying.lab /user:krbtgt命令获取krbtgt的值。如果已经通过其他方式获取到了KRBTGT HASH也可以直接进行下一步。

得到KRBTGT HASH之后使用mimikatz中的kerberos::golden功能生成金票golden.kiribi,即为伪造成功的TGT。

参数说明:

/admin:伪造的用户名

/domain:域名称

/sid:SID值,注意是去掉最后一个-后面的值

/krbtgt:krbtgt的HASH值

/ticket:生成的票据名称

金票的使用

通过mimikatz中的kerberos::ptt功能(Pass The Ticket)将golden.kiribi导入内存中。

已经可以通过dir成功访问域控的共享文件夹。

这样的方式导入的票据20分钟之内生效,如果过期再次导入就可以,并且可以伪造任意用户。

 

0x03 Silver Tickets

简介

Silver Tickets(下面称银票)就是伪造的ST(Service Ticket),因为在TGT已经在PAC里限定了给Client授权的服务(通过SID的值),所以银票只能访问指定服务。

制作银票的条件:

1.域名称

2.域的SID值

3.域的服务账户的密码HASH(不是krbtgt,是域控)

4.伪造的用户名,可以是任意用户名,这里是silver

实验环境

域:YUNYING.LAB

域控:Windows Server 2008 R2 x64(DC)

域内主机:Windows 7 x64(s1):用户ts1

所需工具

Mimikatz

实验流程

首先我们需要知道服务账户的密码HASH,这里同样拿域控来举例,通过mimikatz查看当前域账号administrator的HASH值。注意,这里使用的不是Administrator账号的HASH,而是DC$的HASH。

这时得到了DC的HASH值,通过mimikatz生成银票。

参数说明:

/domain:当前域名称

/sid:SID值,和金票一样取前面一部分

/target:目标主机,这里是dc.yunying.lab

/service:服务名称,这里需要访问共享文件,所以是cifs

/rc4:目标主机的HASH值

/user:伪造的用户名

/ptt:表示的是Pass The Ticket攻击,是把生成的票据导入内存,也可以使用/ticket导出之后再使用kerberos::ptt来导入

这时通过klist查看本机的kerberos票据可以看到生成的票据。

使用dir \\dc.yunying.lab\c$访问DC的共享文件夹。

银票生成时没有KRBTGT的密码,所以不能伪造TGT票据,只能伪造由Server端密码加密的ST票据,只能访问指定的服务。

 

0x04 Enhanced Golden Tickets

在Golden Ticket部分说明可利用krbtgt的密码HASH值生成金票,从而能够获取域控权限同时能够访问域内其他主机的任何服务。但是普通的金票不能够跨域使用,也就是说金票的权限被限制在当前域内。

1普通金票的局限性

为什么普通金票会被限制只能在当前域内使用?

在上一篇文章中说到了域树和域林的概念,同时说到YUNYING.LAB为其他两个域(NEWS.YUNYING.LAB和DEV.YUNYING.LAB)的根域,根域和其他域的最大的区别就是根域对整个域林都有控制权。而域正是根据Enterprise Admins组(下文会说明)来实现这样的权限划分。

2 实验演示

实验环境

根域:YUNYING.LAB

域控:DC.YUNYING.LAB

子域:NEWS.YUNYING.LAB

域控:NEWSDC.NEWS.YUNYING.LAB

子域:DEV.YUNYING.LAB

域控:DEVDC.DEV.YUNYING.LAB

操作系统均为Windows Server 2008 R2 x64

使用工具:

Mimikatz

实验流程:

首先使用mimikatz在NEWSDC(NEWS.YUNYING.LAB的域控)上生成普通的金票,真实环境会是在域内的主机中,这里方便演示所以在域控中,原理和结果是一样的。

这里使用的是NEWS.YUNYING.LAB域的SID号,访问根域的DC共享文件夹被拒绝。

下面说明下具体原因。

Enterprise Admins组

Enterprise Admins组是域中用户的一个组,只存在于一个林中的根域中,这个组的成员,这里也就是YUNYING.LAB中的Administrator用户(不是本地的Administrator,是域中的Administrator)对域有完全管理控制权。

通过whoami命令在yunying.lab的域控上可以看到Enterprise Admins组的RID为519(最后三位)

Domain Admins组

可以看到在子域中是不存在Enterprise Admins组的,在一个子域中权限最高的组就是Domain Admins组。截图是news.yunying.lab这个子域中的Administrator用户,这个Administrator有当前域的最高权限。

通过whoami命令也可以看到在news.yunying.lab这个子域中没有Enterprise Admins组的SID号。

在子域中使用mimikatz创建的黄金票据不能跨域使用的原因也就在这里,通过whoami可以看到YUNYING.LAB中Enterprise Admins组的SID号是:

S-1-5-21-4249968736-1423802980-663233003-519

而NEWS.YUNYING.LAB域中的SID号是:

S-1-5-21-3641416521-285861825-2863956705-XXX

mimikatz通过/sid选项接收SID号然后在尾部拼接RID号(512,519等),拼接之后生成的Enterprise Admins组的完整SID是:

S-1-5-21-3641416521-285861825-2863956705-519

而这个SID在整个域林中都是不存在的,所以在子域中通过mimikatz生成的金票无法跨域或者是访问其他域的资源。在一个域林中,域控权限不是终点,根域的域控权限才是域渗透的终点。

3 突破限制

普通的黄金票据被限制在当前域内,在2015年Black Hat USA中国外的研究者提出了突破域限制的增强版的黄金票据。通过域内主机在迁移时SIDHistory属性中保存的上一个域的SID值制作可以跨域的金票。这里没有迁移,直接拿根域的SID号做演示。

如果知道根域的SID那么就可以通过子域的KRBTGT的HASH值,使用mimikatz创建具有 Enterprise Admins组权限(域林中的最高权限)的票据。环境与上文普通金票的生成相同。

首先我们通过klist purge删除当前保存的Kerberos票据,也可以在mimikatz里通过kerberos::purge来删除。

然后通过mimikatz重新生成包含根域SID的新的金票

注意这里是不知道根域YUNYING.LAB的krbtgt的密码HASH的,使用的是子域NEWS.YUNYING.LAB中的KRBTGT的密码HASH。

然后再通过dir访问DC. YUNYING.LAB的共享文件夹,发现已经可以成功访问。

此时的这个票据票是拥有整个域林的控制权的。我们知道制作增强金票的条件是通过SIDHistory那防御方法就是在域内主机迁移时进行SIDHistory过滤,它会擦除SIDHistory属性中的内容。

 

0x05小结

本文主要说明了MS14068的利用方式和金银票据,主要用来提升和维持域内权限,通常情况下需要结合其他的域内攻击方式进行使用,比如获取了域控制器的NTLM HASH等内容时。下一文将介绍关于Kerberos委派相关的攻击手法和实现原理。

 

实验工具

 

参考链接

  • https://adsecurity.org/?p=1640
  • https://adsecurity.org/?p=2011
  • https://www.cnblogs.com/backlion/p/8127868.html
  • https://blogs.msdn.microsoft.com/openspecification/2009/04/24/understanding-microsoft-kerberos-pac-validation/

 

本文由云影实验室原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/172900

安全客 - 有思想的安全新媒体

分享到:微信
+19赞
收藏
云影实验室
分享到:微信

发表评论

内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66