您现在的位置是:首页 > 黑客技术

Metinfo6.0.0

作者:果E安全网时间:2020-10-25 19:11:28分类:黑客技术

简介*文中中牵涉到的有关漏洞已申报生产商并获得恢复,文中只限技术性科学研究与探讨,禁止用以不法主要用途,不然造成的一切不良影响自主担负。*文中创作者:Mochazz,文中归属于联合利华信息平台网原創奖赏方案,未经审批同意严禁转截各位好!,我是红曰安全性-七月火,本文是过去发掘的Metinfo漏洞,由于官方网已恢复,遂将剖析文章内容释放。这一前台接待注入漏洞存有已久,从MetInfo公布的6.0

*文中中牵涉到的有关漏洞已申报生产商并获得恢复,文中只限技术性科学研究与探讨,禁止用以不法主要用途,不然造成的一切不良影响自主担负。

*文中创作者:Mochazz,文中归属于联合利华信息平台网原創奖赏方案,未经审批同意严禁转截

各位好!,我是红曰安全性-七月火,本文是过去发掘的Metinfo漏洞,由于官方网已恢复,遂将剖析文章内容释放。

这一前台接待注入漏洞存有已久,从MetInfo公布的6.0版本号就存有,且之后官方网的恢复编码,还可以立即绕开。小编于7月份递交了那时候全新 MetInfo 6.1.0版本号SQL注入漏洞,该漏洞直至6.1.3版本号才被恢复。以下漏洞剖析,全当构思共享。

1

2018-1-29, MetInfo官方网调用后台管理及前台接待编码,并公布了MetInfo6.0。殊不知这一新版本编码,却存有一个比较严重的前台接待SQL注入漏洞,大家看来一下实际详细信息。

最先漏洞存有于app\\system\\message\\web\\message.class.php文件中,自变量{$_M[form][id]}立即拼凑在SQL句子中,且短信验证码检验涵数是在SQL句子查看以后,这也就导致了我们可以忽视短信验证码检验涵数,开展SQL注入。实际难题涵数编码以下:

2

那麼事实上,开发人员是有充分考虑SQL注入难题,并写了sqlinsert 来检验SQL注入进攻的,乃至还对{$_M[form][id]}开展了is_numeric分辨解决,可是为何最后還是存有SQL注入呢?下边大家实际讨论一下{$_M[form][id]}自变量的获得全过程。

要想开启这一SQL注入漏洞,我们可以根据前台接待的留言版和线上意见反馈2个作用来开启。大家这儿先剖析留言版处的程序结构。大家填好留言板留言处的表格,并在最正下方加上上id字段名,其值相匹配大家的进攻payload,实际以下:(为了更好地防止照片过长,我将一些主要参数的值给省去)

3

随后我们在message\\index.php文件中奠定中断点,会发觉在app\\system\\include\\class\\common.class.php的构造方法中,载入了表格,实际的启用链即编码以下:

4

这时this目标指的是web类,大家再次跟踪web类的load_form方式。

5

大家会发觉common基类的load_form方式将GET、POST、COOKIE获得的全部数据信息储放在$_M['form']中,数据信息仅用daddslashes函数解决。而web类的load_form方式调用了common类的load_form方式,对$_M['form']中的全部数据信息开展了sqlinsert解决,而且在后面分辨$_M['form']['id']是不是为数据,要不是数据就立即设定为空字符串。这种过虑涵数实际编码以下:

6

7

能够见到sqlinsert涵数对sleep关键词开展了解决,可是大家還是能够应用MYSQL中的benchmark涵数轻轻松松绕开(这两个涵数都能利用在時间盲注中,实际能够参照:https://xz.aliyun.com/t/2288)。可是大家的payload却绕但是is_numeric涵数,因此 这时的$_M['form']['id']会被设成空字符串。那为何还存有SQL进攻呢?大家然后看程序结构。

在跟踪程序流程的全过程中,大家会发觉在实行完load::sys_class('upfile', 'new')编码后,$_M['form']['id']的值又变成了大家传到的payload,这表明这里边一定是又再次开展了表格取值。

8

不可置否,程序流程中载入的upfile类又再次加载了$_M['form']的值,并且并沒有开展除开基类中daddslashes方式之外的消毒杀菌解决,这也是导致SQL注入的缘故。

9

我们可以依据上边的漏洞基本原理,轻轻松松的写成进攻脚本制作:

10

然后,大家再说比照一下5月份的恢复编码,这时MetInfo官方网并沒有升级版本信息,只是悄悄恢复了编码,恢复编码以下下图:

11

能够清楚的看到daddslashes方式刚开始对每一个主要参数开展sqlinsert解决。而上边大家说过,这一消毒杀菌涵数是能够绕开的,因此 大家仍然能够开展SQL注入。

尽管能够开展盲注,可是還是太消耗時间了,大家是不是有方法将其转化成布尔运算盲注呢?回答是能够的,接下去大家就讨论一下,如何把这一处時间盲注变为布尔运算盲注。

在app\\system\\message\\web\\message.class.php文件中,大家会发觉假如SQL句子查看結果中的value字段名非空,则会开展短信验证码的检验,不然会立即回到意见反馈早已被关掉。

12

13

这样子,大家就可以依据不一样的回到結果,开展布尔运算盲注。如今大家看来一下怎样寻找考虑查看結果中的value字段名非空的columnid,立即在MYSQL中做以下查看:

14

15

这样子大家就找到2个能用的columnid最后大家一样能够写成进攻脚本制作,以下:

16

大家再看来另一处注入点,前边大家剖析的是留言版处的SQL注入难题,此次我们要剖析线上意见反馈处的SQL注入,漏洞的诱因全是相近的。但是在利用这一漏洞时,大家必须历经feedback类check_field方式的检验。

17

这儿事实上能用的id有两个,以下:

18

比如这儿我觉得利用id=71,那麼必须结构以下数据文件,才会进到漏洞开启处。

19

如今绕开了check_field方式的检验,大家就成功赶到了开启SQL注入漏洞的feedback累的add方式,其部位在app\\system\\feedback\\web\\feedback.class.php,实际编码以下:

20

大家会发觉此次的短信验证码校检,部位在注入点前边,因此 利用起來较为不便。这儿我们可以应用工程爆破短信验证码融合時间盲注的方法开展进攻,用下列程序流程形成全排列短信验证码词典:

21

可是那样的进攻成本费還是太高了,假如大伙儿会深度学习,能够添加有关优化算法来自动检索短信验证码。

最终大家看来一下MetInfo 6.1.3最新版本的恢复状况怎样,详细情况以下DIFF图:

22

文章内容中提及的这一漏洞点,事实上还可以从别的通道点开展开启,以前也早已有老师傅释放剖析文章内容,漏洞的诱因全是一样的,实际能够参考文尾的类似文章,这儿已不过多阐释。文中剖析告一段落,若有不善敬请诸位指正。此外,大家精英团队已经招生代码审计组员,假如您在这些方面有丰富多彩的工作经验,加入我们大家。(能够发送邮件至:379032449@qq.com)。对代码审计很感兴趣的盆友,还可以关心大家的代码审计新项目:PHP-Audit-Labs

Metinfo 6.1.2 SQL注入

[代码审计]METINFO 6.1.2 SQL注入

*文中创作者:Mochazz,文中归属于联合利华信息平台网原創奖赏方案,未经审批同意严禁转截

郑重声明:

果E安全网所有活动均为互联网所得,如有侵权请联系本站删除处理,转载请注明本站地址。

我来说两句