MINI HTTPD 远程代码执行漏洞分析

一个老漏洞，看到k0shl师傅早些年分析过但是没有写利用手法，于是复现了一下并构造了exp，并在此之上进行了详尽的分析，对于入门来说的话还是挺有学习意义的。

漏洞说明

Name: Ultra Mini HTTPD Stack Buffer Overflow
Module: exploit/windows/http/ultraminihttp_bof
Source code: modules/exploits/windows/http/ultraminihttp_bof.rb
Disclosure date: 2013-07-10
Last modification time: 2020-10-02 17:38:06 +0000
Supported architecture(s): -
Supported platform(s): Windows
Target service / protocol: http, https
Target network port(s): 80, 443, 3000, 8000, 8008, 8080, 8443, 8880, 8888
List of CVEs: CVE-2013-5019

该模块利用了Ultra Mini HTTPD 1.21中基于堆栈的缓冲区溢出，允许远程攻击者通过HTTP请求中的长资源名执行任意代码。此漏洞必须处理应用程序的请求处理程序线程在60秒后被监视器线程终止的问题。为此，它分配一些RWX内存，将负载复制到它并创建另一个线程。完成后，它终止当前线程，这样它就不会崩溃，从而不会使进程崩溃。

下载地址

下载地址最好使用我提供的链接处下载，操作系统不一致debug结果可能会显示不同。
操作系统：Windows XP Home with Service Pack 3 (x86) - CD Retail (English)
漏洞软件：MINI HTTPD
windbg for windows XP:dbg_x86_6.11.1.404.msi
windows XP 激活码：xp-key
python安装包：Python 3.3.4 Download
pip安装：get-pip.py

测试环境

测试环境：Windows XP Home with Service Pack 3 (x86)
调试软件：windbgIDA pro 8.3（宿主机）/ windbg 6.11（虚拟机）

漏洞复现

此漏洞形成的原因是因为Mini HTTPD服务器在接收请求的URL数据时，会将URL拼接成一个路径去尝试读取文件，当没有读取到文件的时候，会拼接成一个Not Found语句输出，在这个过程中，没有对URL的长度进行严格的检查，从而导致在最后拼接的时候发生栈溢出，导致返回地址覆盖从而执行任意代码，下面对此漏洞进行详细分析。
这个漏洞也可以使用MSF进行直接利用，这里我们使用python poc进行分析：

下载minihttpd120.lzh后进行解压（与zip或rar类似），点击运行minihttpd.exe就开启web服务了，访问http://localhost可以看到404 Not Found，说明我们程序正常运行：

接着运行poc，来打崩服务：

可以看到eip=41414141，此刻eip指针已经被覆盖了，我们需要确定一下多长覆盖的eip，使用下面的脚本：

可以看到在F(0x46)处填充就已经crash了：

查看当前栈回溯：

接下我是不断二分法去找什么时候crash的，类似下面的脚本，最后测出在"F"为397时会crash：

crash后windbg显示如下：

可以看到eip=0040260d，在IDA中 .text:0040260D repne scasb
repne scasb这条指令在ZF标志位为0的情况下连续执行scasb操作，也就是连续比较AL寄存器的值和内存当前(E)DI指向的字节值，直到两者相等或者检查完了所有的元素。这个指令常常用于在一个字符串中查找特定的字符。

该指令此处被strcat函数进行调用：

strcat 是C语言中的一个标准库函数，用于字符串的连接。它的原型如下：

• destination：指向要追加的目标字符串，它应该足够大，能够容纳追加后的结果。
• source：指向源字符串，这个字符串会被追加到目标字符串destination的末尾。

返回值是一个指向destination的指针。例如：

执行完上述代码后，dest字符串变为 "Hello World"。使用strcat时，必须要确保目标字符串destination有足够的空间来容纳追加的内容以及末尾的空字符('\0')，否则可能会导致缓冲区溢出的问题。目前这个函数的安全版本是strncat，可以避免这种问题。

strcat(v119, v114);中有两个参数，其中v114的值使用sprintf传进来的：

sprintf(v114, a404NotFound); 中，a404NotFound 是一个字符串，它将被复制到 v114 指向的字符数组中，这个函数并没有触发crash。
画了一个函数调用逻辑图，来让我们更直观的查看触发的逻辑：

![[Pasted image 20240328215311.png]]
程序在接收到数据时会去拼接目标路径并进行打开，如果打开失败就会跳转到失败处理中，在失败处理中，会去执行打印404 not found的操作。
if ( TargetHandle == (HANDLE)-1 ) 这句代码就是在检查 TargetHandle 是否等于错误的 HANDLE 值。如果是，则表明函数调用失败，需要进行错误的处理。
由于文件肯定不存在，所以一定会进入错误处理流程。

