CMS(内容管理系统)很适合被用来做代码审计，尤其是现在CMS系统越来越流行，很多人愿意使用CMS搭建自己的项目。由于大部分CMS是一种开源项目，所以对于CMS的审计属于白盒测试，白盒测试让我们可以发现更多的安全漏洞，而且一旦我们发现了这些漏洞，由于其被广泛使用，所以它的漏洞的影响范围也是呈指数级增长的。这是因为通过白盒测试我们可以查看到程序的内部结构，从而更清楚的理解程序的工作原理。
WityCMS就是一个由creatiwiwiwiwiwity制作的CMS系统，它帮助管理不同用途的内容，如个人博客、商业网站或任何其他定制系统。在本文中，我将介绍如何设置CMS，查找web应用程序问题，以及如何复现CVE-2018-11512漏洞。
环境安装(windows下安装xampp)
- 1.下载WityCMS0.6.1的源代码
- 2.把/witycms-0.6.1 目录复制到C:xampphtdocs 下 或者是你自己安装xampp的的htdocs目录
- 3.运行Apache和MySQL然后访问http://localhost/phpmyadmin/index.php.
- 4.点击"databases"(中文版本的"数据库")
- 5.创建一个名为"creatiwity_cms"的数据库
- 6.浏览器进入http://localhost/witycms-0.6.1/ 可以查看你的程序
- 7.填下"Site name(站点名称)"之类的内容，我添加了一个"Test"，然后可以点击next进入下一步了
- 8.然后是定义系统的主页，你可以从选项中选择任何一个。比如：
- 9.接着设置数据库，第5步那里我建了一个名为"creatiwity_cms"的数据库，所以在这我们要这样设置
- 10.输入管理员账号，然后点击"Launch install!(开始安装)"
- 11.安装成功后的页面长这样:
查找漏洞
因为这篇文章主要是关于CVE-2018-11512的，所以我今天就只找这个程序中的持久型XSS的洞，开始之前，我们先了解下什么是持久型XSS。
根据OWASP的介绍，"跨站脚本攻击(xss)是一种注入类型的攻击手段，它允许恶意web用户将代码植入到提供给其它用户使用的页面中"。这意味着只要一个网站上存在注入点，xss就可能被触发。目前有三种类型的XSS，但是本文我将讨论常见的XSS，即反射型XSS和持久型XSS。
当输入的数据被在发出请求后被返回给我们时，反射型XSS就会被触发。对于反射型XSS来说，网站的搜索功能可以作为一个测试反射型XSS的很好的例子。当用户在搜索框中输入一段payload后，该搜索功能可能会受到反射型XSS的影响。
另外，持久型XSS也被称为"存储型XSS"。这种类型的XSS值会被保存在系统中的某个数据库或是文件中。XSS的利用点通常存在于可以让用户随时更改的设置操作中，比如用户的个人信息页，可以设置用户的电子邮件，姓名，地址之类的地方。也可能存在于用户可以自己更改的某些系统设置中。
对于wityCMS，我的目标是找到可以在系统中保存数据的利用点。这基本上可以手工完成，也可以通过工具自动找到这些利用点。由于我已经在Windows中安装了它，所以我必须使用命令“findstr”而不是“grep”(抱歉，喜欢用"grep"的同学们)。可以在这里找到"findstr"的相关信息。
恶意代码的文件，我们可以使用以下命令:">要列出可以输入恶意代码的文件，我们可以使用以下命令:
/S = Recursive searching
/P = Skip files with non-printable characters
/I = Case insensitive
/N = Prints the line number
/c:<STR> = String to look for
代码:
findstr /SPIN /c:"<input" "c:xampphtdocswitycms-0.6.1*.html"
命令行运行后的结果:
这个结果肯定很让人惊喜，因为可能存在XSS的地方太多了。登录到管理员面板后，我们可以轻松的在输入框中输入我们的payload。通过访问http://localhost/witycms-0.6.1/，我们可以看到一个很明显的值，如图所示:
我们安装这个CMS的时候设置了这个站点名称，它现在显示在主页上，不知道这个站点名称会不会存在持久型XSS，现在我们看看能不能在管理设置里修改这个值。
使用安装时设置的管理员账号密码登录到管理面板，登录后，管理面板中会有一个这样的小链接:
点击"Administration"后，网页会被重定向到我们安装时的执行设置操作的页面，第一个设置值也是网站名称。
插入一个非常简单的XSS代码试试:
script>alert(1)</script>
点击"save(保存)"后，返回值为:
可以注意到<script>和</script>标签被过滤了，因此我们可以知道该系统中存在一个防护机制，所以现在我们需要找到这个防护机制的运行原理。
当数据被保存到数据库中时，会处理一个请求。在这种情况下，我们应该能够识别请求方法是POST还是GET，在页面空白处右键单击"审查元素"查看源代码后，可以确认该方法是POST请求。
从这点来看，我们应该尝试找到POST请求发生的地方，这样顺下去我们就可以看到防护机制的运行点。因此，在cmd中输入以下命令:
findstr /SPIN /c:"$_POST" "c:xampphtdocswitycms-0.6.1*.php"
这个命令类似于我们之前查找包含“input”标记的文件，但是这次，我们尝试在.php文件中查找引用"$_POST"的地方。
因为其他文件都与默认包含的库有关，这些都pass掉。所以命令的结果指向文WMain.hp,WRequest.php和WSession.php。浏览这些文件将我们发现在WRequest中有一个有趣的函数。如下所示，当防护机制发现脚本标示符时，这些标示符将被一个空字符串替换:
由于过滤器函数没有递归，所以过滤器只能拦截这样的输入:
所以输入这种内容是可以绕过过滤器的:
在我们设置站点名称的输入框中输入以下内容，我们将会得到以下结果:
一旦这个payload被设置为站点名称，访问网站的用户将会触发这个脚本，即使TA并没有经过身份验证。
这就开启了新世界的大门，因为当用户访问网站时会执行某些恶意脚本可能会造成比较严重的后果。比如可以将用户重定向到钓鱼站点，在用户不知情的情况下执行矿机脚本，或者其他很多操作。
处理CVE编号
由于这个bug容易引起安全问题，并且这个CMS正在被数以千计的人使用，所以我决定给这个程序申请一个CVE编号，以此来获得一个公开的CVE条目。
信息安全漏洞或者已经暴露出来的弱点给出一个公共的名称。cnas(cve-numbering-authorities)根据程序类型分别处理这些cve编号的漏洞。例如，如果联想设备中发现了安全问题，应该向联想的产品安全应急响应团队报告，在评估了漏洞后，他们将会给这个漏洞一个cve编号。">CVE 的英文全称是"Common Vulnerabilities & Exposures"，CVE就好像是一个字典表，为广泛认同的计算机信息安全漏洞或者已经暴露出来的弱点给出一个公共的名称。CNAs(CVE Numbering Authorities)根据程序类型分别处理这些CVE编号的漏洞。例如，如果联想设备中发现了安全问题，应该向联想的产品安全应急响应团队报告，在评估了漏洞后，他们将会给这个漏洞一个CVE编号。
这说明，如果同样是在CNA公司的产品或项目中发现了漏洞，他们评估后可以直接给出一个CVE编号，在CNAs的CVE的漏洞列表中可以通过编号直接找到这个漏洞。而对于wityCMS, CreatiWity这两个产品，其创建者没有注册到CNA，所以我们可以向MITRE公司申请这个持久型XSS漏洞的CVE编号，下面是处理CVE漏洞事件的步骤：
- 1.确认产品是否由CNA管理。如果由CNA管理，则报告该特定CNA的漏洞。如果不是，则报告给MITRE公司。
- 2.通过google确认发现的漏洞是否已经分配了一个CVE编号。经常检查产品更新，以确认漏洞是否已经公开。
- 3.对于wityCMS的情况，我使用了MITRE公司的CVE申请表单，可以在这里找到。
- 4.在表格中填写所需的详细信息。关于wityCMS的这个漏洞，我是这样填的:
- Vulnerability Type: Cross-Site Scripting
- (漏洞类型:xss)
- Product: wityCMS
- (厂商:wityCMS)
- Version: 0.6.1
- (版本：0.6.1)
- Vendor confirmed the vulnerability? No (Not acknowledged yet at the time - of request)
- 厂商是否已确认该漏洞 没有 (漏洞提交时厂商未确认)
- Attack Type: Remote
- 攻击类型:远程
- Impact: Code execution
- (影响:代码执行)
- Affected Components: Source code files showing “site_title” as output
- 受影响的组件:输出"site_title"的源文件
- Attack Vector: To exploit the vulnerability, one must craft and enter a script in the Site name field of the system
- 攻击方式:必须在系统的站点名称字段中手工注入脚本
- Suggested Description: Stored cross-site scripting (XSS) vulnerability in the "Website's name" field found in the "Settings" page under the "General" menu in Creatiwity wityCMS 0.6.1 allows remote attackers to inject arbitrary web script or HTML via a crafted website name by doing an authenticated POST HTTP request to admin/settings/general.
- 漏洞详情:在creatiwitycms 0.6.1的“设置”菜单下的“网站名称”字段中存在存储型XSS漏洞，允许远程攻击者通过一个经过验证的POST HTTP请求向admin/ Settings / General注入任意的web脚本或HTML。
- Discoverer: Nathu Nandwani
- (发现者:Nathu Nandwani)
- Reference(s): https://github.com/Creatiwity/wityCMS/issues/150, https://github.com/Creatiwity/wityCMS/co...229147de44
- 参考
填写信息应该详细一点。为了让CVE处理的更快一些，描述中最好引用一些可以辅助理解漏洞的资料，并且详细地描述漏洞细节，如果可以，还应该写上漏洞可能有的修复方案。例如，在发送报告之前，我在这个项目的GitHub主页上发现了这个漏洞可能存在的点，因为有很多已经公开的关于存储型XSS的CVE漏洞，我找了其中的一个作为参考，然后通过这个漏洞想到了构造一个存储型XSS方法，并且注意到在这个GitHub项目中可能通过这个方法复现这个漏洞。
最后一点小贴士
- 如果细节已经公开，那么CVE号处理只需要一两天，所以最好先与开发人员或与项目相关的响应团队进行沟通，以便进行适当的修复。
- CVE漏洞的细节应该是准确的。更改发送给CNAs的报告的细节将减慢审核的速度，这意味着必须首先确认漏洞，不要浪费双方的时间。
- 更多关于CVE漏洞提交的细节可以在这里找到。
- VulDB提供漏洞公开服务。注册一个VulDB账号，你可以在那里提交一个条目。例如，这里是这个安全问题的VulDB条目。
- 也可以提交到exploit-db.com。这不仅显示出问题确实存在，而且还为CVE编号增加了可信的参考，因为安全团队尽其所能地测试验证漏洞是否存在。这里是一个exploit-db.com条目，请注意它目前正在等待验证。提交说明可以在这里找到
我在这个wityCMS的一些版本中发现了其他持久型的XSS漏洞，但是我没有为它应用CVE编号。你能找到它们吗?期待听到您的意见或问题。(゜-゜)つロ 干杯~
作者： nats</br>
翻译：i春秋翻译小组-prison</br>
翻译来源：https://greysec.net/showthread.php?tid=3202
大家有问题可以留言，也欢迎大家到春秋论坛玩耍哟~