bctf drunk分析

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

1. import os  
2. filenames =os.listdir('/home/ling/Desktop/dump3')  
3. for file in filenames:  
4.    if 'bin' in file:  
5.        print file  
6.        print os.popen('ROPgadget --binary '+file+' --rawArch=x86--rawMode=32').readlines()  

五、赛后学习

赛后，看了下国外放出来的exp，终于知道了利用的方法。

 

在第一次溢出同时，将0x403000处__secruty_cookie顺带泄露出来，同时将溢出处理函数的地址改写成main。

在程序栈cookie检测失败后，程序进行异常处理，又再次运行到main函数。

而此时__secruty_cookie的值是已经知道了，而此时ebp的值虽然不知道，不过因为没有aslr，通过爆破的方法也是可以得到的。

在拥有了__secruty_cookie和ebp值的情况下，第二次溢出就可以完美绕过栈cookie，变成一个最简单的栈溢出了。

在栈上构造一个int 80的rop链，即可拿下shell。

 

Exp的下载地址：https://rzhou.org/~ricky/bctf2015/drunk/