进入错误处理流程会执行sprintf函数进行格式化字符串，然后执行strcat函数把字符串附加到另一个字符串末尾，因为strcat函数没有对传入参数进行检查，最后导致了缓冲区溢出，任意代码能够执行。

EXP编写

测试环境

测试环境：Windows XP Home with Service Pack 3 (x86)
调试软件：Immunity Debugger(x86)/mona

操作系统及其他工具下载请查看前文

！！注意！！：下面主要使用的是Python2

使用工具

Python 2.7.1

EXP编写

偏移计算

书接上文，查看系统是否开启DEP，当前系统已默认设置为系统服务开启DEP，如果看到开启了所有程序的话就勾选下面的选项，我们先关闭该选项在无DEP下实现exp，再去实现DEP bypass：

测试payload(python2)：

上篇文章我们使用的是字符串，本文使用的是字节串。
Python3 对应代码：

使用Immunity Debugger附加mini_httpd进程，运行payload，可以看到正在访问非法区域：

这里可以看出我们可以控制EIP，我们使用mona.py插件（这个文件下载后放到python2.7目录下）可以查找覆盖保存的EIP所需要的偏移量，因为EIP是只读寄存器，我们需要覆盖ret的在堆栈中对应的值。
先设置mona，我们可以创建一个1000字节的模板文件用来测试。

在Immunity Debugger中执行下面的指令：

之前的poc我们需要修改，来生成一系列唯一的子字符串组合，用来确定在缓冲区溢出攻击中覆盖了特定内存地址的偏移量。在Immunity Debugger中输入：!mona pattern_create 1000

生成的数据会在Immunity Debugger目录的pattern.txt文件中：

如果直接从Immunity Debugger中进行复制的话，记得确定一下最后复制出来的长度：

我们写一个新的poc：

一旦执行和程序崩溃，我们使用!mona findmsp来查找进程内存中的模式，并计算构建漏洞所需的偏移量。

我们可以在上图中看到，保存的 EIP 在 967 字节后被覆盖，并且：

• ESP (0x00c7dc6c) 表示栈指针寄存器当前的值或地址。
• points at offset 971 表示ESP指向了循环模式中的偏移量971。换句话说，当程序崩溃时，位于循环模式中的第971个字节的位置被加载到了ESP寄存器中，ESP寄存器被覆盖。
• in normal pattern (length 29)

这个29是什么？Immunity Debugger我不怎么会用，直接windbg看一下：

下面标记部分为29字节，这也是我们目前的可控范围：

该buffer的长度为1500，ESP上则有105字节可控;2000也是105，应该是极限了：

1500的寄存器偏移为：

下一步是验证偏移量，使用下面的poc：

运行这个poc，再查看寄存器：

正如我们所看到的，EIP 等于"42424242"(BBBB)；ESP 指向以"CCCC"开头的内存区域，后跟一组 E；ESI 指向包含"DDDD"的内存，后跟一组 A。对于偏移的填充符合我们的预期。

指令构造

操作系统使用的是Windows XP SP3，之前默认开了DEP，我们将这个先关掉。我们构造指令的方法是在EIP覆盖之前将shellcode注入到栈上，然后使用jmp esp的ROP gadget，让指令跳转到shellcode上。
首先，我们需要找到jmp esp：

生成的结果会在jmp.txt文件中：

要构建可靠的漏洞利用，最好在程序本身或者其中一个dll中使用指令，来保证漏洞利用适用于不同的windows版本，minihttpd.exe没有我们需要的gadget，这里我们使用C:\WINDOWS\system32\USER32.dll，地址为0x7e4456f7：

我们修改之前的poc，将此地址放在 EIP 上（由于Intel架构，需要使用小端序），struct.pack('<I', 0x7e4456f7)这行代码表示的意思是将整数0x7e4456f7按照小端字节序（<表示小端字节序，I表示无符号整形数，占4字节）转换为字节流，并在 ESP 上放置一些断点\xcc让指令跳转到esp后停止，来检测我们是否修改成功。

可以看到中断成功：

下一步是将 ESP 指向的向后跳跃的操作码放在内存上。为了获得该操作码，我们将使用Metasm，这是Metasploit-framework中的一个工具。我们知道执行是在 ESP 上，所以缓冲区的开始是 971 字节之前。使用metasm，我们得到 971 字节向后跳转的操作码。

ruby的使用过程中可能出现依赖问题，可以使用rvm来创建独立环境

当前poc为：

