MS16-137：LSASS远程拒绝服务漏洞分析
在2016年11月8日，Microsoft发布了Windows身份验证方法（MS16-137）的安全更新，其中包括3个CVE：
虚拟安全模式信息泄露漏洞CVE-2016-7220
本地安全机构子系统的拒绝服务漏洞CVE-2016-7237
Windows NTLM特权提升漏洞CVE-2016-7238
CVE-2016-7237
具体CVE-2016-7237而言，相应的补丁被应用到影响LSASS服务的“lsasrv.dll”上面。
该漏洞影响所有Windows版本（包括32位和64位），并且在修补程序发布的同一天，LaurentGaffié（@PythonResponder）同步提供了更为详细的报告。同时，他还发布了触发该漏洞的概念验证（PoC）代码。
关于更加详细的说明，请访问：
http://g-laurent.blogspot.com.ar/2016/11/ms16-137-lsass-remote-memory-corruption.html
下面是PoC的下载地址：
https://github.com/lgandx/PoC/tree/master/LSASS
通过利用这个PoC，我们发现在Windows Server 2008 R2和Windows 7也存在这个漏洞：
漏洞分析
简而言之，该漏洞被报告为远程拒绝服务，其中崩溃是NULL指针引用所导致的。
当LSASS服务崩溃时，攻击目标将在60秒后自动重新启动，对于生产服务器来说，这是无法忍受的。
下面文字引自该报告：
“这允许攻击者远程分配一个巨大的内存块，用来存放不超过20000字符的消息...”
当攻击目标能够接收如此巨大（具体由“Simple Protected Negotiation”确定）的博文时，攻击者基本上就可以通过“Session Setup Request”数据包，使用SMB1或SMB2来利用这个漏洞。
通过下图可以看出，它的具体大小为0x80808080：
这个尺寸（当然是不怀好意的）将被“NegGetExpectedBufferLength”函数所读取，它是“NegAcceptLsaModeContext”的后继：
如果这个函数的返回值为0x90312（SEC_I_CONTINUE_NEEDED），那么"LsapAllocateLsaHeap"函数就会据此分配一个硕大的内存块。
由于分配的内存块接近4GB，所以可能会失败。
如果分配失败，就为出现NULL指针引用创造了一个必要条件。
代码对比
通过将“lsasrv.dll”的v6.1.7601.23545版本与v6.1.7601.23571版本进行比对，我们可以在“NegpBuildMechListFromCreds”函数中找到CVE-2016-7237的修复代码：
简单来说，修复代码会检查包含指向CRITICAL_SECTION对象的指针的结构指针是否为NULL。
由此看来，修复代码的人对于该漏洞存在一些误解，因为根据LaurentGaffié发布的PoC来看，安全问题不在结构指针中，而是在这个结构指向的CRITICAL_SECTION对象的一个字段中，当分配过大的内存块失败的时候，它就会变成NULL！
所以，NULL指针的检查应该在这里：
能触发Windows 8.1/10中的漏洞吗？
虽然公开的PoC无法在Windows 8.1或Windows 10中触发该漏洞，但研究人员和Microsoft也做出声明，指出这些Windows版本也容易受到攻击。
让我们看看这到底是为什么。
正如我前面所说，“NegGetExpectedBufferLength”函数会从SMB数据包读取这个邪恶的尺寸值。
然后，该函数必须返回0x90312值（SEC_I_CONTINUE_NEEDED），从而造成分配的内存过大而失败。
不幸的是，在最新的Windows版本中，已经在此函数中添加了一个额外的检查，即将这些恶意的尺寸与0xffff（64KB）进行比较。
如果恶意尺寸大于0xffff（64KB），那么这个函数不会返回0x90312值，而是返回0xC00000BB值（STATUS_NOT_SUPPORTED），这样，就不会引起内存分配失败了，所以这个漏洞就不会触发。
另一方面，如果我们使用小于或等于0xffff（64KB）的恶意尺寸，内存分配也不会失败，自然也不会触发该漏洞。
那么，为什么Windows 8.1和Windows 10易受攻击呢？
虽然内存分配失败时会触发这个bug，但这并不意味着分配的内存必须是巨大的，关键在于LSASS服务没有足够的可用内存来进行分配。
实验证明，只要在Windows 7和2008 R2中建立几个SMB连接并发送值为0x1000000（16 MB）的恶意内存尺寸，就会触发这个漏洞。
问题是，对于最新的Windows版本来说，是不会使用这种尺寸的，因为正如我前面所说的，其上限为64KB。
因此，触发这个漏洞的唯一方法应该是在LSASS服务中耗尽其内存。为了达到这个目的，可以这样做：在LSASS认证过程中找出可控制的malloc，并创建大量连接来耗尽其内存，直到“LsapAllocateLsaHeap”函数失败为止。也许，这种内存耗尽方法可以很容易地在本地情况下实现。
结束语
当我理解了公开的PoC对Windows 10无效的原因之后，我突然意识到，发布的这个漏洞补丁根本就不起作用。
令人惊讶的是，公开漏洞利用代码公布至今已经两个多月了，有那么多的Windows用户在使用这个补丁来提供保护，但是根本没有人注意到这个问题。
在2016年11月8日，Microsoft发布了Windows身份验证方法（MS16-137）的安全更新，其中包括3个CVE：
虚拟安全模式信息泄露漏洞CVE-2016-7220
本地安全机构子系统的拒绝服务漏洞CVE-2016-7237
Windows NTLM特权提升漏洞CVE-2016-7238
CVE-2016-7237
具体CVE-2016-7237而言，相应的补丁被应用到影响LSASS服务的“lsasrv.dll”上面。
该漏洞影响所有Windows版本（包括32位和64位），并且在修补程序发布的同一天，LaurentGaffié（@PythonResponder）同步提供了更为详细的报告。同时，他还发布了触发该漏洞的概念验证（PoC）代码。
关于更加详细的说明，请访问：
http://g-laurent.blogspot.com.ar/2016/11/ms16-137-lsass-remote-memory-corruption.html
下面是PoC的下载地址：
https://github.com/lgandx/PoC/tree/master/LSASS
通过利用这个PoC，我们发现在Windows Server 2008 R2和Windows 7也存在这个漏洞：
copyright 无奈人生
漏洞分析
简而言之，该漏洞被报告为远程拒绝服务，其中崩溃是NULL指针引用所导致的。
当LSASS服务崩溃时，攻击目标将在60秒后自动重新启动，对于生产服务器来说，这是无法忍受的。
下面文字引自该报告：
“这允许攻击者远程分配一个巨大的内存块，用来存放不超过20000字符的消息...”
当攻击目标能够接收如此巨大（具体由“Simple Protected Negotiation”确定）的博文时，攻击者基本上就可以通过“Session Setup Request”数据包，使用SMB1或SMB2来利用这个漏洞。
通过下图可以看出，它的具体大小为0x80808080：
这个尺寸（当然是不怀好意的）将被“NegGetExpectedBufferLength”函数所读取，它是“NegAcceptLsaModeContext”的后继：
copyright 无奈人生
如果这个函数的返回值为0x90312（SEC_I_CONTINUE_NEEDED），那么"LsapAllocateLsaHeap"函数就会据此分配一个硕大的内存块。
由于分配的内存块接近4GB，所以可能会失败。
如果分配失败，就为出现NULL指针引用创造了一个必要条件。
代码对比
通过将“lsasrv.dll”的v6.1.7601.23545版本与v6.1.7601.23571版本进行比对，我们可以在“NegpBuildMechListFromCreds”函数中找到CVE-2016-7237的修复代码：
简单来说，修复代码会检查包含指向CRITICAL_SECTION对象的指针的结构指针是否为NULL。
由此看来，修复代码的人对于该漏洞存在一些误解，因为根据LaurentGaffié发布的PoC来看，安全问题不在结构指针中，而是在这个结构指向的CRITICAL_SECTION对象的一个字段中，当分配过大的内存块失败的时候，它就会变成NULL！
www.wnhack.com
所以，NULL指针的检查应该在这里：
能触发Windows 8.1/10中的漏洞吗？
虽然公开的PoC无法在Windows 8.1或Windows 10中触发该漏洞，但研究人员和Microsoft也做出声明，指出这些Windows版本也容易受到攻击。
让我们看看这到底是为什么。
正如我前面所说，“NegGetExpectedBufferLength”函数会从SMB数据包读取这个邪恶的尺寸值。
然后，该函数必须返回0x90312值（SEC_I_CONTINUE_NEEDED），从而造成分配的内存过大而失败。
不幸的是，在最新的Windows版本中，已经在此函数中添加了一个额外的检查，即将这些恶意的尺寸与0xffff（64KB）进行比较。
如果恶意尺寸大于0xffff（64KB），那么这个函数不会返回0x90312值，而是返回0xC00000BB值（STATUS_NOT_SUPPORTED），这样，就不会引起内存分配失败了，所以这个漏洞就不会触发。
另一方面，如果我们使用小于或等于0xffff（64KB）的恶意尺寸，内存分配也不会失败，自然也不会触发该漏洞。
那么，为什么Windows 8.1和Windows 10易受攻击呢？
虽然内存分配失败时会触发这个bug，但这并不意味着分配的内存必须是巨大的，关键在于LSASS服务没有足够的可用内存来进行分配。
实验证明，只要在Windows 7和2008 R2中建立几个SMB连接并发送值为0x1000000（16 MB）的恶意内存尺寸，就会触发这个漏洞。
问题是，对于最新的Windows版本来说，是不会使用这种尺寸的，因为正如我前面所说的，其上限为64KB。
因此，触发这个漏洞的唯一方法应该是在LSASS服务中耗尽其内存。为了达到这个目的，可以这样做：在LSASS认证过程中找出可控制的malloc，并创建大量连接来耗尽其内存，直到“LsapAllocateLsaHeap”函数失败为止。也许，这种内存耗尽方法可以很容易地在本地情况下实现。
结束语
当我理解了公开的PoC对Windows 10无效的原因之后，我突然意识到，发布的这个漏洞补丁根本就不起作用。
令人惊讶的是，公开漏洞利用代码公布至今已经两个多月了，有那么多的Windows用户在使用这个补丁来提供保护，但是根本没有人注意到这个问题。
无奈人生安全网