漏洞危害
CVE-2021-26855又名proxylogon，是利用ssrf绕过权限验证，再结合同期Exchange的其他漏洞例如文件写入（CVE-2021-27065）等漏洞进行无权限rce
受害版本
Exchange 2013 Versions < 15.00.1497.012
Exchange 2016 CU18 < 15.01.2106.013
Exchange 2016 CU19 < 15.01.2176.009
Exchange 2019 CU7 < 15.02.0721.013
Exchange 2019 CU8 < 15.02.0792.010
具体过程如下：
1、 通过SSRF漏洞攻击,访问autodiscover.xml泄露LegacyDN信息
2、 在通过LegacyDN, 获取SID
3.、然后通过合法的SID,获取exchange的有效cookie
4.、最后通过有效的cookie,对OABVirtualDirectory对象进行恶意操作，写入一句话木马，达到控制目标的效果.
漏洞复现环境
win2012r2+exchange 2016cu16.iso
漏洞复现
漏洞探测
漏洞探测包：
ssrf原因为请求包中的cookie中X-BEResource，存在漏洞主机会有X-FEServer和X-CalculatedBETarget两个cookie。其中需要X-FEServer的信息进行进一步利用
读取 autodiscover.xml
Autodiscover(自动发现)是自Exchange Server 2007开始推出的一项自动服务，用于自动配置用户在Outlook中邮箱的相关设置，简化用户登陆使用邮箱的流程。如果用户账户是域账户且当前位于域环境中，通过自动发现功能用户无需输入任何凭证信息即可登陆邮箱。
读取对应账户的legacyDN
利用脚本
Tips
有幸在内网实战碰见后端三台负载的exchange存在proxylogon，且由于环境限制纯手工复现一番，这里把出现的坑一一列出：
1、16进制问题
在读取完legacyDn后需要通过legacyDn拼接16进制：\x00\x00\x00\x00\x00\xe4\x04\x00\x00\x09\x04\x00\x00\x09\x04\x00\x00\x00\x00\x00\x00进行发包读取sid，这里python脚本会自动转换，但是手动burp发包的话则需要一个个字节编辑
2、后端负载情况下的FQDN
常见的proxylogon的脚本都会通过读取返回包头中的X-FEServer字段也就是域内主机名，而后在通过请求包的cookie字段X-BEResource对该主机的444端口的接口进行ssrf利用，例如：
X-BEResource: Admin@WIN-DC:444/mapi/emsmdb?MailboxId=f26bc937-b7b3-4402-b890-96c46713e5d5@exchange.lab&a=~1942062522;
实战过程中通过X-FEServer读取的值而后利用ssrf并不能访问，在读取sid的步骤中返回的是500状态码
而后通过试错，利用返回包中的X-CalculatedBETarget的字段值，也就是负载的其中一台exchange域内主机名进行ssrf访问444端口的接口成功
3、读取OAB ID失败
常见的exp在获取ASP.NET_SessionId和msExchEcpCanary之后，再尝试获取OAB ID使用的接口为
/ecp/DDI/DDIService.svc/GetObject?schema=OABVirtualDirectory&msExchEcpCanary=%s&a=~1942062522; ASP.NET_SessionId=%s; msExchEcpCanary=%s
而在上次的实战中，使用该接口返回包中Identity的值一直为null，在渗透测试最后一天的下午又找到一个exp，使用的接口为：
/ecp/DDI/DDIService.svc/GetList?schema=VirtualDirectory&msExchEcpCanary={msExchEcpCanary}&#~1941962754; ASP.NET_SessionId={sessid}; msExchEcpCanary={msExchEcpCanary}
最终成功读取OAB ID，并写入webshell，附上该exp 的链接：https://github.com/hosch3n/ProxyVulns/blob/main/26855.py
4、请求包头缺失
因为特别是从读取sid后的几步，比对了很多exp的，详细的exp能比简易的exp多出3个请求头字段，且都验证有效、必需。
