深入分析 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 src=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));

即可