bctf drunk分析

最新推荐文章于 2022-09-27 12:07:47 发布

ling13579

最新推荐文章于 2022-09-27 12:07:47 发布

阅读量1k

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/v_ling_v/article/details/44657657

written by ling

一、找溢出点

下载下来，发现是个exe程序。最开始以为和去年alictf一样，是个windows平台下运行的程序，不过题目中并没有说运行在什么windows操作系统版本。

分析程序，发现漏洞很明显。显然的栈溢出，同时通过该函数还可以进行内存dump。

二、分析程序开启的保护机制：

首先通过查看程序依赖的dll，发现仅仅有kernel32.dll和msvcr100.dll，可以猜出应该是vs2010编译出来的程序，可能各种保护机制的有。

1. 栈cookie

通过看main入口点处的汇编，很明显能发现栈cookie。

Windows下的栈cookie与linux下的大体一样，不过也略有区别。

Windows下的栈cookie 是在数据段的前4个字节有一个__security_cookie，在没有aslr的情况下这个地址是固定的。而压入栈中的cookie是将__security_cookie与当前的ebp异或得到的。

Linux下的栈cookie 值位于线程局部存储区域，通过gs段寄存器访问，虚拟地址不是固定的。而压入栈中的cookie 没有经过ebp异或操作。

2. Safeseh

通过dumpbin /loadconfig命令，可以看到主程序是有she表的，而程序依赖的两个库都是系统库，看了下对应xp系统下的库，发现也是有safeseh的。

3. Aslr

在vista之后系统中如果程序编译时采用了/dynmicbase选项，那么程序将会启用aslr。经过/dynmicbase选项编译的程序pe头中的dllCharacteristics将会设置IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE=0x40。

因为本程序具有内存dump功能，因此可以通过dumm程序导入表中库函数的地址，可以发现每次程序运行库函数的地址是固定的，因此aslr是没有启用的。

而程序的DllCharacteristics为0x8140，是经过了/dynmicbase选项编译的。所以可以断定系统不是vista之后的系统。

4. Dep

根据启动参数的不同，dep的工作状态分为4种：

（1）Optin。

默认仅将dep保护应用与windows系统组件和服务，常用的桌面系统都是用的这个选项。

在vista下经过/NXcompat选项编译过的程序将自动应用dep。

查看pe头中的DllCharacteristics：如果设置了IMAGE_DLLCHARACTERISTICS_NX_COMPAT=0x100，表示程序采用了/NXCOMPAT编译。在vista下这个编译过的程序将自动应用dep。

（2）optout：

为排除列表外的所有程序和服务启用dep。服务器版的操作系统采用这个选项。

（3）alwayson

（4）alwaysoff

这里不确定操作系统版本，因此无法确定dep是否开启。

经过分析，最初以为的保护机制如下：

栈cookie保护，safeseh保护，没有aslr。

Dep保护未知

因为dep不知道，就先假设dep是关掉了的，万一成功了呢。

三、保护机制的绕过：

栈cookie通常通过异常处理she绕过。

Safeseh绕过需要一个类似pop-pop-ret的gadget，而这个gadget不能位于开启了safeseh模块中的。本程序及其依赖的dll都开启了safeseh。在od中查看该程序的内存布局，选择在程序的内存高地址的map区域中找一个pop-pop-ret。

根据上面的思路，构造了如下payload，在本地xp环境下测试成功。

'1111' + '\x90' * 0x48 + '\x90\xeb\x05\x90'+ l32(pop_pop_ret) + shellcode + '\n'

但是攻击服务器时，通过内存dump找了好几个pop-pop-ret，都不行。

因此当时估计是开启了dep，找不到绕过的方法。

四、wine下分析

后来在dump内存中发现了wine的字符串，才知道这是通过wine运行在linux环境下的。因为手上的kali32系统默认安装有wine和ollydbg，于是研究了下这些保护机制在wine中的具体情况。

经过测试，发现在wine下safeseh是不起作用的，同时也没有aslr，但是dep是开启了的。因为safeseh没有开启，所以可以将异常处理的地址覆盖为任意地址。

后来调试发现在到达异常处理函数时，寄存器的值中esi刚好指向我们输入的数据的内存。因此如果能够找到一个类似xchg esi，esp;ret的gadget，将栈转到我们可控的内存区域，就可以构造一个virtualprotect的rop链绕过保护。

然后就是从远程服务器中dump库的内存。写了个脚本利用ROPgadget找可能的gadget。在脚本的输出中人肉找了很久，一直没有找到合适的gadget，将栈转到可控区域。

[html]view plaincopy 
   
 import os  
 filenames =os.listdir('/home/ling/Desktop/dump3')  
 for file in filenames:  
    if 'bin' in file:  
        print file  
        print os.popen('ROPgadget --binary '+file+' --rawArch=x86--rawMode=32').readlines()  