深入分析 CVE-2018-1045 MSA-18-0004

目录

漏洞信息分析

代码审计分析

总结

关于漏洞利用

漏洞修复

漏洞信息分析

漏洞信息的原话是这样的

“可以在日历块中的事件名称中注入JavaScript。但通常情况下,创建活动的能力只提供给信任的用户(如教师),所以不会被标记为具有XSS风险,而被视为安全问题。”

Xss注入点在’日历块中的事件名称中’

于是注册了一个账号,根据描述找了一下,并没有找到’event name’,但是找到了一些较为相近的,单单根据上面的漏洞描述信息,感觉xss注入点可能是在类似下面的链接的页面里。

可能一:

https://learn.moodle.net/calendar/view.php?view=month

可能二:

https://learn.moodle.net/calendar/managesubscriptions.php?course=1

继续查看信息,找到一个diff

很明显,这里的修复方法是对$name这个参数使用了clean_text()函数进行了过滤,也就是原来的$name变量是存在xss注入的。

 

代码审计分析

下面下载3.3.4版本的源码进行代码审计分析一下

(为什么下载修复后的3.3.4版本 不下载存在漏洞的3.3.3版本呢?因为3.3.3版本我没找到,而且3.3.4版本和3.3.3版本在这个漏洞上的不同只在于一句代码,所以我们完全可以拿3.3.4版本来分析。)

分析目标有两个

  • 找出$name变量具体是在哪里传过来的(找到可控的点)
  • 分析$name变量在没有进行clean_text()函数过滤时最后是在哪里输出,是如何导致xss注入的,如何构造payload
  • 分析修补方案是否存在绕过(由于时间关系,这次暂不分析这一点)

 

漏洞修复点在/calendar/lib.php的1460行

这一行未修复前的代码为

跟进html_writer::link方法,class html_writer 类在/lib/outputcomponents.php第1590行,link方法在1732行,这里我整理了一下相关的代码,让逻辑更加清晰一点,贴出整理后的关键代码,可以得到如下逻辑

通过阅读这个逻辑可以知道,$name变量的变化过程是$name–$text–$contents,

,变量$popupcontent返回的内容的最后的格式肯定是类似这个样子的 <a ………>$name</………….a>

然后后面的变量的传递过程就是$popupcontent–$popupdata–$data–$cell然后最后实际上就是把$popupcontent输出到html页面,实际上就是把

<a ………>$name</………….a> 这样的内容输出到页面,并且在这个过程中(从返回$popupcontent到输出的过程中)没有对$name做任何的过滤。

下面我们可以验证一下输出的内容是不是像分析的 <a ………>$name</………….a> 这样的格式的

Ps:这里要说明一下,因为我搭建了很久都没有把那个moodle.的网站搭建起来,按照官方文档去搭建总是会显示安装出错,谷歌了好久也没搞定,所以最后很无奈,只能直接在这个页面做测试了(需要先登录)

https://learn.moodle.net/calendar/view.php?view=month

我们审查一下元素,可以看到

确实是符合<a ………>$name</………….a> 这样的格式的在这里$name=test

说明我们上面的分析是正确的。(这个页面的版本什么的可能会有发生一定的变化,发生的变化应该也是对$name变量进行了过滤而已,并不会影响$name输出的位置,而且我们这里使用的是 字符串‘test’进行的验证,目的是验证”我们上面的分析返回的$popupcontent值的格式是<a ………>$name</………….a>这样的” ,这里虽然版本会不一样,但实际上应该是不会影响这一个的验证的。)

 

既然上面我们已经分析和验证了,输入的$name,最后会以<a ………>$name</………….a>的格式输出,而且在这个过程中没有对$name进行过滤,那么在$event->name传递到$name的过程中,如果也没有对其进行过滤的话,这就可能造成xss注入了。

下面先分析$name的来源,有四处 分别在1444、1452、1454、1457行(实际上都是传入的$event-name)

先跟进一下format_string方法,在/lib/weblib.php 1409行,此部分代码有点多就不贴出了,但是可以发现这里也是没有对$event-name变量进行过滤的。

结合上面的分析,可以知道从1452、1454、1457行得到的$name是会存在xss注入的。

下面分析$name = get_string(‘namewithsource’, ‘calendar’, $a);

跟进get_string方法,在/lib/moodlelib.php  7031行,内容如下

我们继续跟进class lang_string这个类,在/lib/moodlelib.php 9827行

贴出部分关键代码

这部分的代码有点多,具体逻辑细节也稍微有点复杂,但是根据最初的这几句代码

我们可以知道,但其实我们的重点是要分析$name有没有被过滤,也就是分析$a->name有没有被过滤(因为可控变量是$event->name,传给了$a->name)所以我们只要关注在$a->name变量的传递过程中是否被过滤了就可以了。

经过跟踪$a的传递过程,并没有发现对$a->name有做过什么过滤,所以从第1444行进来的$name变量也是存在xss的

$name = get_string('namewithsource', 'calendar', $a);

并且根据代码的注释

以及初始漏洞的描述

以及我们上面的分析过程,我们可以知道$name变量是the event name in the calendar block,而且这个是我们完全可控的。也就是在类似这样的页面中

https://learn.moodle.net/calendar/view.php?view=month&time=1516665600&lang=en

这里我们只要输入<script>alert(0)</script>或者<img data-original=0 onerror=alert(0)>即可验证此漏洞。

(但是网页https://learn.moodle.net/calendar/view.php?view=month已经修复了这个漏洞,我没有办法在该网页上验证~然后moodle这个网站我又尝试了很久也没有搭建起来,总是会安装报错,谷歌也暂时没有找到有用的解决办法)

 

总结:

本漏洞存在的原因是存在可控输入点 Event title而且传递到$name中并且未经任何过滤就按以下格式直接输出<a….>$name</…a> 由此导致了xss注入 (此格式是简化格式)

(较完整格式类似下图)

 

关于漏洞利用:

但是这里利用这个漏洞需要用户先进行登录,我们才能打开日程管理模块,才能进行xss注入,所以利用起来可能会显得非常的鸡肋。

因为这里是属于存储型的xss,目前想到的一种利用方法就是 攻击者注册账户A,并在自己的日程管理模块中注入盲打cookie的xss代码,这样如果其他用户B访问查看了A的日程事件安排event的话,这时候就会执行A注入进去的xss代码,可能能够盲打到访问的用户B的cookie。

很遗憾的是没能够把环境搭建起来进行实际的测试。

 

漏洞修复

只需要更改/calendar/lib.php的1460行代码,把原来的

$popupcontent .= \html_writer::link($dayhref, $name);

改为

$popupcontent .= \html_writer::link($dayhref, clean_text($name));

即可

本文由 华盟网 作者:AlexFrankly 发表,其版权均为 华盟网 所有,文章内容系作者个人观点,不代表 华盟网 对观点赞同或支持。如需转载,请注明文章来源。

0

相关文章

发表评论

电子邮件地址不会被公开。