窃取证书的攻击流程及抓包分析
前言
2021 年中旬,specterops 发布了一项针对域证书服务(adcs)的利用白皮书,文档中提到了 19 种对 adcs 服务的利用。本篇主要是分析文中提出的 ntlm relay to adcs 窃取证书的攻击流程,原理和抓包分析。
相关内容
ADCS 介绍
Active Directory 证书服务(Active Directory Certificate Services,下文简称 ADCS)可以向用户,机构和服务颁发证书,收到证书的个体可以使用证书进行域内的身份认证,本篇中要利用的是 ADCS 配置的 WEB 证书请求服务。
NTLM 认证简介
NTLM 协议是 windows 系统的一项身份认证协议,NTLM 认证是一种 Challenge/Response 验证机制,由三种消息组成:通常称为 type 1(协商),type 2(质询)和 type 3(身份验证)。
认证流程图和简单介绍如下:

用户登录客户端电脑
客户端向服务器发送 type1(协商)消息,它主要包含客户端和服务器请求的功能列表,此消息会指定会话所需的安全特性
服务器使用 type2(质询)进行响应,包含服务器支持和同意的功能列表。更重要的是,这一步会返回服务器生成的 Server Chanllenge 标志和协商的安全特性
客户端用 type 3 消息(身份验证)回复质询。用户接收到步骤 3 中的 challenge 之后,使用用户 hash 与 challenge 进行加密运算得到 response,将 response,username,challenge 发给服务器
服务器拿到 type 3 之后,使用 challenge 和用户 hash 进行加密得到 response2 与 type 3 发来的 response 进行比较,结果一致则认证通过。如果服务器没有用户的哈希,则会把上述消息发送给域控,域控会使用 challenge 和用户哈希加密得到 respons2 发送给服务器,这一步在本文中不做分析
Ntlm 是嵌入式协议,它没有自己的传输依赖项,常见的应用层协议有:HTTP,SMB, HTTP。NTLM 不提供服务器的身份验证,因此 ntlm 认证的应用程序容易受到来自欺骗服务器的攻击,这也是 ntlm relayx 的原因所在。
①网络安全学习路线
②20 份渗透测试电子书
③安全攻防 357 页笔记
④50 份安全攻防面试指南
⑤安全红队渗透工具包
⑥信息收集 80 条搜索语法
⑦100 个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年 CTF 夺旗赛题解析
原理介绍
当攻击者能够获取到某个实体的 ntlm 认证请求,就可以将这份请求转发到攻击者想要访问的服务,并以该实体身份通过身份认证。在本文中,就是通过转发获取到的 ntlm 请求到 adcs 服务上,并为其申请证书,完成身份窃取。当 ntlm 请求的发起方是域控时,则可以获取到域控机器账户的证书,进而使用域控证书完成域认证进行 DCsync,获取域管权限。
让服务器向攻击者发起 ntlm 请求的方案很多,在实战中的利用通常要通过网络环境分析选择,这里只简单介绍两种:
**打印机漏洞:**Windows 的 MS-RPRN 协议用于打印客户机和打印服务器之间的通信,默认情况下是启用的。协议定义的 RpcRemoteFindFirstPrinterChangeNotificationEx()调用创建一个远程更改通知对象,该对象监视对打印机对象的更改,并将更改通知发送到打印客户端。任何经过身份验证的域成员都可以连接到远程服务器的打印服务(spoolsv.exe),并请求对一个新的打印作业进行更新,令其将该通知发送给指定目标。之后它会将立即测试该连接,即向指定目标进行身份验证(攻击者可以选择通过 Kerberos 或 NTLM 进行验证)。另外微软表示这个 bug 是系统设计特点,无需修复。
**SSRF:**在 ssrf 里面如果支持 file 协议,并且 file 协议能加载远程资源的话,使服务器远程加载攻击机上的资源,就能拿到 net-ntlm
更多可以参照https://daiker.gitbook.io/windows-protocol/ntlm-pian/5,这里列举了十多项控制服务器向攻击机发送 ntlm 请求的方案和举例
环境
域控:192.168.1.8 winserver 2012
adcs 服务器:192.168.1.8(一般情况下 adcs 不与域控部署在同一台)
攻击机:192.168.1.13 kali
受害机:192.168.1.14 win7
首先在攻击机上启动 impacket 包中的 ntlmrelay.py

控制受害机向攻击机发起 ntlm 请求(这里笔者偷了个懒,直接使用 netuse 发起,实战中可以使用上文中提到的漏洞),可以看到 kali 已经将请求转发到了 adcs 服务器并获取到了证书

使用 wireshark 抓包分析
可以看到当控制受害机发起 ntlm 请求后,受害机成功和 kali 建立了连接,

在这之后,受害机又一次向 kali 发起了 server challenge 请求,kali 并没有立即响应,而是先建立了与 adcs 服务的 http 连接

在 kali 的第二次 http 请求中,adcs 回复给 kali server chanllenge

kali 在接收到 adcs 返回的 challenge 后,将 challenge 转发给了受害机[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-q3iOnAXr-1655210686838)(https://upload-images.jianshu.io/upload_images/26472780-bbfbc24495508bc1.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
受害机在收到 challenge 后,使用自己的哈希将其加密生成 Net-ntlmv2(即 response)并发送给 kali

在这之后,kali 带着受害机的 Net-ntlmv2,成功请求到 adcs 的 web 服务,这里可以看到响应是 200

到此,整个 ntlm 中继到 adcs 的身份认证完成,接下来 kali 就可以带着受害者的 net-ntlm 去请求证书。笔者在复现漏洞时,看到很多文章提到,将 adcs 的 web 服务配置为 https 可以防止 ntlm 中继攻击,下文将对此做分析。
首先在 adcs 上安装证书注册 web 服务,安装完成后,可以看到域控上 443 端口运行着 adcs 服务,同样先启动 ntlmrelayx

当受害机发起 ntlm 请求后可以看到并没有成功中继到 adcs 的 https 服务上

抓包分析可以看到,kali 接收到了来自受害机的 ntlm 连接

但是当 kali 向 adcs web 发起时,在 tls client hello 后,服务端并没有回复 server hello,而是直接设置 reset=1,断开了连接

经过分析,笔者认为这里断开连接是因为 tls 协议协商失败导致的,这里笔者换到 windwos 物理机(192.168.1.10)再次开启 ntlmrelay

再次发起 ntlm 请求,可以看到成功认证到了 adcs 上

抓包

果然,当使用 tls1.2 向 adcs 发起请求时,adcs 响应了 ntlmrelayx 并建立了连接,由于后续通信都是密文,这里不做一一分析,但是可以看到,当 adcs 使用 https 提供 web 服务时,依然无法防御 ntlm 中继攻击。
总结
adcs 服务在域内可以为用户和机器颁发证书,证书一旦被恶意攻击者截获,攻击者就可以通过证书以受害者的身份访问任意服务,同时,证书默认有效期为 5 年,也就是说倘若管理员未吊销被泄露的证书,攻击者可以通过它使用长期的权限维持,由此可见在域中,adcs 服务的配置,证书的审核和下发对全域安全有着重要意义。对上述攻击手段的防御,这里给出两点建议
非必要情况下,关闭 adcs 的 web 端服务
配置 adcs 的 web 服务为不允许 ntlm 认证
评论