Microsoft Exchange漏洞分析

此篇为漏洞分析，想看漏洞利用可以点这

前言

前一段时间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签名是否开启