在2016年12月，FortiGuard Labs发现并报告了Microsoft Windows Server中的WINS Server远程内存损坏漏洞。在2017年6月，微软向FortiGuard实验室答复说：“要修复程序漏洞需要对代码进行全面彻底的检查，WINS所提供的功能会被DNS所取代，微软已经建议客户将其迁移出去。也就是说，由于修复漏洞所需要的工作量，Microsoft不会修补此漏洞。相反，Microsoft是建议用户使用DNS来替换WINS。
此漏洞影响的版本涉及到Windows Server 2008，2012和2016。之所以存在此漏洞是因为在处理格式错误的WINS数据包时会触发远程内存损坏。
在本文中，我想分享一下这个漏洞的一些细节。
漏洞复现
要复现此漏洞，请按照以下步骤操作。
1. 在受影响的Windows Server版本中的“服务器管理器”中安装“WINS服务器”。本文中，我们正在使用的是Windows Server 2016.按照“服务器管理器”的安装向导，然后选中“WINS服务器”选项。请参见图1中的操作。
图1.安装WINS Server服务
2. 打开“控制面板” – >“管理工具” – >“WINS”。然后导航到“WINS” – >“复制伙伴”，右键单击“复制伙伴”，然后选择“新建复制伙伴”。见下图中的操作。
图2.创建WINS复制伙伴
3. 在弹出的对话框中，输入WINS服务器IP地址，然后单击确定。请注意，WINS服务器的IP地址必须是攻击者的主机的IP地址。在我的测试中，IP地址为10.0.0.1。请参见图3中的操作。
图3.输入WINS服务器IP地址
4. 在另一台机器上，如Windows 7 x64（这台主机的IP地址必须是你在步骤3中输入的WINS服务器的IP地址），然后在CLI中运行PoC，如“trigger_poc.py”。发送数据包后，你就可以看到Windows Server 2016上的WINS Server服务会停止工作，或者会使用新的pid自动重新启动进程。你可以继续运行PoC，直到由于远程内存的损坏而导致WINS Server服务完全停止工作。捕获的攻击报文如图4所示。
图4.捕获的攻击报文
漏洞分析
存在此漏洞的根本原因在于Windows Server未正确处理多个挂起的WINS-Replication会话。所以让我们先来看看捕获的数据包。参见图5。
图5.攻击数据包中的数据
当使用复制命令WREPL_REPL_UPDATE2（0x00000005）处理多个（大于 3个）待处理的WINS-Replication会话时，就会触发此漏洞。它导致了“int 29h”，错误代码为0xC0000409。参见图6。
图6.“int 29h”，错误代码为0xC0000409
“int 29h”是在Windows 8或更新版本中发现的新的安全声明。它有许多断言。在这里，断言在伪代码中检查了以下条件：损坏的列表指针。
if (((Entry->Flink)->Blink) != Entry){
mov ecx,3
int 29h
}
当我们建立了多个挂起的WINS-Replication会话时，列表指针将被破坏。根本原因是将同一个缓冲区多次释放到了列表池。请参阅以下代码：
.text:00007FF7F87E35D4 DeallocEnt proc near ; CODE XREF: CommAssocDeallocAssoc+2Ap .text:00007FF7F87E35D4 ; CommAssocDeallocDlg+2Ap .text:00007FF7F87E35D4 ; DATA XREF: ... .text:00007FF7F87E35D4 .text:00007FF7F87E35D4 arg_0 = qword ptr 8 .text:00007FF7F87E35D4 arg_8 = qword ptr 10h .text:00007FF7F87E35D4 arg_10 = qword ptr 18h .text:00007FF7F87E35D4 arg_20 = qword ptr 28h .text:00007FF7F87E35D4 arg_28 = qword ptr 30h .text:00007FF7F87E35D4 .text:00007FF7F87E35D4 mov [rsp+arg_0], rbx .text:00007FF7F87E35D9 mov [rsp+arg_8], rsi .text:00007FF7F87E35DE mov [rsp+arg_10], r8 .text:00007FF7F87E35E3 push rdi .text:00007FF7F87E35E4 sub rsp, 20h .text:00007FF7F87E35E8 mov rbx, r9 .text:00007FF7F87E35EB mov rsi, r8 .text:00007FF7F87E35EE mov rdi, rdx ---> rdi points to the head of the list (rdx, named entry A here) which equals sAssocQueHd global variable .text:00007FF7F87E35F1 mov rcx, r8 ; lpCriticalSection .text:00007FF7F87E35F4 call cs:__imp_EnterCriticalSection .text:00007FF7F87E35FA nop .text:00007FF7F87E35FB inc dword ptr [rbx] .text:00007FF7F87E35FD mov eax, [rbx] .text:00007FF7F87E35FF mov rbx, [rsp+28h+arg_20] ; ---> rbx points to the entry B, which will be deallocated .text:00007FF7F87E3604 mov [rbx+10h], eax .text:00007FF7F87E3607 mov rax, [rdi+8] .text:00007FF7F87E360B cmp [rax], rdi .text:00007FF7F87E360E jz short loc_7FF7F87E3617 .text:00007FF7F87E3610 mov ecx, 3 .text:00007FF7F87E3615 int 29h ; Win8: RtlFailFast(ecx) .text:00007FF7F87E3617 .text:00007FF7F87E3617 loc_7FF7F87E3617: ; CODE XREF: DeallocEnt+3Aj .text:00007FF7F87E3617 mov [rbx], rdi ---> entry B’s Blink points to entry A .text:00007FF7F87E361A mov [rbx+8], rax ---> entry B’s Flink points to entry C .text:00007FF7F87E361E mov [rax], rbx ----> set entry C’s Blink to entry B .text:00007FF7F87E3621 mov [rdi+8], rbx ----> set entry A’s Flink to entry B .text:00007FF7F87E3625 mov rdi, [rsp+28h+arg_28] .text:00007FF7F87E362A cmp dword ptr [rdi], 64h ...
在上面的列表中，Flink指针指向列表中的下一个复习，Blink指针指向列表中的上一个对象。
在PoC中，在会话1,2,3之后发送两个数据包并保持处于挂起状态（用过发送TCP重置数据包这两个会话不会被终止），首先使用B指针调用释放分配函数，例如0x1f11306ff70 。A（ListHead）指针始终等于全局变量sAssocQueHd。分配是在父函数中完成的。所以在B被释放之后，C将不存在于第一个释放列表中。关系如下表所示。
之后用B指针第二次调用释放分配函数，它仍然等于0x1f11306ff70。A（ListHead）等于全局变量sAssocQueHd。所以在B被释放之后，没有添加新的条目。条目关系如下图所示。
你可以清楚地看到, 释放分配函数被调用了两次,B中的列表元素Flink和Blink指向了它们自己。这会导致列表错误。
那么这个deallocate函数将被第三次调用。所以“int 29h”由于列表指针检查被破坏而触发。
if (((Entry->Flink)->Blink) != Entry)
{
mov ecx,3
int 29h
}
在以下函数中处理带有Assoc_Ctx的WREPL_REPL_UPDATE2数据包时，对象指针将会设置为相同的指针：
.text:00007FF7F87E0190 ProcTcpMsg proc near ; CODE XREF: MonTcp+4C5p .text:00007FF7F87E0190 ; DATA XREF: .pdata:00007FF7F88077D4o .text:00007FF7F87E0190 ...... .text:00007FF7F87E0284 loc_7FF7F87E0284: ; CODE XREF: ProcTcpMsg+EDj .text:00007FF7F87E0284 mov ecx, [r15+4] ---> netlong here was obtained from the second packet (Wirehark parses it as "WINS-Replication WREPL_REPL_UPDATE2"), "Assoc_Ctx"="00 00 00 3f". .text:00007FF7F87E0288 call cs:__imp_ntohl .text:00007FF7F87E028E mov esi, eax ---> here esi=0x3f .text:00007FF7F87E0290 mov ecx, [r15+8] ; netlong ...... .text:00007FF7F87E0382 loc_7FF7F87E0382: ; CODE XREF: ProcTcpMsg+1EAj .text:00007FF7F87E0382 lea ecx, [rsi-1] .text:00007FF7F87E0385 mov rax, qword ptr cs:xmmword_7FF7F8804D28 .text:00007FF7F87E038C mov rbx, [rax+rcx*8] ; ---> here rbx = poi(7FF7F8804D28)+0x3e*8, because rcx is obtained from Assoc_Ctx=0x3f -1 .text:00007FF7F87E0390 xor esi, esi
从上面的代码段可以看出，一旦获得了对象指针poi(poi(7FF7F8804D28)+0x3e*8
，最终的目标指针（之前传递给条目B的指针）在第一次调用释放分配函数时是确定的，它被分配了B指针。在第二次和第三次调用释放函数时,最终的目标指针(入口B指针)保持不变。在我的测试中,它是1306 1306 ff70 f1。这将导致内存损坏。
注意：poi是获取地址的值的函数。
总而言之，该漏洞是由于复制命令WREPL_REPL_UPDATE2（这是触发此漏洞的关键）处理多个（> 3）挂起的WINS复制会话所导致的。其结果是相同的列表条目被多次释放，这就导致了远程内存损坏。
漏洞缓解措施
我们鼓励那些易受攻击的Microsoft Windows Server的所有用户立即从WINS服务器进行迁移。另外，针对此漏洞，已经部署了Fortinet IPS解决方案的企业组织已经通过MS.Windows.WINS.Server.Remote.Memory.Corruption签名得到保护。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
