（360 A-TEAM 长期招收高级安全研究人员，APT 攻防人员，请联系 wufangdong@360.net）
n1nty@360 A-TEAM
对网络安全只要稍有关注的话应该早就已经知道这个漏洞了。
CVE-2018-8581 TL;DR
漏洞最早由 ZDI 披露，ZDI 发现的 PoC 里面利用此漏洞实现了接管任意人的收件箱的效果。
原理比较简单，该漏洞实质是由 SSRF （Server-Side Request Forgery：服务器端请求伪造）漏洞和其他安全机制相结合造成的。Exchange 允许任何用户为推送订阅指定所需的 URL，服务器将尝试向这个 URL 发送通知，此行为造成 SSRF 漏洞。且 Exchange 服务器在向指定的 URL 发送通知时，在需要的情况下Exchange 会自动向此 URL 进行 401 身份认证。认证的其中一种方式为NTLM 认证。且因为 Exchange 服务在与目标 URL 进行 401 认证时所使用的默认凭据为 CredentialCache.DefaultCredentials 且相关 Exchange 服务由 SYSTEM 账号或 NETWORK SERVICE 账号启动， 所以攻击者通过利用此 SSRF 漏洞，可以窃取 Exchange 服务器的系统账号凭据并伴随利用 NTLM-RELAY 技术将此凭据重放至 Exchange 服务器的 EWS 接口，从而获得一个高权限的 EWS 会话（所以此漏洞在微软官方的通告里面被描述为 ”Microsoft Exchange Server Elevation of Privilege Vulnerability“）。该高权限的会话允许攻击者在后续访问 EWS 接口时模拟成任何用户，并最终可以接收到任何用户今后所接收到的任何邮件。
补丁
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-8581
微软官方并没有真正推出相应的补丁，而是给出了一个让此漏洞无法再利用的方法：
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa /v DisableLoopbackCheck /f
为了少打一点字，我在后面将这个方法称为 ”补丁“。
DisableLoopbackCheck
此漏洞的本质在于 SSRF，在于 SSRF 时 Exchange 的相关逻辑会自动利用当前 Access Token 中的默认凭据去与远端机器认证。
而这个补丁，修的并不是 SSRF。
微软提供了几种防御 NTLM-RELAY 的方法，其中一种方法就是被 DisableLoopbackCheck 这个注册表值控制着。
在某个版本的 Windows 系统后，所有利用 Windows SSPI 生成的 TYPE3 消息在发送至远端机器前，会被缓存在当前机器的 LSASS 中。随后如果当前机器上的任何服务收到了一个与之前被缓存在 LSASS 中的 TYPE3 完全一样的 TYPE3 消息，则认证将会失败，因为 SSPI 将这种情况视为有人在进行 credential reflection 攻击。
当注册表 key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 下存在 DisableLoopbackCheck 且其值为 1 的时候，这种保护措施就被禁用了（Exchange 默认是这样的），当它不存在或者值为 0 的时候，这种保护措施是被启用的。
通过删除 DisableLoopbackCheck 这个值，我们很明显可以看出来微软这个补丁并没有去解决根本的 SSRF 问题甚至也没有解决 SSRF 时会自动带出凭据的问题，它尝试去做的是阻止你利用这个 SSRF 来进行 NTLM-RELAY。
那么这一点，它做好了吗？
补丁有用
从上面的描述可以知道，补丁尝试防止的是 NTLM-RELAY。
Exchange 是一个包含有多种角色的构架比如 CAS，MAILBOX 等。当你将所有这些角色全都装在了同一台服务器上的时候，补丁是有用的。它并没有防止 SSRF，但是它有效地防止了攻击者通过 EXCHANGE 的 SSRF 来将凭据 NTLM-RELAY 回这台 EXCHANGE 自身来防止了 Elevation of Privilege。
补丁没用
我在一次测试此漏洞的过程中无意中发现， 流量中的 NTLM TYPE1 消息与 TYPE2 消息中所带有的机器名不一样。这说明什么呢？ 说明发起 SSRF 的那台 Exchange 机器，和我们 RELAY 到的带有 EWS 接口的机器不是同一台，出现了跨机器 RELAY 的情况。这种情况下，补丁是无效的。
简单来说，当你没有将 Exchange 构架的各种角色（从目前我的测试结果来看，特别是 CAS 与 MAILBOX 角色）都安装在同一台服务器上，而是分拆到了多台服务器上形成了一个 EXCHANGE 集群的时候（这种情况并不少见），这个补丁对你是没有用的，哪怕你在所有的服务器上都打了这个补丁。（也许还有以别的方法构架起来的 EXCHANGE 集群，其他构架的集群是否受影响，需要你们自己问靠谱的微软员工了）
口说无凭
我搭建了一个测试域 + Exchange 2013 的环境，域名为 TESTEX.COM，其中有以下几台服务器：
DC
域控
MAILBOX
MAILBOX 是一台 Exchange 服务器，上面安装了 MAILBOX 角色。
CAS
CAS 是一台 Exchange 服务器，上面安装了 CAS 角色。CAS 角色的功能，简单理解就是它是所有邮件客户端访问邮件的接口，OWA 与 EWS 等功能全是运行在 CAS 角色上的。
假设攻击者控制了 user3@testex.com 这个邮箱，他要攻击 user1@testex.com，也就是说攻击者要给 user1@testex.com 这个邮箱的收件箱创建一个转发规则，使得 user1@testex.com 这个邮箱以后收到的所有邮件都会转发给 user3@testex.com
没有打补丁时
当 MAILBOX 与 CAS 都没有打补丁时，利用网上公开的 POC 进行攻击后，可以发现 user1@testex.com 的收件箱被设置了发件规则，攻击成功：
打上补丁后
以下两图可以确定，已经成功从两台机器上移除了 DisableLoopbackCheck 那个注册表值。
CAS
MAILBOX
用 PoC 重打一下，结果如下：
成功了，又新加了一条规则，补丁没用。
打完补丁后重启一下？
提心删完注册表后要重启机器补丁才能生效，所以我将 CAS 与 MAILBOX 全重启了，再用 POC 打一下，又新加了一条规则：
最后
补丁到底有用没用，各位自己心里有数了吧，：）
360 A-TEAM 是隶属于 360 企业安全集团旗下的纯技术研究团队。团队主要致力于 Web 渗透，APT 攻防、对抗，前瞻性攻防工具预研。从底层原理、协议层面进行严肃、有深度的技术研究，深入还原攻与防的技术本质。
欢迎有意者加入！
