我最初是用QEMU、一个未打包的固件和libnvram的组合来重现这个问题，但这个漏洞毫无价值，因为在移植到真正的思科设备上是偏移是错误的。因此，我在eBay上订购了一台二手设备。

我已经习惯了Cisco设备，所以我想我至少可以通过SSH或控制台电线（cable）在设备上获得一个shell，但是那个该死的RV130没有提供这两个功能:/

为了克服这个问题，我打开了外壳，识别出UART 引脚。从那里，我可以使用一个来自@XipiterSec的基于FTDI32的设备Shikra进行串行连接。

我没有带逻辑分析，所以我通过试错来确定波特率(正确的波特率是38400)。一旦设备启动，你会看到我们想要的东西:根shell:)

如果你阅读Pentest Partner他们的文章，可能注意到这个请求：

第一步是在设备上获得gdbserver并将其附加到正在运行的http服务器。我从Hugsy (GEF的创建者)的repo下载用于ARMv6l的静态链接的gdbserver版本。

现在我们可以使用gdb-multiarch远程连接到gdbserver。我使用下面的GDB init文件使事情更容易:

当您提交样例请求时，您将看到如下所示的segfault。成功!

为了知道需要多少填充来溢出strcpy将复制到的缓冲区，我们将使用gef “pattern create”和“pattern search”。

我们使用下面这个pattern来触发漏洞

我们看到当可执行程序在0x616d6560执行指令时发生了崩溃:

我们现在可以通过搜索我们的pattern来找到偏移量。注意，我搜索的是0x616d6561而不是0x616d6560，因为当最小有效位为偶数时，ARM CPU切换到thumb模式。

现在我们知道，我们的有效载荷需要446位填充来溢出缓冲区和控制程序计数器。

我们的第一次开发将利用“retlibc”。它背后的思想很简单:不需要执行一个ROP链来使堆栈可执行，然后让程序计数器指向堆栈来执行shell代码，我们只需让r0(第一个参数)指向堆栈，然后调用system。
为此，我们需要取得以下信息:

通过现场调试会话很容易获得前两个信息。首先调用vmmap查看内存映射。正如我们在下面的输出中看到的，libc被映射到0x357fb000。

要获得系统的偏移，你可以使用静态radare2:

同时也可以在GDB动态调试：

从GDB得到的值只是函数偏移量(0x0004d144添加到libc的map）
0x357fb000)。
我们得到了系统地址，现在我们需要找到我们的小工具。要做到这一点，我将依靠Ropper。

在我看来，最有趣的是位于0x00041308的那个指令，这意味着我们需要找到一个小工具，把r2从堆栈中取出来。

没什么有趣的，让我们切换到Thumb模式，看看是否有什么事情发生:

现在我们可以使用位于0x00020e79的gadget了。

所以让我们使用python写一个快速可行的利用:

这个利用的思路如下：

当执行gadget2时，堆栈看起来是这样的:

找准RV130很容易，因为libc不会随着版本的不同而改变，这意味着所有的偏移量都是一样的，不管固件版本是什么:

然而，在调整Metasploit模块以支持RV110W和RV215W设备时，我面临着一个非常重复和无聊的任务:为每个固件版本查找偏移量。

因此，我编写了两个利用radare2和Ropper脚本功能的实用程序脚本。

第一个自动从提供的libc文件返回系统地址:

以下是搜索系统的偏移在所有RV110固件版本:

第二个是在一个文件中找到一个特定的gadget偏移量:

用如下指令运行脚本：

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