欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

CVE-2018-1158 MikroTik RouterOS漏洞分析之发现CVE-2019-13955

来源:本站整理 作者:佚名 时间:2019-08-06 TAG: 我要投稿

漏洞简介
CVE-2018-1158是MikroTik路由器中存在的一个stack exhaustion漏洞。认证的用户通过构造并发送一个特殊的json消息,处理程序在解析该json消息时会出现递归调用,造成stack exhaustion,导致对应的服务崩溃重启。
该漏洞由Tenable的Jacob Baines发现,同时提供了对应的PoC脚本。另外,他的关于RouterOS漏洞挖掘的议题《Bug Hunting in RouterOS》非常不错,对MikroTik路由器中使用的一些自定义消息格式进行了细致介绍,同时还提供了很多工具来辅助分析。相关工具、议题以及PoC脚本可在git库routeros获取,强烈推荐给对MikroTik设备感兴趣的人。
下面利用已有的PoC脚本和搭建的MikroTik RouterOS仿真环境,对该漏洞的形成原因进行分析。
 
环境准备
MikroTik官方提供多种格式的镜像,其中可以利用.iso或者.vmdk格式的镜像,结合VMware虚拟机来搭建仿真环境。具体的搭建步骤可参考文章 Make It Rain with MikroTik 和 Finding and exploiting CVE-2018–7445,这里不再赘述。
根据Tenable的漏洞公告可知,该漏洞在6.40.9、6.42.7及6.43等版本中修复。为了便于对漏洞进行分析和补丁分析,选取的相关镜像版本如下。
6.40.5,x86架构,用于进行漏洞分析
6.42.11,x86架构,用于进行补丁分析
搭建起仿真环境后,由于RouterOS自带的命令行界面比较受限,只能执行特定的命令,不便于后续进一步的分析和调试,因此还需要想办法获取设备的root shell。同样,Jacob Baines在他的议题《Bug Hunting in RouterOS》中给出了相应的方法,这里采用修改/rw/DEFCONF的方式。对于该文件的修改,可以通过给Ubuntu虚拟机添加一块硬盘并选择对应的vmdk文件,然后进行mount并修改。
需要说明的是,采用这种方式进行修改后,每次设备启动后/rw/DEFCONF文件会被删除,如下。
# /etc/rc.d/run.d/S12defconf
elif [ -f /rw/DEFCONF ]; then
    # ...
    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) &  # /rw/DEFCONF 被删除
fi
这样下次如果需要获取root shell,还需要再重新挂载并修改,比较麻烦。可行的解决方式如下:
在修改/rw/DEFCONF文件后,创建一个虚拟机快照,下次直接恢复该快照即可;
在修改/rw/DEFCONF文件后,将其拷贝一份保存到其他路径,获取到设备root shell后再拷贝一份到/rw路径下。
 
漏洞分析
根据漏洞公告可知,与该漏洞相关的程序为www。在设备上利用gdbserver附加到该进程进行远程调试,然后运行对应的PoC脚本,在本地的gdb中捕获到如下异常。
(gdb)
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 267.373]
=> 0x777563f5
:   call   0x7775a948
   0x777563fa
:  add    ebx,0x7c06
   0x77756400
:  mov    esi,DWORD PTR [ebp+0x8]
   0x77756403
:  mov    edi,DWORD PTR [esi+0xc]
// ...
// stacktrace
(gdb) bt
#0  0x777563f5 in pthread_mutex_lock () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/lib/libpthread.so.0
#1  0x77573cc3 in malloc () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/lib/libc.so.0
#2  0x775a5c3e in string::reserve(unsigned int) () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/lib/libuc++.so
#3  0x775a5ecd in string::assign(char const*, char const*) () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/lib/libuc++.so
#4  0x775a5f1d in string::assign(string const&) () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/lib/libuc++.so
#5  0x77788942 in void nv::message::insert(nv::string_id, nv::IdTraits::set_type) () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/lib/libumsg.so
#6  0x77504b63 in ?? () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/nova/lib/www/jsproxy.p
# ...
#1102 0x77504bd3 in ?? () from
/mikrotik-6.40.5/_system-6.40.5.npk.extracted/squashfs-root/nova/lib/www/jsproxy.p
# ...
为了便于分析,临时关闭了系统的ASLR机制.
查看栈回溯信息,可以看到存在大量与0x77504bd3 in ?? () from …/jsproxy.p相关的栈帧信息,与漏洞描述中的”递归解析”一致。根据PoC中数据内容格式”{m01: {m01: … }}”,结合单步调试,定位漏洞触发的地方在sub_77504904()函数中,其被json2message()函数调用,核心代码片段如下。
sub_77504904()
{
    // ...
    switch ( (_BYTE)a3 )
    {
        case 'b':
            v9 = v6;
            v10 = strtoul(nptr, &nptr, 0);
            nv::message::insert(v58, v59, v10 != 0, v9);
            break;

[1] [2] [3]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载