一、前言

在对抗拒绝服务攻击的战争中，应用层的软件和服务变得越来越重要、复杂且相互关联，实现应用程序安全的难度也呈指数级增长。现代软件开发过程的飞速 发展，使得快速、准确地识别风险变得愈发的重要。这种攻击发生时，从监控设备或是防御设备上，往往还未发现任何异常，可能就已经造成服务器的不可用状态发生。应用层的攻击，往往是以获取敏感数据，获取更高的权限，甚至是取以得对服务器的完全控制为目的的。但在这个可用性就是一切的时代，一旦业务不可用会带来巨大的经济损失和风险，常常造成拒绝服务的应用层攻击有，安全配置错误，XML实体注入，反序列化以及使用了有漏洞的组件。

最近，针对某主机进行安全监测时，通过端口扫描发现了其可能存在ms12-020漏洞。该漏洞影响了XP，Vista，7，Server 2003，Server 2008 R2等，其中Server 2008的SP2补丁包是不包含该漏洞的修复的，使用原版系统安装完成后，需要使用windows update服务进行更新，而很多用户可能会忽视这一点，进而开放了有漏洞的服务。

二、漏洞成因

概要

当RDP客户端连接到远程桌面服务的服务器组件时，会在新建的回话中启用登陆及GDI图形子系统。在该会话中，GDI图形子系统依赖RDP特定的驱动程序RdpWD.sys–通过TCP连接传输键盘/鼠标事件的驱动。该渠道同样会创建虚拟通道去配置重定向到其他硬件驱动(磁盘，音频，打印机)-这将允许通过TCP连接传输被请求的数据。

调试定位

1、在测试机上，配置将蓝屏时崩溃信息保存至dump文件：

图一:配置测试机

2、载荷1进行攻击测试：
○攻击导致蓝屏并重启

图二:测试机BSoD

○根据上面配置的目录获取相应的dump文件

图三:获取dump

○配置symbol

图四:配置Symbol

3、windbg分析崩溃原因：
命令：
 !analyze -v
输出：
 termdd!IcaBufferAllocEx+0x42:
 fffff880`0281c722 488b4330 mov rax,qword ptr [rbx+30h]ds:002b:64536553`050a0124=????????????????—>指向错误的堆块

查看调用堆栈：

图五：崩溃时的调用堆栈

由于先入栈在高地址，则调用顺序是从下至上，我们可以整理得到相应的相应的汇编代码：

命令：

uf termdd!IcaBufferAllocEx+0x42
uf RDPWD!StackBufferAllocEx+0x72
uf RDPWD!MCSDetachUserRequest+0x2f
uf RDPWD!NMDetachUserReq+0x18
uf RDPWD!NM_Connect+0xcf
uf RDPWD!SM_Connect+0x15e

整理分析:

