当前位置： 首页 > news >正文

CVE-2021-26855漏洞深度剖析：从SSRF原理到Exchange ProxyLogon实战复现

news 2026/6/24 19:51:54

1. 项目概述：从“永恒之黑”到Exchange的“ProxyLogon”

如果你在2021年初关注过网络安全新闻，一定对“Exchange服务器被大规模攻击”的报道记忆犹新。那段时间，全球数以万计的企业邮件服务器一夜之间沦为黑客的“矿机”或数据窃取的后门，其始作俑者就是被称为“ProxyLogon”的攻击链，而CVE-2021-26855正是这条攻击链上最关键的“敲门砖”。这个漏洞允许攻击者在未经身份验证的情况下，向微软Exchange服务器发送特制的HTTP请求，从而伪装成合法用户，最终实现远程代码执行。它之所以危险，不仅在于其利用门槛相对较低，更在于它直接暴露了企业最核心的通信枢纽。今天，我们就来彻底拆解这个编号为CVE-2021-26855的SSRF（服务器端请求伪造）漏洞，从原理分析到本地复现环境搭建，再到手工利用的每一个细节，让你不仅看懂漏洞报告，更能亲手在可控的靶场中重现攻击过程，深刻理解其危害与防御之道。

2. 漏洞核心原理深度剖析

2.1 漏洞本质：一个被“信任”的SSRF

CVE-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-BEResource=<backend_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-26855（SSRF）并不能直接获取服务器权限。它的威力在于为后续攻击铺平了道路，是“ProxyLogon”攻击链的第一步：

  1. CVE-2021-26855 (SSRF)：攻击者利用此漏洞，以NT AUTHORITY\SYSTEM等高权限身份，通过CAS代理向本地后端服务发送请求。
  2. CVE-2021-26857, 26858, 27065 (反序列化/文件写入)：利用第一步获取的权限和访问能力，攻击者再结合其他几个漏洞（主要涉及Exchange Control Panel (ECP)组件中的不安全反序列化和任意文件写入），将恶意Web Shell（如.aspx文件）写入服务器可访问的Web路径。
  3. 获取控制权：写入的Web Shell允许攻击者在服务器上远程执行命令，从而完全控制Exchange服务器。

因此，分析CVE-2021-26855，必须将其置于这个攻击链的入口位置来理解。它打开了那扇“信任之门”，让后续的所有攻击成为可能。

3. 复现环境搭建与配置

郑重声明：本节所有操作仅限在您个人完全可控的、隔离的实验室环境（如本地虚拟机）中进行。任何对非授权系统的测试均属违法行为。

3.1 环境准备：构建靶场

为了安全地复现该漏洞，我们需要一个包含漏洞版本的Exchange服务器。最便捷的方法是使用预构建的漏洞靶场环境。

方案一：使用Vulhub靶场（推荐）Vulhub是一个开源的漏洞环境集合，提供了docker-compose编排的一键搭建。

  1. 安装Docker与docker-compose：确保你的Linux或Windows WSL2系统已安装最新版Docker和docker-compose。
  2. 获取Vulhub：
    git clone https://github.com/vulhub/vulhub.git cd vulhub/exchange/CVE-2021-26855
  3. 启动环境：
    docker-compose up -d
    这个命令会自动拉取包含Exchange 2019 CU8（受漏洞影响版本）的Docker镜像并启动。启动过程较慢，需要耐心等待数分钟，直到所有服务就绪。

方案二：手动部署Windows Server与Exchange更贴近真实场景，但耗时耗力。

  1. 准备一台Windows Server 2019虚拟机（至少8GB内存，100GB磁盘）。
  2. 安装IIS、 .NET Framework 4.8等必要组件。
  3. 下载并安装Exchange Server 2019 Cumulative Update 8（或受影响的早期版本）。
  4. 配置邮箱数据库和基本服务。

实操心得：对于漏洞学习复现，强烈推荐Vulhub方案。它避免了复杂的Windows环境配置和庞大的Exchange安装过程，能将精力聚焦在漏洞原理和利用上。手动部署更适合需要研究Exchange内部交互或防御绕过的深度场景。

3.2 工具准备：利用脚本与检测工具

