Windows错误报告服务曝权限提升漏洞，PoC利用代码已公开
随着概念验证利用代码的公开披露，一个影响微软Windows系统的严重本地权限提升漏洞近日浮出水面。 该漏洞编号为 CVE-2026-20817，存在于 Windows 错误报告服务中。此漏洞允许拥有低级别权限的已认证用户，以完全的 SYSTEM 权限执行任意恶意代码。
随着概念验证利用代码的公开披露，一个影响微软Windows系统的严重本地权限提升漏洞近日浮出水面。
该漏洞编号为 CVE-2026-20817，存在于 Windows 错误报告服务中。此漏洞允许拥有低级别权限的已认证用户，以完全的 SYSTEM 权限执行任意恶意代码。
详细的研究成果及配套的 C++ PoC 利用代码已由安全研究员 @oxfemale（X/Twitter 账号 @bytecodevm）发布在 GitHub 上。此次公开披露突显了 Windows 进程间通信的错误报告机制中存在的一个重大安全缺陷。
该漏洞的核心涉及 高级本地过程调用协议。WER 服务暴露了一个名为 \WindowsErrorReportingService 的特定 ALPC 端口，用于与其他进程进行通信。
根据研究人员的发现，该漏洞具体存在于 SvcElevatedLaunch 方法（标识为方法 0x0D）中。WER 服务完全未能对调用用户的权限进行有效验证。
因此，攻击者可以强制该服务从共享内存块中传入的自定义命令行参数来启动 WerFault.exe。
利用代码执行步骤
要成功触发该漏洞，攻击者遵循以下一系列操作：
由于 WER 服务以高权限级别运行，新生成的进程继承了 SYSTEM 令牌。
该令牌包含危险权限，例如 SeDebugPrivilege（允许调试任何进程）和 SeImpersonatePrivilege（允许模拟任何用户）。虽然它未授予 SeTcbPrivilege 使其能成为操作系统本身的一部分，但所获得的权限仍可提供完整的系统访问权限。
该漏洞影响范围广泛，涉及多种操作系统。包括 2026年1月之前的所有 Windows 10 和 Windows 11 版本，以及运行 Windows Server 2019 和 Windows Server 2022 的企业服务器环境。
微软已在 2026年1月安全更新中正式修复此漏洞。
根据 GitHub 上发布的 PoC，强烈建议各组织和系统管理员立即应用最新的安全补丁以保障其网络安全。
安全团队还应监控其环境中的异常 WerFault.exe 子进程以及不正常的 SYSTEM 令牌行为，以便及时发现潜在的漏洞利用尝试。
关于作者
评论2次
https://github.com/oxfemale/CVE-2026-20817 帮各位老师找了一下github上的地址
### 结论 该漏洞源于WER服务对ALPC端口调用的权限验证缺失，攻击者可通过构造恶意ALPC请求触发`WerFault.exe`进程以SYSTEM权限执行任意命令。核心攻击链依赖未授权的`SvcElevatedLaunch`方法（0x0D），其未对调用者身份及参数进行校验，导致特权提升。建议立即验证xi统状态并部署补丁。 --- ### 分析路径（T00ls方法论） #### **L1 攻击面识别** 1. **目标服务定位**： - WER服务（`WindowsErrorReportingService`）通过ALPC端口暴露功能接口，端口名`\WindowsErrorReportingService`。 - 高危接口：方法0x0D（`SvcElevatedLaunch`）用于启动特权进程，但未验证调用者权限。 2. **攻击入口**： - 攻击者通过ALPC客户端发送恶意请求，利用`SvcElevatedLaunch`将自定义命令行参数注入`WerFault.exe`进程。 3. **权限提升路径**： - `WerFault.exe`由高权限的WER服务启动，继承SYSTEM令牌，允许执行任意代码（如提权、横向移动）。 --- #### **L2 假设与验证** 1. **攻击链假设**： - 攻击者需通过ALPC协议向目标端口发送结构化请求，包含伪造的命令行参数。 - 核心验证点：WER服务是否对`SvcElevatedLaunch`的调用者（如进程标识符、用户权限）进行检查。 2. **漏洞触发条件**： - 通过逆向分析PoC代码，需确认参数传递方式：攻击者通过共享内存块传递伪造的命令行（如`CommandLine`字段）。 - 验证WER服务是否直接将该参数传递给`CreateProcess`等函数，且未过滤特殊字符或路径。 --- #### **L3 边界/异常场景** 1. **边缘条件测试**： - **参数长度限制**：尝试传递超长命令行参数，观察是否触发内存溢出或截断。 - **参数格式验证**：尝试注入`cmd.exe /c calc`等简单命令，确认WER服务是否直接执行。 - **服务状态依赖**：若WER服务未运行，需验证攻击者能否强制启动服务并触发漏洞。 2. **防御绕过场景**： - 若xi统启用了ALPC端口访问控制列表（SDDL），需检查默认配置是否允许低权限进程访问目标端口。 --- #### **L4 防御反推与修复** 1. **漏洞修复逻辑**： - 微软补丁可能在`SvcElevatedLaunch`方法中添加权限检查（如`SeImpersonatePrivilege`或`SeTcbPrivilege`），或验证调用者进程的完整性级别。 - 参数校验：强制过滤命令行参数中的危险路径（如`%SYSTEMROOT%`）或特殊符号（如`&`）。 2. **临时缓解措施**： - 通过`sc config WindowsErrorReporting start= disabled`关闭WER服务（风险：影响错误上报功能）。 - 使用`Windows Defender Application Control`限制`WerFault.exe`的执行参数或启动权限。 --- ### 验证步骤 1. **检查xi统版本**： ``` wmic os get Caption,Version,BuildNumber ``` - 若Build号低于2026年1月补丁基准版本（需微软官方公告确认），则存在风险。 2. **监控ALPC活动**： - 使用`Process Monitor`过滤`Operation:AlpcSendMessage`，观察`WindowsErrorReportingService`端口的请求数据。 3. **PoC验证**： - 编译GitHub发布的PoC代码，尝试触发`WerFault.exe`以SYSTEM权限执行命令（如写入`C:\Windows\System32`目录的文件）。 4. **xi统日志检查**： - 检查`Security`事件日志中的4688事件（进程创建），确认是否存在异常的`WerFault.exe`子进程（父进程应为`WindowsErrorReportingService`）。 --- ### 修复建议 1. **立即部署补丁**： - 安装2026年1月安全更新（需微软官方KB编号），修复ALPC接口的权限验证逻辑。 2. **最小权限原则**： - 禁用非必要用户对`WindowsErrorReportingService`的访问权限（通过`sc sdset`调整SDDL）。 3. **持续监控**： - 配置EDR/HIDS规则，监控`WerFault.exe`的异常行为（如高权限进程启动、未预期的网络连接）。