RDPWD!SM_Connect
fffff880`0677c562 b9020c0000 mov ecx,0C02h
fffff880`0677c567 498bd4 mov rdx,r12
……
fffff880`0677c59a 488b89b0000000 mov rcx,qword ptr [rcx+0B0h]
fffff880`0677c5a1 e81a090000 call RDPWD!NM_Connect (fffff880`0677cec0)
RDPWD!NM_Connect:
fffff880`0677cec0 4053 push rbx
fffff880`0677cec2 55 push rbp
……
fffff880`0677cf47 7408 je RDPWD!NM_Connect+0x91 (fffff880`0677cf51)
fffff880`0677cf49 488bcb mov rcx,rbx
fffff880`0677cf4c e88f5f0000 call RDPWD!NMDetachUserReq (fffff880`06782ee0)
—>会调用RDPWD!MCSDETACHUSERREQUEST
–>最终走到TERMDD!ICABUFFERALLOCEX+0XBA:CALL TERMDD!ICAFREESTACK (FFFFF880`02821DF0)
–>第一次FREE
fffff880`0677cf51 488b33 mov rsi,qword ptr [rbx]
fffff880`0677cf54 ba01000000 mov edx,1
……
fffff880`0677cf88 7405 je RDPWD!NM_Connect+0xcf (fffff880`0677cf8f)
fffff880`0677cf8a e8515f0000 call RDPWD!NMDetachUserReq (fffff880`06782ee0)
RDPWD!NMDetachUserReq:
fffff880`06782ee0 48895c2408 mov qword ptr [rsp+8],rbx
fffff880`06782ee5 57 push rdi
……
fffff880`067955e6 c744242019000000 mov dword ptr [rsp+20h],19h
fffff880`067955ee e88d020000 call RDPWD!StackBufferAllocEx (fffff880`06795880)
–>第二次free，返回错误的寄存器值
!StackBufferAllocEx:
fffff880`06795880 48895c2408 mov qword ptr [rsp+8],rbx
fffff880`06795885 57 push rdi
……
fffff880`067958e6 488364242000 and qword ptr [rsp+20h],0
fffff880`067958ec ff151e870000 call qword ptr [RDPWD!_imp_IcaBufferAllocEx (fffff880`0679e010)]
termdd!IcaBufferAllocEx:
fffff880`0281c6e0 48895c2408 mov qword ptr [rsp+8],rbx
fffff880`0281c6e5 57 push rdi
……
fffff880`0281c71c 0f848c000000 je termdd!IcaBufferAllocEx+0xce (fffff880`0281c7ae)
fffff880`0281c722 488b4330 mov rax,qword ptr [rbx+30h]—>出错

问题主要出现在RDPWD!NM_Connect函数下，调用了两次RDPWD!NMDetachUserReq函数进行释放堆块，却没有置标志位

Tips:x termdd!* 可以查看termdd模块下的函数

4、对比补丁前后的RDPWD.sys 补丁前版本：6.1.7600.16385
补丁后版本：6.1.7601.18540

IDA下： View–>Open subviews–>Names下查找函数：
○补丁后的NM_Connect函数：

.text:000000000001A2A7 mov ebp, 0FFFFFFFEh ->先置标志位
.text:000000000001A2AC jz short loc_1A2B9
.text:000000000001A2AE mov rcx, rbx ; struct tagNM_HANDLE_DATA
.text:000000000001A2B1 call ?NMDetachUserReq@@YAHPEAUtagNM_HANDLE_DATA@@@Z
—>NMDetachUserReq有两个free函数:termdd!_imp_ExFreePoolWithTag和termdd!IcaFreeStack
—>会先检查标志位再确定是否free，由于这儿置了标志位，则是调用termdd!_imp_ExFreePoolWithTag，避免double free

补丁前后对比（红框）：

图六：代码对比

5、综合分析:
当用户发请求时，会从服务器分配ChannelID和UserID，并用链表保存ConnectInfo
在连接初始化时设定maxChannelIds等于0时，使得在分配ChannelID失败，进入到RDPWD!NM_Connect函数
RDPWD!NM_Connect会进入到NMDetachUserReq丢弃连接，这时会释放ConnectInfo，但是却没有置标志位，具体使用了IcaFreeStack
后面继续有用户请求，但是由于被设定为0，还是会失败，还是会使用IcaFreeStack进行free，造成了double free
之后又引用该堆作为继续分配，导致了Use-After-Free，进而内核的崩溃。

三、攻击载荷分析

客户端MCS连接初始化PDU的典型样例：

图七：初始化数据包单元

根据数据包格式要求构造攻击载荷

1、修正偏移0x158
00 00 00 00 -> TS_UD_CS_CORE::serverSelectedProtocol

2、编码RDP连接请求
03000013 0E E0 0000 0000 00 01 00 0800 00000000

TPKT头部 (长度 = 19字节):
03 -> TPKT: TPKT版本 = 3
00 -> TPKT: 保留 = 0
00 -> TPKT: 报文长度 – 高部位
13 -> TPKT: 报文长度 – 底部位 (总共 = 19 字节)

X.224 数据 TPDU:
0E -> X.224: 长度指示器 = (14 字节)
E0 -> X.224: 类型 = 0xE0 = 连接确认
00 00 -> X.224: 目的引用 = 0
00 00 -> X.224: 源引用 = 0
00 -> X.224: 类和选项 = 0
01 -> RDP协商消息 (TYPE_RDP_NEG_REQ)
00 -> 标志 (0)
08 00 -> RDP_NEG_REQ 长度 (8 字节)
00 00 00 00 -> RDP_NEG_REQ: 选择协议 (PROTOCOL_RDP)

3、附加用户请求PDU
03000008 02f08028

03 00 00 08 -> TPKT头部 (length = 8 字节)
02 f0 80 -> X.224 数据 TPDU (2 字节: 0xf0 = 数据 TPDU, 0x80 = EOT, 传输结束)
28 -> PER 编码 PDU 数据 (选择附件用户请求)

4、数据包下找到 Connect-Initial::targetParameters 头部: 30 19
30 -> ASN.1 BER 编码 SequenceOf 类型.
19 -> 序列数据的长度 (25 bytes)

头部跟随着 DomainParameters::maxChannelIds 信道: 02 01 22
02 -> ASN.1 编码整数型
01 -> 整形长度 (1 字节)
22 -> 实际值为 34 (0x22)

替换原有的 maxChannelIds (0x22) 的值为 0 – 这个字节位于数据包偏移的0x2C的位置。

5、得到的数据包如下 (标注的4个位置对应到4个修改)：

图八：攻击载荷

对于数据包的这些修改都是完全合法的，除了这一点：就是设定targetParameters的maxChannelIds的值为0.这可能是整个数据包中唯一“邪恶”的字节。 实际测试中，发现第3点的附加用户请求PDU，发送一次是无效的，最少要发送两次。

当然，这份数据报文已经上传至CloudShark，点击下面链接即可在线分析数据报文：（用winhex打开，可以帮助分析协议的结构)
ms12_020_termdd.pcap在线解析报文

四、检测与防御

1、检测方式：主要通过扫描
○nmap：
nmap -sV –script=rdp-vuln-ms12-020 -p 3389
○metasploit:
use auxiliary/scanner/rdp/ms12_020_check
set rhosts exploit
○威胁态势感知引擎
帮助发现存在漏洞的主机
2、防御：
○端口—-缓解措施
开启RDP的主机，更换默认端口，一般的扫描都会针对3389端口，由于扫描器配置了大量的脚本，针对单个主机，一个脚本基本上只会扫描一定数量的端口，这对于大多数的扫描器有效；
○补丁
在Mircosoft下找到相应系统版本的更新补丁，下载并安装：补丁下载
○虚拟补丁
对于应用层 的防御，通过开发相应的过滤规则，配置到WAF实现对攻击载荷的过滤；并可以配置可以访问端口的网段。在对于ms12_020的过滤规则上，主要到DomainParameters::maxChannelIds的设定为00时会触发漏洞，而且设置目标主机的最大信道为0也与正常的用户行为不符合。具体实现：
（1）对RDP端口上数据包进行匹配，发现数据流：03000013 0E E0 0000 0000 00 01 00 0800 00000000–>判断为RDP发起–>继续

（2）读取偏移0X2D数据，和00比较，相同则阻止传输该IP后续的报文
○安全的系统镜像
除非用户自主选择安装系统镜像，对于要求安装的常用服务器系统，都会提供并安装已更新到了最新补丁的系统。由于更新会频繁重启或出现兼容性问题，浪费时间并影响业务，构建安全的系统镜像是十分重要的

五、总结

应用程序是人创建和维护的最复杂的系统之一，建立良好的日志记录和监控以及威胁感知系统，可以及时发现主机存在的安全隐患。通过WAF实现虚拟补丁并配合清洗设备和抗D技术，构建从反射放大的流量型攻击，利用TCP协议的Flood攻击，利用真实IP进行容量耗尽的CC攻击以及应用层攻击的全方位的防御体系，并缺一不可。采用多层的解决方案，利用好威胁情报功能和预警系统，并时刻保持警惕对待时刻到来的攻击，维护客户业务的可用性。

引用资料

Luigi Auriemma
MS12-020 Vulnerability for Breakfast
CVE-2012-0002（ms12-020）深度分析报告