我们需要专门的工具来发送构造好的漏洞利用请求。

  1. ProxyLogon漏洞利用脚本：GitHub上有多个开源项目，例如proxylogon.py或集成在ProxyLogon项目中的脚本。这些Python脚本封装了复杂的HTTP请求构造过程。
    git clone https://github.com/Ridter/proxylogon.git cd proxylogon # 查看脚本用法 python proxylogon.py -h
  2. HTTP代理工具 (Burp Suite / Fiddler)：用于拦截、查看和重放HTTP请求，是分析漏洞触发流量细节的必备工具。建议使用Burp Suite Community版。
  3. 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-BEResource=127.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-BEResource=127.0.0.1:44444/mapi/emsmdb/?MailboxId=f26bc937-cf33-4c-8f-8-2e15f565ef5d@exchange.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等文件写入漏洞。由于在靶场中完整复现整个链涉及多个复杂步骤，我们这里描述其核心思想，并使用自动化脚本演示。

核心思想：

  1. 利用CVE-2021-26855的SSRF，以高权限身份访问ECP（Exchange Control Panel）的后端组件。
  2. 通过ECP组件中存在的反序列化漏洞（CVE-2021-26857），上传一个特制的数据，其中包含我们要写入的Web Shell内容（一段恶意的ASPX代码）。
  3. 指定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访问它来验证。

  1. 访问Web Shell：在浏览器中打开https://<靶场IP>/aspnet_client/shell.aspx。一个简单的Web Shell页面通常会有一个输入框让你执行系统命令。
  2. 执行命令：在输入框中尝试输入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 及更高版本的安全更新。

修复操作步骤：

  1. 立即更新：从微软官方渠道下载并安装对应版本的安全更新包。
  2. 运行健康检查脚本：微软发布了名为“Exchange Server Health Checker”的PowerShell脚本，可以检查服务器是否已受攻击、是否存在后门，并验证补丁安装状态。
  3. 扫描IIS日志：使用微软提供的“Microsoft Exchange Server On-Premises Mitigation Tool”或第三方脚本扫描IIS日志，查找与ProxyLogon攻击特征匹配的痕迹。

5.2 临时缓解措施（如果无法立即打补丁）

在无法立即安装更新的极端情况下，可以采取以下缓解措施，但这不能替代正式补丁：

  1. 阻断特定URL路径：在防火墙或反向代理（如IIS URL Rewrite规则）上，阻止对以下路径的访问：
    • /owa/auth/Current/themes/resources
    • /ecp/
    • /owa/
    • /Microsoft-Server-ActiveSync
    • /autodiscover/（注意：这会严重影响正常功能，仅作为应急）
  2. 禁用UM（统一消息）服务：如果不需要，禁用相关服务可以阻断部分利用路径。
  3. 限制出站流量：严格限制Exchange服务器对互联网的访问，仅开放必要的端口（如25， 443， 用于邮件流和更新）。

5.3 长期安全加固建议

  1. 最小权限原则：运行Exchange服务的账户不应具有不必要的权限。定期审查服务账户。
  2. 网络分段：将Exchange服务器置于内部网络区域，仅将客户端访问服务器（CAS）角色暴露给互联网，并通过防火墙严格限制对后端邮箱服务器的访问。
  3. 部署WAF（Web应用防火墙）：在Exchange服务器前端部署WAF，并配置规则拦截已知的ProxyLogon攻击特征。
  4. 启用日志审计与监控：详细记录IIS、Windows安全日志和Exchange审核日志。建立安全监控（SIEM）规则，实时告警异常访问模式（如大量对/owa/auth/的POST请求）。
  5. 定期漏洞扫描与渗透测试：定期对Exchange服务器进行授权的外部漏洞扫描和渗透测试，主动发现潜在风险。

6. 复现过程中的常见问题与排查

在搭建环境和复现漏洞时，你可能会遇到以下问题：

6.1 环境搭建问题

问题1：Vulhub启动Exchange容器失败，提示端口冲突。

  • 原因：Exchange需要占用80、443、25等多个端口，可能与宿主机或其他容器冲突。
  • 解决：检查docker-compose.yml文件中的端口映射（如443:443），修改宿主机端口（如8443:443），并确保后续所有访问都使用修改后的端口。

问题2：访问Exchange OWA页面时，证书不受信任。

  • 原因：Vulhub使用的Exchange镜像是自签名证书。
  • 解决：在浏览器中添加安全例外，或使用curl时加上-k参数忽略证书验证。切勿在生产环境中这样做。

6.2 漏洞检测与利用问题

