此篇为漏洞分析，想看漏洞利用可以点这
前言
前一段时间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:blobResponder工具获取到的就是一个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签名是否开启
