窃取证书的攻击流程及抓包分析

2022-6-17 16:28 2140 0

摘要: 前言 2021年中旬，specterops发布了一项针对域证书服务(adcs)的利用白皮书，文档中提到了19种对adcs服务的利用。本篇主要是分析文中提出的ntlm relay to adcs窃取证书的攻击流程，原理和抓包分析。相关内容 ADCS介 ...

关键词： 请求 adcs 证书 ntlm 服务器服务可以受害攻击者 Challenge

前言

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.webp?
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服务的配置，证书的审核和下发对全域安全有着重要意义。对上述攻击手段的防御，这里给出两点建议