能修复自己的RouterOS漏洞指的是什么
能修复自己的RouterOS漏洞指的是什么,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
创新互联公司长期为上千余家客户提供的网站建设服务,团队从业经验10年,关注不同地域、不同群体,并针对不同对象提供差异化的产品和服务;打造开放共赢平台,与合作伙伴共同营造健康的互联网生态环境。为天峻企业提供专业的成都网站设计、网站制作,天峻网站改版等技术服务。拥有十载丰富建站经验和众多成功案例,为您定制开发。
2018年10月7日,来自全球知名高科技网络安全公司Tenable的安全研究人员Jacob Baines针对CVE-2018-14847[2]发布了一段新的概念验证(PoC)代码[1],实现了在受漏洞影响的MikroTik路由器上的远程代码执行。我们第一时间对PoC进行了研究,目前我们对漏洞利用的部分改进已经合入了Tenable的Github仓库[7]。本文将对CVE-2018-14847目录穿越漏洞成因进行分析,同时阐述我们的一些发现,如何通过受此漏洞影响的Winbox指令进行任意文件上传,从而实现一些更有趣的利用方式。我们能够利用CVE-2018-14847在RouterOS 6.42中触发后门shell,或在其他漏洞的配合下,通过在LD_LIBRARY_PATH中注入动态链接库的方法,对存在漏洞的可执行文件进行热补丁修复。我们还将在文中介绍一种“修改”只读文件系统修复漏洞的方法。
漏洞分析
环境简介
MikroTik RouterOS是一个基于Linux开发的网络设备操作系统,兼容x86、ARM、MIPS等多种CPU架构,因此RouterOS也可以安装在PC上将其作为软路由,提供防火墙、VPN、无线网络等多种功能与服务。
RouterOS提供了多种途径对其进行管理与配置,包括SSH、Telnet、Web界面(Webfig)与客户端软件(Winbox)等。本文讨论的漏洞,位于RouterOS与客户端软件Winbox通信过程中所使用的Winbox私有协议中。
RouterOS官网提供了针对多种CPU架构的ISO安装镜像,我们下载6.41.3版本的ISO镜像并安装一个虚拟机。
在虚拟机中配置好IP等基本设置后,我们对各个配置项进行探索,可以总结出一些基本认知。
1. RouterOS可以通过Web(80端口)、SSH(22端口)、Winbox(8291端口)、Telnet(23端口)进行远程访问,使用相同的用户名与密码进行身份验证。
2. 命令行方式访问(SSH、Telnet)会登录到一个厂商定制的shell界面,只能运行厂商实现的管理功能,无法运行Linux命令。
3. 通过Webfig途径登录后,与服务器的交互全部通过一个名为master-min-xxxxx.js的脚本进行加密传输。这个加密协议我们下文将称之为JSProxy。
4. Webfig与Winbox途径提供的配置选项几乎完全相同,根据Tenable与Talos等前人的研究,二者在传输层的编码方式上有些许差异,但在应用层的指令编号、指令参数等保持一致。
协议分析
在上节我们提到,使用GUI管理RouterOS的两个方式Webfig网页端与Winbox客户端,分别采用JSProxy与Winbox协议与RouterOS进行通信,下面我们将分别分析两种协议的通信格式。
在JSProxy通信过程中,浏览器与服务器通信采用变种的MS-CHAP-2方式生成会话密钥,并用于全程的数据加解密,在此我们不作深入讲解,通过JSProxy我们能够略窥RouterOS控制所需要的指令格式与指令映射关系。
对JSProxy的payload进行解密后,我们得到一条条JSON编码的数据。基本格式如下:
JSON数据中的每个键值对包含了三种信息:字段类型、字段名、字段值。JSON键的第一个字母(上图蓝色部分)代表字段类型,包括字符串、整型、布尔值、数组等。JSON键的剩下6个十六进制位(上图红色部分)代表字段名,通常是一个编号,表示数据值的含义,我们下文称之为key ID。JSON值(上图黄色部分)就是这个字段的数据值。
到这里我们可以了解到,RouterOS管理页面的通信方式是通过键值对的请求与回复实现的,键值对的编码方式在JSProxy与Winbox中不尽相同,但数据含义是相同的。我们对 master-min-xxxxx.js进行分析,一个好消息是,我们可以在其中找到所有keyID。
而Winbox协议的二进制编码格式,我们可以从Winbox客户端中分析得到。我们寻找到了一个关键函数,功能是将Winbox消息转换成字符串进行日志输出,四舍五入等于开源了。
Winbox协议二进制格式的大致格式分为6字节的消息头,与依次紧密排列的键值对,大于255字节的消息会插入两字节的长度数据作为消息分片。
其中键值都是以小端序传输,同样采取类似“数据类型-键-值”的格式。
借助Cisco Talos实验室开源的Winbox协议Wireshark解析插件[9]。我们能非常直观的看到数据中各个字段与原始数据的对应关系。
当然这个插件还有一些不足之处,无法解析所有类型的数据包,但对于我们,能够对数据包进行过滤和简单查看一下对应关系就足够了。
关键漏洞:目录穿越、任意文件读写(CVE-2018-14847)
CVE-2018-14847漏洞发生在漏洞上传的位置。我们如何知道文件上传指令发给谁,文件由谁接收,保存到哪里呢?我们需要先定位哪个程序在RouterOS上负责接收用户上传的文件。
从Winbox消息中,我们注意到不同指令会发送给不同的目的组件,从JSProxy中我们能够得知这个目的地位于SYS_TO字段对应的字段中。这个字段是两个int32组成的数组,第一个数字对应了系统中的一个程序,第二个数字对应了这个程序的第几个功能。Tenable对系统中保存了这个对应关系的数据文件/nova/etc/loader/system.x3进行了分析,并制作了一个名为parse_x3的小工具,我们可以在Tenable的Github仓库中的parse_x3目录找到。
根据这个对应关系,结合抓包我们能够得知,文件上传请求的SYS_TO值为{0x02,0x02},对应的二进制文件位于/nova/bin/mproxy。
我们从RouterOS的ISO文件中提取出对应的二进制文件。文件位于mikrotik-6.41.3.iso\system-6.41.3.npk\nova\bin\mproxy,直接用7-zip打开iso和里面的npk,拖出来即可(很多地方其实用不着binwalk)。
在对mproxy进行分析的过程中,Tenable通过功能(handler)实现对应的基类nv::Handler找到了每个程序里面的所有功能的所有编号,并编写了一个Binary Ninja脚本寻找程序中的所有handler,从而快速定位功能对应的函数,这个小工具位于Github仓库中的find_handlers目录中,有兴趣的同学可以尝试一下。
我们尝试找一个简单点的方法,从另外一个角度定位对应的函数。我们在Winbox客户端中正常上传一个文件,并寻找上传的文件所在的路径。当然,假如现在是黑盒测试的话,我们可以用其他的方法获得文件系统的访问权,例如利用其他漏洞进行提权、直接修改文件系统植入shell等等。我注意到文件系统根目录下有很多的符号链接,其中有一些链接到可写目录中,所以我在这里用find -follow跟随符号链接确保我们能够定位到文件的所有可能的路径。
通过这种方法获得的路径,与mproxy程序中出现的字符串进行交叉比对,我们可以得到结论:mproxy程序中,某个负责文件上传的函数能够上传文件至/var/pckg目录中。
再通过这个字符串的交叉引用,我们就能够定位到我们所需的关键函数,我们命名为ked_handler。
对这个函数进行分析,我们可以得出ked_handler函数大致有7个功能,以传入的第5个参数进行选择,有以下7个取值(以IDA伪代码中出现顺序排序):
l 功能1:在/var/pckg目录下创建文件,返回一个用于写入数据的session
l 功能3:打开/var/pckg目录下的一个文件,返回一个用于读取数据的session
l 功能7:打开/home/web/webcfg目录下的一个文件,返回一个用于读取数据的session
l 功能2:向一个打开文件的session写入数据
l 功能4:从一个打开文件的session读取数据
l 功能5:中止一个session并删除先前写入的文件
l 功能6:在/var/pckg目录下新建一个目录
通过对抓包数据进行分析,我们发现官方客户端在读取并下载文件时调用的是3号功能,而Tenable的poc调用的是7号功能。
与这两个功能相关的部分逻辑如下。
其中,tokenize函数对传入的字符串按 / 字符进行切分,返回一个字符串数组。ked_check_path函数采用类似状态机的方式有限制的允许“..”字符串,不允许穿越到父目录中。但函数中没有对“.”(即,当前目录)进行验证,所以我们可以构造类似“/./../”的payload,让函数误以为我们进入1级子目录后返回了当前目录,但实际我们进入了父目录,成功实现目录穿越。ked_check_path这个函数可以说是搬起石头砸了自己的脚。
通过伪代码我们能看到这三个功能都没有对输入参数进行正确过滤,应该存在相同的目录穿越漏洞。这两个命令理论上都能利用来进行任意写入,实际情况呢?
关键点在权限上,对ked_handler进行调用回溯,我们能够定位到mproxy的main函数中,向eventloop注册handler的代码片段。在添加handler前,程序调用了set_policy对7个命令进行了某种设置,据Tenable的深入研究,这几条函数调用与handler中相关功能的调用权限相关。第三个参数为0的时候,代表调用此功能无需登录。由以上代码可知,功能命令4、5、7的调用无须登录。
到这里,我们已经实现了对系统根目录的任意文件读写。
关键漏洞:开发者后门(Tenable exp: bytheway)
下一个问题,有了权限,我们能做什么呢?当然是Getshell了!我们前面提到,即使我们有管理员账号密码,ssh登录进去依然是一个功能受限的shell,不能执行Linux指令。Tenable在报告中提出了一种利用厂商开发者后门进行提权的方法。这个后门与上文提到的目录穿越漏洞,在RouterOS 6.42.1与6.40.8版本一并得到修复。
这个漏洞存在于ssh和telnet登录时运行的/nova/bin/login中。命令行登陆时,程序先正常向用户请求输入用户名和密码,然后根据两个判断条件:用户名是否等于devel、hasOptionPackage返回是否为非0值,如果都符合则进入下一个代码块。
其中,hasOptionPackage函数位于/lib/libumsg.so中,它的取值依据为/pckg/option文件是否存在。
确认用户名与OptionPackage后,程序将用户名重置为admin,并设置一个标志位,指示后门的激活状态。
处理一部分其他逻辑之后,程序再次检查这个标志位,如果后门激活,则将shell运行的实际命令设置为bash。根据PATH环境变量的设置,最后命中并执行文件系统中名为/bin/bash(实际是一个busybox)的交互式命令行。
这个后门的触发逻辑在RouterOS的不同版本中略有不同。根据Tenable的研究,在RouterOS 6.40.9以下版本中,依据的文件是/flash/nova/etc/devel-login,在6.41.1以下版本中,判断的是/pckg/option,在6.42以上版本中,对/pckg/option文件类型做了额外的验证,但依然能够通过修改文件系统的方式进行触发。
利用方式总结
根据上面的两个漏洞的细节,我们已经可以总结出整个漏洞利用的过程:
1. 构造payload,调用功能7,打开/flash/rw/store/user.dat文件,获得session id。
2. 调用功能4,用这个session id读取文件内容。
3. 用其他工具解密管理员账户的明文密码。
4. 调用{0x0d,0x04}号handler进行Winbox管理员登录(模拟Winbox客户端登录,协议细节不再赘述),获得管理员权限session id。
5. 调用功能1,用管理员session在/pckg/option创建空文件。
6. 用管理员明文密码登录ssh/telnet,获得root shell。
整个的利用过程已经被Tenable总结出了一个漏洞利用程序bytheway,在他们的Github中可以找到。
漏洞复现
我们在这里使用的是基于Tenable的bytheway进行修改后的exploit。
交互过程如下:
根据RouterOS版本不同,触发后门需要的文件也不同,因此exploit里面将两个文件都创建了,尽量兼容更多的版本。
One More Thing
漏洞复现了就结束了?NO。我们在公网上部署了多台测试环境对RouterOS漏洞的利用行为进行捕获,从攻和守两个角度都有一些新的发现。我们接下来将介绍一个帮我们“修复”漏洞的好心攻击者与我们对其修复方法的复现,还有我们发现的另一种漏洞利用方法,同时介绍如何利用这种方法反过来修复这个漏洞。
“删除”只读rootfs系统文件
挖矿、蠕虫、僵尸网络等攻击行为不再多说,都是常规操作。在其中一个设备上,我们发现了一个好心的攻击者帮助我们“修复”了后门shell。具体表现是,“修复”后的设备能够通过ssh登录管理界面,也能通过exp触发后门,但却无法登录devel用户,输入正确的密码后却被断开连接。估计是某个病毒的作者想要防止其他攻击者利用这个漏洞,所以好心帮我们“修复”了。可以说是滑天下之大稽。
通过对设备文件系统的分析和虚拟机上的复现,我们猜测这个设备上的/bin/bash文件被“删掉”了。但问题是,PATH变量是硬编码的不可能修改,而/bin目录所在的根文件系统是只读挂载的squashfs,所以删除系统文件是怎么实现的呢?
前面我提到了特殊意义的“删掉”,是因为我们重新分析线上环境的文件系统时,发现/bin/bash并没有被删,所以下面的这种漏洞“修复”方式仅是我们能够复现的一种猜想。
首先我们想知道,在系统目录中有哪些是可写入的。
我们选择/ram,并用随便一种方式上传一个完整版busybox进去(因为RouterOS自带的mount进行bindmount时会报错)。随后,在可写目录中新建bin文件夹并将/bin目录中的内容复制进去,并用mount将新目录挂载到/bin目录之上,实现“覆盖”的效果。由下图可见,我们断开连接后再次登录,就会在登录成功后马上断开,提示消息为Connection Closed而不是漏洞修复后提示的Permission denied。
用这种方式实现的修改,并没有真实写入文件系统,在重启之后,后门依然可以访问。病毒作者可以说是用心良苦哇。
这个思路同样可以用于一些敏感的生产环境系统,很多嵌入式设备都采用squashfs或者其他用于Flash芯片的只读文件系统,如果对可用性有较高的要求,不能接受重启、系统升级带来的服务中断的话,可以用类似的目录挂载方式对系统进行热修复。
CVE-2018-14847的其他用途
在对CVE-2018-14847漏洞进行分析的时候,我产生了一个疑问。既然功能1、3、7共享这个目录穿越漏洞,那理论上我们可以在未授权的情况下向系统任意目录写入任意文件。也许我们不需要开发者后门,也可以实现远程代码执行。
我尝试利用Tenable的协议库winbox_message.hpp编写一些poc,利用ked_handler中功能1提供的session写入文件,在可写的路径上传busybox。但服务器对上传的功能2指令没有任何响应。通过对Winbox客户端上传功能的分析,我发现Tenable的协议库中对长度大于256字节的message处理有一些小bug。
下图以一个文件上传数据包内容为例,以全0数据方便我们观察原始数据格式。方框部分就是Tenable协议库遗漏的部分,我们在winbox_session.cpp中,在每个消息分片之前加入分片长度值与截断标记,修复后的数据包就和Winbox客户端发送的协议格式完全相同了。
进行修复以后,调用mproxy的功能2能够正常上传文件到指定位置,在修复之前,因为其他header的存在,最多只能上传209字节的文件,更大的文件请求就会因为消息分片格式的问题被mproxy丢弃。这个patch我们也提交到了Github上。现在,我们打开了另一扇大门。
不依赖开发者后门的漏洞利用方法
最开始我的设想,直接利用上传功能覆盖一个系统可执行文件,并触发对应的功能。但后来发现有两个难点。一是从未授权用户的角度来看,能够调用的程序就那么几个,/nova/bin/login与mproxy、telnet和ssh服务器等,这些程序所在的挂载点都是只读的,root用户也无法覆盖。二是通过功能2创建的文件默认权限都是644,即可读可写不可执行,即使传上去了也会因为权限问题无法启动。
不过对RouterOS有了更多的了解后,我有了一个设想。查看shell登录以后的环境变量:
我们发现,LD_LIBRARY_PATH中包含了多个目录,/lib在根文件系统下,是只读的。/pckg是一个指向/ram/pckg的符号链接,/pckg/security/lib与/pckg/user-manager/lib只在安装了对应的可选包才会出现,也都是只读的。/rw是一个指向/flash/rw的符号链接,这个目录是可写的。虽然/rw/lib目录在默认配置下不存在,但我们可以通过上文的目录穿越漏洞调用ked_handler的功能6进行创建,从而使这个漏洞的利用成为可能。
LD_LIBRARY_PATH是一个危险的东西。利用这个环境变量,我们可以实现在任何程序运行前对程序的行为进行修改,甚至在程序运行时实现进程注入。子进程可以继承父进程的环境变量,而系统中绝大多数应用都是loader进程的子进程(下图PID 276)。
因此,将payload封装为so库,放置在LD_LIBRARY_PATH中的可写路径/rw/lib下,即可实现对接下来任意启动的进程进行注入并实现命令执行——比如我们在命令行登录时,就会启动一个/nova/bin/login。
在RouterOS 6.42+植入后门shell
用这个思路,我们还可以在无法触发后门的6.42版本中,使用老版本libumsg.so重新引入这个后门,对RouterOS“越狱”会有帮助。前面我们提到,
这个后门的触发逻辑在RouterOS的不同版本中略有不同。根据Tenable的研究,在RouterOS 6.40.9以下版本中,依据的文件是/flash/nova/etc/devel-login,在6.41.1以下版本中,判断的是/pckg/option,在6.42以上版本中,对/pckg/option文件类型做了额外的验证,但依然能够通过修改文件系统的方式进行触发。
RouterOS 6.42+中,远程触发开发者后门几乎是不可能的,攻击者更不可能跑到别人家里去拆掉Flash芯片往里塞后门。意味着即使攻击者拿下了用户名密码,但他也仅仅能访问GUI中有限的控制选项,不能植入payload利用设备获得更多的经济利益。
我们前面分析过,与后门相关的控制逻辑,有一部分位于/lib/libumsg.so中,准确来讲是nv::hasOptionPackage函数。既然我们已经能够进行任意文件上传,同时我们能够控制LD_LIBRARY_PATH,那么我们简单的将RouterOS 6.41.x中的libumsg.so复制出来,再在6.42.x的系统中利用目录穿越漏洞调用ked_handler的功能6创建/rw/lib目录并将libumsg.so上传上去,因为LD_LIBRARY_PATH的函数加载优先级高于PE文件中定义的加载路径[8],我们用这种方式即可实现后门触发,在6.42.x系统中启用ssh shell。
因为不想再写代码了,为了从另一个角度验证这个思路的可行性,我们在RouterOS 6.41.x上设计了下面的实验。
在RouterOS 6.41.x上利用漏洞“修复”漏洞
我们现在有一个后门,我们还控制了LD_LIBRARY_PATH下可写的目录/rw/lib,同时能够创建这个目录并向其中写入文件。假如我现在的设备就是一个骨干路由,需要对漏洞进行紧急修复,我们现在来尝试一下,在不更新、不重启系统的情况下通过LD_LIBRARY_PATH预加载动态链接库关掉这个后门。
首先,我们确认后门可以正常工作,并创建/rw/lib目录。当然,我们也可以用漏洞来创建这个目录,我只是懒得写exp了(笑
接下来,我们从RouterOS 6.42的ISO中提取出libumsg.so,并利用CVE-2018-14847(或者用你能想到的其他方法)上传到指定目录中。我在这里同时上传了一个busybox。
上传成功后,kill掉所有名为login和sshd的进程。
这样一来,当前所有通过控制台、Telnet与ssh登录的终端都会被关闭,再次连接就会启动新进程,同时加载我们通过LD_LIBRARY_PATH植入的新版本libumsg.so,后门shell失效。
还记得我们在前面对开发者后门的分析吗?如果libumsg.so中的后门函数hasOptionPackage返回true后,登录session的用户名会被重置为admin,从而控制台中显示的登录成功、失败的日志中的用户名都会因此被修改。但后门修复之后,这一段程序逻辑不复存在,因此对后门的登录尝试也会在系统日志中显示出来。
再结合我们前面提到的,用mount挂载魔改只读文件系统的方式,我们还可以用新版本覆盖根文件系统的/nova/bin/mproxy,将目录穿越漏洞一并修复掉。
我们再开个脑洞,整个漏洞修复过程分为三步:创建目录、上传修补程序、重启服务,这个过程完全可以自动化,一个脚本对全网存在漏洞的设备进行扫描修复。真正做出来肯定也会非常有趣吧。
看完上述内容,你们掌握能修复自己的RouterOS漏洞指的是什么的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注创新互联行业资讯频道,感谢各位的阅读!
网站栏目:能修复自己的RouterOS漏洞指的是什么
网页链接:http://myzitong.com/article/ppghci.html