接下来使用Immunity Debugger进行调试，在0x7e4456f7下一个断点，来逐步跟踪执行并确定我们跳转的位置。在主界面使用ctrl+G，然后输入0x7e4456f7，F2下断点，接着运行F7(Step into)，我这边用windbg查看的，可以看到在没开启DEP的时候我们顺利跳转到栈上执行命令了：

可以看到，现在我们利用gadget执行esp指向的地址，esp指向的地址已经被我们覆盖为jmp $-971的指令了，所以跳转到一个充满A的区域，但并不是在缓冲区开头，我们用pattern确定一下我们落在了哪里，此处使用msf自带的脚本生成pattern字符串：

修改poc：

我们会跳转到"3Av4"这个地方：

使用mona寻找偏移量：

也可以直接找"3Av4"前面占了多少字节：

我们这里使用631作为shellcode的偏移（其实641也一样的）：

检测坏字符

现在，我们可以使用msf来创建一个shellcode并将其注入漏洞利用中，但首先我们需要找出坏字符（我们不能在缓冲区上使用的字节，因为它们会破坏漏洞利用）。
为了找出坏字符，我们使用!mona bytearray选项。这将在工作文件夹上创建两个文件，一个bytearray.txt包含要进行攻击的数组，另一个bytearray.bin，一个使用!mona compare命令与内存中的数组进行比较的文件。如果内存上的数组与文件上的数组不同，mona会告诉我们是什么字节导致了不同，并且可以在没有这些字节的情况下重新制作数组。一旦从数组中剥离了所有错误字符，mona会告诉我们内存上的数组是“未修改的”。
当我们攻击Web服务器时，我们已经可以排除一些我们知道会破坏url的字符，例如空字节、空格、/符号和?符号。
我们使用命令!mona bytearray -cpb "\x00\x20\x2f\x3f"生成第一个字节数组，在我们的漏洞利用中复制该数组，并在jmp esp上放置断点执行进行调试分析。

!mona bytearray -cpb "\x00\x20\x2f\x3f":
–cpb 参数表示“Create Pattern Bytearray”，它后面跟着的字符串\x00\x20\x2f\x3f是需要排除的字节。

• \x00 通常被排除，因为它是字符串结束符（null byte），它可能会导致基于字符串的函数（如strcpy）提前结束。
• \x20 是空格字符，在某些情况下可能会被用作分隔符，导致输入被拆分。
• \x2f 是正斜杠/，在URL或文件路径中被用作分隔符。
• \x3f 是问号?，在URL中用来标示查询参数的开始。

执行后，我们可以看到EIP等于"45454545"，访问冲突。这是因为某些字符串破坏了我们的缓冲区（正常的话应该是jmp esp），并且覆盖EIP的偏移量已经更改。

0x0e处有截断，前面的0x0d可能是坏字符。

重新生成检测的bytearray：

结果还是和之前相同重复操作几次，把0x0b，0x0a，0x09都去掉，也就是：

现在可以断在jmp esp上面了：

我们也可以使用mona compare验证一下，找到我们0x01的地址：

0x7e4456f7下断点，然后运行：

可以看到unmodified，也就是说我们是正确的。

现在我们创建一个没有错误字符编码的msf的shellcode。目前，我们只执行经典的calc.exe。

• -p windows/exec 选择了 windows/exec 模块，用于在 Windows 系统上执行命令。
• CMD=calc.exe 指定了 shellcode 执行的命令，即启动计算器。
• -b "\x00\x20\x2f\x3f\x0d\x0c\x0b\x0a\x09" 指出了需要排除的坏字符集合。
• -f c 表示输出格式为 C 语言代码。
• --arch x86 确保生成的 shellcode 是针对 x86 架构的。
• --platform windows 指定了目标平台是 Windows。

当前poc如下：

运行构造好的poc，进行逐步调试：

我们可以看到我们处于 shellcode 0xb8a2f2d413 的开头。我们继续执行。如果一切顺利的话会弹出计算器，但我们却遇到了访问违规：

EIP: 0x00c7d94b
ESP: 0x00c7dc70

ESP指向堆栈上EIP下方的内存区域，EIP当前指向堆栈上的指令。因此，如果shellcode执行pop并弹出堆栈中的值，则shellcode本身可能会损坏。为了解决这个问题，我们必须将ESP移动到EIP指向的地址（我们的shellcode所在的地址）上方。我们使用msf的asm来获取对应的指令。
这个实现方法是从ESP中减去1000字节：

也可以使用metasm生成：

我们可以看到生成的指令具有空字节（\x00），因此我们不能使用它。这可以通过使用负值进行添加操作来解决：

我们得到相同的结果，但这次没有空字节。现在，我们将这个指令放在漏洞利用的jmp $-971之前。

