Metinfo 6.0.0 众多漏洞分析

最近在seebug上浏览漏洞,发现metinfo爆出了很多危害很大的漏洞,然后看了一下cve列表,竟然还有这么多,既然这样那就开始跟踪学习起来。

 

伪全局变量

首先metinfo在全局都使用了一种对传入参数进行封装的方法,也就是伪全局变量覆盖,下面是核心代码:
这也是我在之前的文章中提到的,在开发中多封装一层的好处,可以在很多地方避免因为没有过滤就拼接数据到sql变量中,导致的sql注入,这也是给大家在开发过程中需要注意的地方。

 

CVE-2018-7271、CVE-2018-12531

首先是两个安装时候的漏洞,也是在安装的过程中,没有对输入进行过滤,导致了任意代码注入,写入webshell,跟了几个cms,发现很多cms都存在这个问题。下面简单贴一下代码:
可以发现,并没有对输入进行检查,直接拼接写入了文件,造成了漏洞,下面实际测试一下:
安装时输入的数据库密码为payload:

pass = "*/assert($_REQUEST[w])/*"
拼接之后代码为:
<?php
     /*
       con_db_host = "localhost"
       con_db_port = "3306"
       con_db_id   = "root"
       con_db_pass    = ""*/assert($_REQUEST[w]);/*""
       con_db_name = "metinfo"
       tablepre    =  "met_"
       db_charset  =  "utf8";
      */
?>

然后访问/config/config_db.php即可获取webshell。

 

CVE-2018-7721

这是一个前台的反馈处的xss,可以在没有登录的情况下,直接xss到管理员,从而拿到管理员cookie,作为管理员登陆。
首先找到feedback的代码逻辑控制器/app/system/feedback/web/feedback.class.php
只是简单的代码入库操作,然后找到管理员查看反馈的代码控制逻辑/app/system/feedback/admin/feedback_admin.class.php:
看到将用户输入从数据库中取出来以后,引入了模板文件,然后跟进到模板文件中查看是否有过滤:
看到整个流程中并没有对代码进行实体化转义等过滤xss的方式,因为xss变的很简单,我们简单做个弹窗测试

<script>alert('/xss/');</script>

然后管理员查看反馈是触发xss:

 

CVE-2018-9934

这是一个比较有趣的漏洞,这并不是传统的web漏洞,而是一种类似于钓鱼的中间人攻击方式,要利用这个漏洞首先要知道你要攻击的用户的邮箱,然后密码找回功能,通过篡改请求host头,从而将发送给用户的链接中的host更改,用户点击之后,黑客就获得了用户的密码更换token,从而更改掉用户的密码。
攻击手法为:
在metinfo点击找回密码,然后输入要攻击的用户的邮箱,


然后用户收到钓鱼邮件,当用户点击以后
成功接收到了用户的密码更改链接,然后
就可以成功改掉该用户的密码。
攻击流程大概如图:

 

CVE-2018-12530

这是一个任意文件删除漏洞,可以将安全后产生的安装锁文件删除,然后利用安装时的代码注入漏洞getshell,看来这两个漏洞的组合拳还是很多的。
首先可以看一下payload:

/admin/app/batch/csvup.php?fileField=test-1&flienamecsv=../../../config/install.lock

然后跟进到代码中看一下:

可以发现并没有对传入的filenamecsv过滤,直接读了这个csv文件,然后读取完成以后,采取了unlink操作,也就导致了漏洞的产生。

 

CVE-2018-13024

这是一个后台的getshell漏洞,可以造成任意文件写入,算是很危险的,下面具体跟踪一下文件写入的流程:
产生漏洞的位置在admincolumnsave.php的大约32行的column_copyconfig函数:
首先在进入这个条件的时候,还是比较好进的,没有什么必须满足的条件,然后跟进这个函数
其实这个函数中间的switch可以直接略过,因为最后还是会带入到下面的Copyindex函数中,而这个函数就是文件写入的关键函数:
可以看到,这里直接就将函数的第二个参数写入了文件,这个参数追溯起来就是我们之前的module变量,于是整个数据流程就变成了:

所以我们在管理员登陆以后,构造的payload是:

admin/column/save.php?name=123&action=editor&foldername=upload&module=22;phpinfo();/*

然后我们只要访问/upload/就可以默认访问到写好的shell。

 

一些设计不当导致的小问题

还有一些cve是关于跨站请求伪造的,这里就不具体分析了,因为这样的点真的很多。

因为整个cms在设计的时候,后台没有采用csrf的防御机制,所以攻击着可以很轻易的构造恶意表单,然后通过钓鱼的手段,使管理员访问这个钓鱼链接,然后csrf恶意表单就被触发了,从而完成了很多只有管理员才能做的操作。
下面贴一下csrf的攻击流程图,方便新手理解;
这也是在开发中应该注意到的,csrf的防护是必须的,现在很多开发框架都已经默认启用了csrf-toen的防御方式,虽然不能完全避免csrf攻击,但是能让攻击的构造变得更难。

(完)