以DNS协议中继AD CS为点再谈Kerberos认证

渗透技巧 1年前 (2022) admin

438 0 0

背景

之前的文章介绍过Kerberos认证的基础和攻击面，在这之后James Forshaw提出新的攻击方法——Kerberos中继。由于部分协议可以指定与客户端连接的服务不同的SPN进行Kerberos认证，因此攻击者可以滥用这些协议达到攻击的目的。

01 为什么认为”Kerberos无法中继”

在James发表文章之前，Kerberos被认为无法进行中继，原因在于：

NTLM中继属于中间人攻击，攻击者使用PetitPotam等攻击方法，强迫目标机器向攻击机进行NTLM认证，而当攻击者获取到NTLM认证时，将其转发从而与目标机器进行认证。

但使用同种思路进行Kerberos中继是行不通的，原因在于Kerberos加强了通信前双方身份的认定工作，通过在Authentication Server Request (AS_REQ)中添加服务主体名称(SPN) ，导致最终获取的ST无法用于与其他SS(Service Server)通信，从而阻止中继到与服务主体名称不同的服务。

02 Kerberos中继原理

从上面的原因可以得到，阻止Kerberos中继的原因是AS_REQ中的SPN无法被控制，但如果攻击者可以控制SPN，便可以顺利地中继到任意目标服务器。部分协议可以强制受害者向攻击者进行强制身份认证，并且在进行Kerberos身份认证时允许指定不同的SPN，包括以下：

● IPSec and AuthIP

● MSRPC

● DCOM

● HTTP

● LLMNR

● MDNS

攻击者使用以上协议控制受害者使用指定的SPN进行认证，在受害者拿到ST后会对攻击者进行AP_REQ请求，攻击者提取请求中的ST通过没有设置强制签名的协议进行中继。没有设置强制签名的协议如下：

● LDAP/LDAPS

● HTTP

● SMB

也就是说Kerberos中继关键点在于这两种协议

1. 用于触发受害者客户端身份验证的协议，此协议要求可以指定SPN

2. 身份验证中继到的服务使用的协议，此协议要求不设置强制签名

具体的攻击过程如下：

03 以通过DNS协议中继AD CS认证为例

在此我们将上述所说用于触发受害者客户端身份验证的协议选为DNS，中继到的服务使用的协议选为ADCS的HTTP认证，进行具体的实例分析

● DC IP ：192.168.137.100

● CS IP ：192.168.137.101

● WIN10 IP ：192.168.137.241

● 攻击者 IP ：192.168.137.235

mitm6使用IPV6修改受害者的首选DNS为攻击者的恶意服务器，进而通过Dynamic update使受害者进行强制身份验证：

Krbrelayx.py伪造DNS服务器监听请求并进行中继操作：

得到证书后可以进行认证等操作：

过程中的行为如下：

受害机器向攻击者伪造的DNS服务器发送SOA请求

伪造服务器回复AD CS服务器地址，从而实现控制认证时使用的SPN

受害者尝试进行动态更新

攻击者拒绝并要求受害者进行身份验证

受害者向KDC验证，并且使用了攻击者指定的SPN：cs.m01n.com

认证结束后，受害者发送TKEY 请求并将得到的ST发送给攻击者进行认证

攻击者提取ST并将其发送给AD CS，并与AD CS建立连接

成功申请到证书

04 总结

本篇文章通过DNS中继AD CS介绍了Kerberos中继的原理相关知识，作为微软为Windows为AD域提出的可靠认证方案，Kerberos还有些细节依然有可乘之机。

绿盟科技天元实验室专注于新型实战化攻防对抗技术研究。

研究目标包括：漏洞利用技术、防御绕过技术、攻击隐匿技术、攻击持久化技术等蓝军技术，以及攻击技战术、攻击框架的研究。涵盖Web安全、终端安全、AD安全、云安全等多个技术领域的攻击技术研究，以及工业互联网、车联网等业务场景的攻击技术研究。通过研究攻击对抗技术，从攻击视角提供识别风险的方法和手段，为威胁对抗提供决策支撑。