还是没有准确落到shellcode上面，手动查一下，shellcode在0x00c7d897：

原本的栈中往低地址处跳的跳转有问题，我们需要调整一下：

其中\0x20是坏字符，需要修改一下poc，offset_shellcode改为641，对应：

完整poc如下：

可以看到已经弹计算器了，我们的exp已经成功利用：

注意！！后来shellcode我换了一个新的，所以文章中的shellcode可能对不上，但是原理是一样的

漏洞利用绕过DEP

前言

在上一篇文章中，我们关闭了（其实是默认关闭）了系统的DEP，本文我们将在开启DEP的系统上绕过DEP保护来实现EXP的编写。
首先开启DEP并重启虚拟机：

此时再运行我们的poc，发现已经无法运行了：

windbg调试一下，发现内存非法访问：

eip=00c7dc6c发生了内存访问冲突，因为DEP不允许我们在堆栈上运行代码，而堆栈正是我们放置和执行代码的地方。当我们激活DEP时，能够执行任意代码的方法是尝试在内存中搜索指向我们想要执行的某些指令的地址（return to libc），然后使用ret指令并将它们链接在堆栈上。构成的指令链就是所谓的 ROP（面向返回的编程）。

构造ROP

使用ROP我们可以尝试创建需要执行的 shellcode，但不确定我们是否能够找到所有必要的指令。幸运的是Windows API 为我们提供了一系列功能，使我们能够将进程堆栈标记为可执行内存，一旦完成，我们将能够在堆栈上执行代码，就好像它是传统的漏洞一样。
根据 Windows 版本的不同，有不同的API功能，最常用的是VirtualAlloc和VirtualProtect。

VirtualAlloc在官方文档中使用语法为：

VirtualAlloc接收的参数是开始预留的内存地址、要预留的内存大小（以字节为单位）、要进行的预留类型以及预留页的内存保护。最后一个参数，如果设置为0x40(PAGE_EXECUTE_READWRITE)，将允许我们在该保留内存区域中执行代码。

VirtualProtect在官方文档中使用语法为：

VirtualProtect接收的参数用于更改保护的地址、要更改的区域的字节大小、所需的保护类型 （0x40） 以及指向将接收区域当前保护值的变量的指针。最后一个值必须是一个正确的变量，如果它为null或不存在的变量，则调用将失败。

我们在Immunity Debugger中运行!mona rop，来查找可利用的rop指令：
生成的结果保存在了rop.txt、rop_chains.txt、rop_suggestions.txt、stackpivot.txt文件中。

在rop_chains.txt文件中，mona尝试生成一串指令来调用Virtualalloc 或Virtualprotect函数，并将堆栈标记为可执行，以便执行我们的shellcode。这串指令在 Python、Ruby 或 Javascript 中以函数的形式呈现，以便能够直接插入到我们的漏洞中。
这是mona创建的函数，用于从python中调用Virtualalloc：

但是这里面包含了坏字符，我们需要进行排除：

运行mona rop后，rop_chains.txt文件我们将看到无法生成字符串，因为没有指令可以生成没有坏字符的字符串。
默认情况下，当 mona 搜索 ROP 字符串时，它会丢弃操作系统自己的模块来查找gadget。在本例中，我们将强制 mona使用其他模块来查看是否能找到任何有效的字符串。直接在全部模块找可利用的Virtualalloc ROP：

这一次在rop_chains.txt中，我们发现了以下内容：

现在，我们有一个有效的漏洞利用指令链，它将执行VirtualAlloc来更改进程堆栈的状态，并允许我们在其上执行代码。
在我们之前的漏洞利用中，我们使用从USER32.dll获取的地址来执行jmp esp，该地址是为了执行ESP指向的代码。由于我们现在在ESP中拥有的不是代码，而是指向代码的指针，因此我们需要将该地址更改为ret。ret语句的作用是从堆栈顶部获取值并将其放入EIP（指向指令的指针）中。

生成rop.txt：

从rop.txt文件中，我们可以找到可利用的# POP ECX # RETN这种gadget，我们使用这一条：

这条指令的含义为：
POP ECX：将从堆栈中弹出栈顶的值并将其存储在 ECX 寄存器中。
RETN：弹出栈顶的值输入到EIP中，执行EIP。

计算跳转到shellcode的偏移（最好用$+0x28）：

可以看到已经可以正常弹出计算器了：

参考链接

https://whereisk0shl.top/post/2016-10-24
https://www.infosecmatter.com/metasploit-module-library/?mm=exploit/windows/ftp/absolute_ftp_list_bof
Windows Shellcode学习笔记——利用VirtualAlloc绕过DEP
dep-bypass-mini-httpd-server-1-2

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！