红队行动中如果能控制目标的exchange服务器就离成功不远了。这两年几乎每隔一段时间都会有新的漏洞出现，包括proxy系列漏洞(CVE-2021-26855 、CVE-2021-34473 )、后台的反序列化漏洞(CVE-2021-42321 、CVE-2022-23277 )等。研究这些漏洞之前我们需要对exchange整体的架构一个大体的了解，本文是笔者在了解exchange运行机制过程的一些简单记录，这篇主要关注exchange ews frontend部分的工作原理。
exchange包括frontEnd和BackEnd两部分，从前端到后端的代理转发过程就是proxy系列漏洞出现的地方：
首先查看iis的全局设置，配置文件为C:\Windows\System32\inetsrv\config\applicationHost.config。
与iis管理器中的对应，可以明显看到网站的物理路径以及应用池：
img
目录下并没有常规的aspx,ashx等文件，主要是一个web.config文件:
img
查看该文件，应用功能主要由这几个module实现：
img
moudle的具体申明在c#模块后门中有提及，主要格式为：
<add name="HostHeaderValidationModule" type="Microsoft.Exchange.HttpUtilities.HostHeaderValidationModule, Microsoft.Exchange.HttpUtilities, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
Name：模块名，任意值都可以
Type：第一个参数为命名空间+类名，第二个参数为dll的名字。PublicKeyToken为签名。
在web.config另一个配置项中的文件SharedWebConfig.config可以找到dll对应的物理路径：
img
img
通过前面的了解，我们得知ews主要使用的应用池为MSExchangeServicesAppPool
<application path="/EWS" applicationPool="MSExchangeServicesAppPool">
<virtualDirectory path="/" physicalPath="C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\EWS" />
几个module对应的dll：
Microsoft.Exchange.HttpUtilities.dll中的HostHeaderValidationModule和AnonymousRequestFilterModule
Microsoft.Exchange.FrontEndHttpProxy.dll中的ProxyModule
使用dnspy将进程挂到MSExchangeServicesAppPool的w3wp.exe进程上
该模块非关键业务逻辑，代码很少
主要判断请求头和ip，如果内网的请求去掉这几个头。
读取服务器配置，判断是否开启AMSI，主要是安全方面的设置。比如基础的xss和sql注入防御。
只看到判断请求类型就返回401，没看到认证相关的逻辑。推测ntlm认证/basic认证的内容应该不在exchange实现，由iis实现。
可以看到ews接口默认支持windows认证：
这是exchange frontend的关键逻辑部分，主要是这几个完成主要逻辑：
OnBeginRequest主要是对请求的一些处理，比如判断SSL等：![1661950375986]
OnAuthenticateRequest主要是用户身份相关的，主要是匿名用户相关的。
OnPostAuthenticateRequest，根据是否认证选择Hanlder:
在stackoverflow上老外过了这么一句侧面说明了Request.IsAuthenticated这个属性由iis决定：
it is valid no matter what type of authentication is being used (Windows, Passport, Forms or our own custom scheme)
根据协议的类型，实例化对应的webhandler：
调用Run函数
Run函数初始化AuthBehavior比较关键，和认证相关：
主要判断的当前的认证方式：
初始化hanlder后调用RemapHandler
该方法调用获取到传入hanlder的type:
通过MgdSetRemapHandler，将web交由此hanlder进行处理
接下来就看ews对应的handler-EwsProxyRequestHandler的业务逻辑，发现其没有普通的handler的ProcessRequest等方法。这里主要是对面对象的理解，有多重的继承关系
最终是ProxyRequestHandler类，继承了一堆接口：
IHttpAsyncHanlder:
启动新线程，调用BeginCalculateTargetBackEnd:
层层调用后进入BeginPorxyRequest，通过GetTargetBackEndServerUrl函数得到后端的uri：
GetTargetBackEndServerUrl主要使用GetTargetBackEndServerUrl函数获取url，增加了一些特殊情况的判断：
GetTargetBackEndServerUrl，获取到444端口上的后端url，这里也是proxy系列漏洞出问题的地方之一。
获取到uri后，使用CreateServerRequest生成对后端的请求：
CreateServerReques增加了一些请求头，PrepareServerRequest函数对请求包进行进一步处理：
PrepareServerRequest增加权限的判断，如果权限足够，生成kerberos认证头，如下
接着调用AddProtocolSpecificHeadersToServerRequest增加特殊的请求头：
CommonAccessToken比较关键，这个token怎么生成我们后面再详细聊。之后对这个CommonAccessToken的判断，若的system或者机器账户会报错。CommonAccessToken肯定包含用户的身份信息。
至此大致的代理请求生成完毕，根据客户端请求判断请求类型，调用BeginGetServerResponse发送：
经过回调最终调用OnResponseReady，主要是拿到异步请求的结果并赋值。
至此我们理解了在用户请求到前端服务器之后，前端服务器代理用户请求到后端的过程。对exchange的运行机制有了简单的理解。总结以下几点：
1. exch都需要经过proxymodule，之后根据协议判断交由hanlder进行处理。
2. 401认证是iis部分实现的，主要是域认证。后续认证及权限控制exch有自己的一套实现。
3. CommonAccessToken、AuthBehavior及kerberos票据对于用户的认证及权限有很大的影响需要重点关注。
ProxyRequestHanlder处，调用FixupCommonAccessToken生成token：
FixupCommonAccessToken最终调用CommonAccessToken，参数为当前用户令牌
可以看到当前身份令牌为Administrator，CommonAccessToken代表邮件用户的身份。
详细的生成流程位于CommonToken类：
在proxylogon的利用中已有生成CommonToken的实现：
GenerateKerberosAuthHeader返回一个string,放入Authorization头：
进入 InitializeForOutboundNegotiate：
生成securityStatus并没有提供账户密码，使用的是AuthIdentity.Default：
继续调用，进入NegotiateSecurityContext，之后进入NegotiateGssapi
NegotiateSecurityContextInternal进行keberos票据生成：
这里没太明白，从proxy系列漏洞来看，前端到后端用的system机器权限。这部分权限确定不由commontoken控制，应该由此kerberos票据生成。参考orange团队的文章https://devco.re/blog/2021/08/06/a-new-attack-surface-on-MS-exchange-part-1-ProxyLogon/中写的一段话：
Then the Backend will verify whether the request is equipped with an extended right called ms-Exch-EPI-Token-Serialization. With the default setting, only Exchange Machine Account would have such authorization. This is also why the Kerberos Ticket generated by the Frontend could pass the checkpoint but you can’t access the Backend directly with a low authorized account.
由此可见这个kerberos票据默认情况应该就是用机器的权限去生成的。
在proxy系列漏洞已经被修复的大背景下，研究frontEnd的应用意义是我们可以自己生成到后端的请求。在控制了exchange的情况下，可以通过反射等技术实现exchange自身的功能，比如放一个aspxshell，该shell实现了一个不需要认证的ews接口。通过此接口可以进行下载邮件、赋权等操作。在没有启动新进程的情况下实现控制目标邮件的效果。
本文写于两个月之前，当时还没有proxyNotShell这个漏洞的信息，最近出现了这个0d的在野利用。推测除了利用的url和proxyshell一样外，增加了其余可控commonAccessToken的地方。具体登漏洞细节放出来后再做分析。