问题3：使用curl检测漏洞时，始终返回404或跳转到登录页。

  • 原因：
    1. 目标可能已安装补丁，漏洞已修复。
    2. 请求构造不正确，特别是X-BEResource的格式或查询参数有误。
    3. Vulhub环境服务未完全启动成功。
  • 排查：
    1. 确认环境版本是受影响的（如Exchange 2019 CU8）。
    2. 使用Burp Suite抓取脚本发送的成功请求，与自己构造的curl命令进行逐字节对比，特别注意Cookie的格式和空格。
    3. 进入Docker容器，检查Exchange服务（IIS,MSExchange*）是否全部运行正常。

问题4：利用脚本执行成功，但无法访问写入的Web Shell。

  • 原因：
    1. Web Shell写入路径不正确或不可通过Web访问。
    2. IIS应用程序池权限不足，无法执行ASPX脚本。
    3. 杀毒软件或Windows Defender实时保护删除了Web Shell文件。
  • 排查：
    1. 登录到Exchange服务器（或Docker容器内），检查脚本指定的路径下是否存在shell.aspx文件。
    2. 检查该文件的NTFS权限，确保IIS_IUSRS或应用程序池身份有读取和执行权限。
    3. 临时禁用Windows Defender实时监控（仅限靶场环境），然后重新运行利用脚本。

6.3 流量分析与调试技巧

使用Burp Suite进行深度分析：

  1. 将浏览器或curl代理到Burp Suite。
  2. 运行漏洞利用脚本，在Burp的Proxy -> History中查看所有发出的请求。
  3. 重点关注发送到/owa/auth/Current/themes/resources的POST请求，分析其Cookie头和整体结构。
  4. 可以尝试在Burp的Repeater模块中手动修改请求参数，观察不同参数值导致的响应变化，这有助于深入理解漏洞触发条件。

复现像CVE-2021-26855这样的复杂漏洞，最大的收获往往不是最终弹回的那个Shell，而是在搭建环境、调试脚本、分析流量、排查错误这一系列“踩坑”过程中，对漏洞原理、系统架构和攻防思维产生的深刻理解。每一次请求的构造，每一次错误的排查，都在加深你对“信任边界”、“输入验证”和“链式攻击”这些安全核心概念的认识。在可控的环境里亲手“黑”掉一次，远比读十篇分析报告来得有效。

http://www.jsqmd.com/news/1074030/

相关文章：

  • AI编程避坑指南：运行时环境与协议常识才是真硬通货
  • BUUCTF逆向工程入门：虚拟机环境配置与5道经典题目实战解析
  • 进化算法设计高非线性单调布尔函数：编码、适应度与实现
  • OpenMAIC：清华开源多智能体课堂构建范式
  • 变量重命名：提升代码可读性与维护性的核心实践
  • AI API速率限制实战：从429错误到分布式限流架构设计
  • LangChain中不存在AgentSkills？手把手实现可动态管理的技能系统
  • Qwen2.5-14B-Instruct驱动的AI小说创作工作站
  • Wireshark实战：从ARP与ICMP协议分析入门网络故障诊断
  • 基于ThingSpeak TalkBack的物联网设备控制：低成本轮询方案详解
  • Vibe Coding：开发者认知节律的范式重构与工程实践
  • MPC8568E RapidIO门铃与端口写机制详解：寄存器配置与驱动开发实战
  • SELinux安全架构深度解析：从强制访问控制到容器安全实践
  • 从0到1打造可落地的AI Agent：需求锚定、架构选型与生产级实现
  • 非sudo用户如何安全使用Docker：Rootless模式实战指南
  • Mistral Medium 3：面向工业合规的可验证大模型实践
  • AMD 780M + Windows 11：ComfyUI 部署的稳定高效方案
  • LlamaFactory：大模型LoRA微调的工程化标准件
  • MATLAB多项式实战：从系数向量到求根拟合的工程应用
  • Spring Boot敏感词过滤实战：Trie树与AC自动机方案详解
  • Microchip CA-XP套件实战：从零构建硬件安全认证与加密原型
  • SKILLFLOW：构建技能基准与演化框架，实现技术能力量化管理
  • Atmel低功耗PLD的ITD特性与系统级电源管理设计实战
  • 开源音频解密工具：本地化处理QQ音乐加密格式的技术实践
  • Windows下OpenClaw本地AI工作流部署全指南
  • MATLAB调用Java全攻略：环境配置、性能优化与工程实践
  • SeleniumBasic：为VB6/VBA注入现代浏览器自动化能力
  • AI应用安全左移：静态代码分析在AI技能开发中的实践指南
  • WSL2中配置mkcert实现本地HTTPS开发环境搭建指南
  • MATLAB自定义数据提示：从基础原理到高级应用实践