ASLR/DEP绕过技术概览（学习）

来源：互联网发布：基德新秀数据编辑：程序博客网时间：2024/05/21 09:19

转载：http://cybersword.net/attack/exploit/558.html

1..覆盖返回地址为jmp esp,执行shellcode,当函数返回,返回地址被覆盖为jmpesp，导致执行shellcode

1）对付方法：引入Dep(data ExecutionPrevention 数据执行保护)，堆，栈上的内存页属性为不可执行，执行会出错。

2）Anti-Dep：绕过Dep技术ROP(return oriented programming)，ROP由一系列的 Gadget组成。所谓ROP Gadget，就是一系列以retn结尾的指令。

1））为了使Gadget地址固定，无论什么时候指向的都是我们的命令，引入ASLR（address space layout randomization 地址空间格局随机化），ASLR，使得加载程序时，不适用固定的加载基地址加载，该技术需要操作系统，和程序的双重支持，支持ASLR的程序会在pe头设置属性：

IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE标识表明其支持ASLR。

在VS中可选择：

2））ASLR所影响的部分有

　 1）））模块随即化：OD打开进程-〉查看-〉可执行模块，基地址在系统重启的时候会变化　

　　２）））堆栈随即化，堆栈基地址会变化，进而导致内存中的变量会发生变化

　　３）））PEB/TEB随机化（不用固定的地址去获取ＰＥＢ，ＴＥＢ，用ＦＳ寄存器获取）

3））Ａｎｔｉ－ＡＳＬＲ模块

１）））攻击未时启用的ＡＳＬＲ模块：虽然有映像随机化，但有可能有进程存在未启用ＡＳＬＲ，ＲＯＰ技术要求从固定的地址获得Ｇａｄｇｅｔ，可使用ＯＤ的ＯＬＬＹＦｉｎｄＡｄｄｒ插件查找进程　空间中未启用的ＡＳＬＲ模块

２）））堆喷射技术（ＨｅａｐＳｐｒａｙ技术）：虽然堆栈随机化，但HeapSpray技术将ShellCode布局到0x0C0C0C0C（或者其他指定的地址上，通常这个地址要比较大），并不会受堆栈随机化的影响。其实，HeapSpray中使用ROP绕过DEP的时候，就使用了前面提到的“攻击未启用ASLR的模块”。只是，HeapSpray把ShellCode布局在堆上。

３）））覆盖部分返回地址：虽然模块加载基地址发生变化，但是各模块的入口点地址的低字节不变，只有高位变化

对于地址0×12345678，其中5678部分是固定的，如果存在缓冲区溢出，可以通过memcpy对后两个字节进行覆盖，可以将其设置为0×12340000 ~ 0x1234FFFF中的任意一个值。

如果通过strcpy进行覆盖，因为strcpy会复制末尾的结束符0×00，那么可以将0×12345678覆盖为0×12345600，或者0×12340001 ~ 0x123400FF。

部分返回地址覆盖，可以使得覆盖后的地址相对于基地址的距离是固定的，可以从基地址附近找可以利用的跳转指令。

这种方法的通用性不是很强，因为覆盖返回地址时栈上的Cookie会被破坏。不过具体问题具体分析，为了绕过操作系统的安全保护机制需要考虑各种各样的情况。

４）））ｊａｖａ　Ａｐｐｌｅｔ　Ｓｐｒａｙ：　ｊａｖａ　ａｐｐｌｅｔ中动态申请的内存空间具有可执行属性，可在固定地址上分配滑板指令（如ＮＯＰ）和ｓｈｅｌｌｃｏｄｅ，然后挑转到上面地址执行。和常规的HeapSpray不同，Applet申请空间的上限为100MB，而常规的HeapSpray可以达到1GB。

５）））ｊｕｓｔ　ｉｎ　Ｔｉｍｅ　Ｃｏｍｐｌｉａｔｉｏｎ（ＪＩＴ）即时编译，也就是解释器（如ｐｙｔｈｏｎ解释器），主要思想是将ＡｃｔｉｏｎＳＣＲＩＰＴ代码进行大量ｘｏｒ操作，然后编译成字节码，并且多次更新到ＦＬＡＳＨ　ＶＭ　这样它会建立很多带有恶意ＸＯＲ操作的内存块

vary=(0×11223344^0×44332211^0×4433221);

正常情况下被解释器解释为：

如果非常规的跳转到中间某一个字节开始执行代码，结果就是另一番景象了：

关于JIT的详细介绍，可以参考Pointer Inference and JIT Spraying以及Writing JIT-Spray shellcodefor fun and profit，文章末尾会给出链接。

Pointer Inference and JIT Spraying

Writing JIT-Spray shellcode for fun and profit （中文版）

6.））） Tombkeeper在CanSecWest2013上提出的基于SharedUserData的方法

１））））从Windows NT 4到Windows 8，SharedUserData的位置一直固定在地址0x7ffe0000上。从WRK源代码中nti386.h以及ntamd64.h可以看出：

#define MM_SHARED_USER_DATA_VA 0x7FFE0000

在x86 Windows上，通过Windbg，可以看到：

0:001> dt _KUSER_SHARED_DATASystemCall 0x7ffe0000

ntdll!_KUSER_SHARED_DATA

+0×300 SystemCall : 0x774364f0

0x7ffe0300总是指向KiFastSystemCall

0:001> uf poi(0x7ffe0300)

ntdll!KiFastSystemCall:

774364f08bd4 mov edx,esp

774364f2 0f34 sysenter

774364f4 c3 ret

２））））反汇编NtUserLockWorkStation函数，发现其就是通过7ffe0300进入内核的：

0:001> ufUSER32!NtUserLockWorkStation

USER32!NtUserLockWorkStation:

75f70fadb8e6110000 mov eax,11E6h

75f70fb2 ba0003fe7f mov edx,offset SharedUserData!SystemCallStub (7ffe0300)

75f70fb7 ff12 call dword ptr [edx]

75f70fb9 c3 ret

其中11E6是NtUserLockWorkStation的服务号（ShadowSSDT中0x01E6的服务），通过Xuetr可以看到：

这样，在触发漏洞前合理布局寄存器内容，用函数在系统服务(SSDT / Shadow SSDT)中服务号填充EAX寄存器，然后让EIP跳转到对应的地方去执行，就可以调用指定的函数了。但是也存在很大的局限性：仅仅工作于x86 Windows上；几乎无法调用有参数的函数。

64位Windows系统上0x7ffe0350总是指向函数ntdll!LdrHotPatchRoutine。

HotPatchBuffer结构体的定义如下：

struct HotPatchBuffer {

ULONG NotSoSure01; //& 0×20000000 != 0

ULONG NotSoSure02;

USHORT PatcherNameOffset; // 结构体相对偏移地址

USHORT PatcherNameLen;

USHORT PatcheeNameOffset;

USHORT PatcheeNameLen;

USHORT UnknownNameOffset;

USHORT UnknownNameLen

};

LdrHotPatchRoutine调用方式：

void LdrHotPatchRoutine (struct *HotPatchBuffer);

在触发漏洞前合理布局寄存器内容，合理填充HotPatchBuffer结构体的内容，然后调用LdrHotPatchRoutine。

如果是网页挂马，可以指定从远程地址加载一个DLL文件；

如果已经经过其他方法把DLL打包发送给受害者，执行本地加载DLL即可。

此方法通常需要HeapSpray协助布局内存数据；且需要文件共享服务器存放恶意DLL；只工作于64位系统上的32位应用程序；不适用于Windows 8（已经被修补）。

更多0

0 0