Microsoft Exchange Server 服务器端请求伪造漏洞（CVE-2026-45504）！
一、漏洞背景
2026年6月，微软发布月度安全更新，其中包含一个针对 Microsoft Exchange Server 的服务器端请求伪造（SSRF）漏洞，编号 CVE-2026-45504。根据 MSRC 公告的简要描述，该漏洞允许攻击者通过特制请求使 Exchange 服务器向内部网络发起未授权的 HTTP 请求。SSRF 在 Exchange 体系中通常扮演着“内网跳板”的角色，一旦被利用，攻击者可绕过边界防护，探测或攻击内部服务，甚至与其它弱点串联形成远程代码执行（RCE）。
由于此刻未找到此漏洞的公开利用代码（PoC），我们的目光更应聚焦于：Exchange 为什么频繁滋生 SSRF？它的代理架构存在哪些天生缺陷？通过复盘经典案例并动手复现一个通用 SSRF，完全可以建立起对这种漏洞的立体认知。
二、从历史漏洞看懂 Exchange SSRF
2.1 Exchange 的前端–后端代理机制
Exchange Server 自 2013 年起将角色划分为“客户端访问服务”（前端）和“邮箱服务”（后端）。所有来自外部的 HTTP 请求（OWA、ECP、EWS、AutoDiscover 等）先由前端的 IIS 接收，再由前端通过 HTTP 代理将请求转发给后端对应的虚拟目录进行处理。这种代理依赖特定的认证与寻址信息，例如：
• X-BEResource：存储在 Cookie 中，用于指明请求应转发到哪个后端服务器及具体路径。 • X-CommonAccessToken：在通过认证后携带用户令牌，实现后端免认证访问。 • Kerberos 互认证：前后端之间默认使用 Kerberos 进行身份验证，防止中间人篡改。
正常流程中，前端只会将请求代理到配置为“伙伴”的邮箱服务器，且地址范围被严格限制。但若某些校验函数存在缺陷，攻击者就可能通过篡改上述字段，让前端将请求发往任意内部目标。
2.2 经典案例：CVE-2021-26855（ProxyLogon）中的 SSRF
最广为人知的 Exchange SSRF 当属 ProxyLogon 链。其 SSRF 原理十分精巧：攻击者构造一个看似请求前端 /owa/auth/x.js 的包，在 Cookie 中嵌入 X-BEResource=Administrator@backend.local/ews/exchange.asmx?X-Rps-CAT=...。
前端在解析该 Cookie 时，误将内部邮箱服务器地址 backend.local 作为后端目标，并组合出指向后端 EWS 的完整路径。同时，因为头部还携带了经特殊方式获取的管理员令牌（或利用预认证绕过），最终前端向后端发出了一个经过高权限认证的任意 EWS 请求。这样，攻击者不仅验证了 SSRF 存在，还直接获得了任意文件写入、邮箱数据导出等能力。
该案例揭示出两个关键点：
• 地址白名单绕过的根源：Cookie 中对后端服务器的校验，往往只依赖字符串包含判断，而非严格的正则限制，导致可通过特殊 FQDN 或 IP 形式绕过。 • SSRF 的杀伤力取决于上下文：Exchange 的 SSRF 一旦进入 EWS、ECP 等内部接口，就等于获得了身份，可完成高度危险的后续操作。
2.3 其它滋生 SSRF 的接口
除代理 Cookie 外，Exchange 的自动发现（AutoDiscover）、脱机通讯簿（OAB）、MAPI over HTTP 等组件也曾暴露出 SSRF 漏洞。它们共同特点是：服务端会根据外部输入的 URL、EMail 地址或服务器名称，向内部发起 HTTP 请求以获取配置或数据。一旦输入过滤不严，http://192.168.1.1/admin 这类地址就可能直接进入后端请求队列。
三、CVE-2026-45504 浅析与攻击面推测
结合微软公告中的寥寥几句，以及 Exchange 历史漏洞的分布，可以合理推测 CVE-2026-45504 极有可能落在上述某个代理或自动发现环节，而且利用路径很可能与某一特制 HTTP 头、Cookie 或 POST 参数有关。其表现形式大概率是：
• 攻击者发送一个精心篡改的请求； • 前端未正确验证目标地址是否属于可信的后端服务器集合； • 服务器以当前计算机账户或服务账户身份，向攻击者指定的内网地址发起 HTTP 请求； • 返回内容可能直接或间接泄漏内部信息，或作为内网横向移动的入口。
当然，这只是在细节未公布前作出的方向性推断，一切仍需以微软官方的技术分析为准。
四、复现环境搭建与通用 SSRF 演示
为了让大家直观地感受 Exchange SSRF 的利用过程，这里我们用一台 Exchange 2016 服务器，再现一个基于前端代理缺陷的 SSRF 验证场景。该复现手法源自已公开的安全研究，仅作教育用途，不代表 CVE-2026-45504 的实际利用。
4.1 环境准备
• 域控制器：Windows Server 2016，域名为 corp.local• Exchange 服务器：Exchange Server 2016 CU23，主机名 EX01，已加入域，安装所有角色• 攻击主机：Kali Linux，安装 Burp Suite 社区版，与 Exchange 服务器网络可达 • 目标内网服务：在 192.168.10.50上启一个简单的 Python HTTP 服务，作为内部仿冒 API，用于观察 SSRF 请求是否到达。
确保 Exchange 的 OWA（https://ex01.corp.local/owa）可从攻击主机正常访问。
4.2 验证 SSRF 的存在——利用 X-BEResource 修改请求
1. 打开 Burp Suite，配置浏览器代理，访问 https://ex01.corp.local/owa/auth/logon.aspx。2. 将请求发送到 Repeater，修改如下：
GET /owa/auth/logon.aspx HTTP/1.1
Host: ex01.corp.local
Cookie: X-BEResource=ex01.corp.local/owa/auth/logon.aspx; ClientId=...
...其它头部保持不变...这是一个正常请求。现在我们将 X-BEResource 修改为指向内网 Python 服务的地址（借助绝对 URI 或者尝试欺骗后端）：
GET /owa/auth/x.js HTTP/1.1
Host: ex01.corp.local
Cookie: X-BEResource=Administrator@192.168.10.50/owa/auth/logon.aspx?; ...3. 如果 Exchange 没有做好白名单校验，它的前端会尝试将请求代理到 http://192.168.10.50/owa/auth/logon.aspx。此时我们在攻击主机的 Python 服务日志中会看到一条来自 Exchange IP 的 GET 请求。
实际测试中，由于令牌机制，未必每次都能成功让后端直接访问外部 HTTP，但观察服务器返回的异常错误（如“服务器无法处理请求”、“内部目标无响应”）或 DNS 解析日志，也能间接证明 SSRF。
4.3 更贴近真实利用的演示——探测内部 EWS 接口
常见的利用目标是让 Exchange 前端去请求自身的后端 EWS 端点，从而获取敏感 XML 数据。构造如下请求（注意，此处沿用 ProxyLogon 公开的 SSRF 验证思路）：
GET /owa/auth/errorfe.aspx HTTP/1.1
Host: ex01.corp.local
Cookie: X-BEResource=Administrator@localhost/ews/exchange.asmx?X-Rps-CAT=; ...发往 /owa/auth/errorfe.aspx 是为了命中前端的某个无需预先认证的路径，同时 Cookie 中指定后端路径为本地 EWS。如果漏洞存在，响应包中会包含 EWS 服务返回的 XML 数据，如 <s:Envelope ...>。
声明：此步复现仅在已获得授权的测试环境中进行，且适用于特定未修补版本，此处仅展示原理。
4.4 后续利用的想象空间
一旦确认 SSRF 可用，攻击者通常会：
• 扫描内网端口，绘制拓扑； • 请求云元数据服务（如 169.254.169.254），窃取凭证；• 结合 EWS 的 CreateItem或GetFolder操作，读写邮箱；• 串联其它反序列化或任意文件写入漏洞实现 RCE。
这也正是每一次 Exchange SSRF 引起广泛关注的根本原因。
五、威胁与修复建议
Exchange 的 SSRF 漏洞之所以高危，是因为它往往让攻击者绕过两层防御——网络边界的入站过滤以及前后端之间的隔离。无论 CVE-2026-45504 的具体细节如何，防御措施都殊途同归：
• 立即应用安全更新：微软已通过 2026 年 6 月补丁修复该漏洞，确保所有 Exchange 服务器安装最新累积更新和安全修补程序。 • 网络层微隔离：将 Exchange 服务器放在独立的安全区域，严格限制其对内网其它资产的访问权限，尤其是元数据服务、数据库和运维管理口。 • 加强输入校验：在 WAF 或反向代理中自定义规则，拒绝含有内网 IP、特殊字符的 Cookie 和头字段，拦截异常的 X-BEResource内容。• 日志与监测：启用 Exchange 详细日志，监测包含 192.168.*、10.*、169.254.*等地址的异常出站请求。• 最小权限原则：Exchange 服务账户的权限应被严格管控，防止 SSRF 被用于域内提权。 注：转载文章来源于网络，版权归原作者或企业所有，侵删！