VaeThink v1.0.1 code execution vulnerability mining analysis

VaeThink v1.0.1 code execution vulnerability mining analysis


0x01 Introduction

This article is a record of the analysis, code execution vulnerability mining and audit process of a niche CMS (vaeThink v1.0.1), which is developed based on ThinkPHP5. As an introductory rookie in code auditing, I also hope to record and share the process of practice and learning, in order to communicate and progress with everyone.


0x02 analysis

By gitdownloading the project source code to the local, first understand the project source code directory structure:

www  WEB 
    port               API 
 public                WEB 
    admin_themes       admin 
    .htaccess           apache 
    thinkphp           ThinkPHP5 
    vae                vaeThink 
 vendor                 Composer 
 composer.json         composer  
 LICENSE.txt                 README  

After obtaining the source code of the CMS project, do not rush to conduct a white-box audit of the source code. You can deploy and run the CMS first, recognize and understand its function points, and conduct a black-box test at the same time.

The CMS deployment is relatively simple, as long as LAMPthe environment, pointing to the root directory of the site and the publicdirectory can then follow the prompts to install. After the installation is complete, visit the CMS and the login page will appear directly:

It should be noted that generally there may be SQL injection vulnerabilities in the login function, but this article focuses on mining code execution vulnerabilities, so other types will be skipped . We will continue to log in to the background through the administrator account set during installation to learn more about the background Other function points:

Generally, there are code execution vulnerabilities, which may be in the following functional modules:

2 cache 

From these 5 points, we continue to explore the CMS.


0x03 configuration, log and cache files

In the /menu, there are functional pages related to website information, email and SMS configuration. Without the source code audit, first check the data tables and fields in the database and find that there is no information related to these configurations. It can be guessed that this information may be directly processed and stored in a configuration file. After checking the project directory the general understanding, should be in data/confthe next.

We input specific test data for submission, and grepfilter files containing specific data:

I was delighted to find that the input configuration content was written data/conf/extra/webconfig.phpin, and at the same time, noticed that the input configuration content was also written into the log file data/runtime/log/201905/1557823231-14.log.

We continue to construct controllable content '];phpinfo();//, which can be escaped by closing the previous array:

However, the test found that the content before the controllable content returnwill return directly, and the injected code has not been executed. In addition, pay attention to the path of the configuration file. It can be found that the datadirectory is not a website path that can be directly accessed. It is possible to go further unless it can be traversed with other paths or the file contains loopholes . The log file here is the same.

Notes that datathere are directory cacheand tempdirectory in which some cache files

In addition to the same restrictions as the above configuration and log files, these cache files have also been exit()processed safely:


0x04 file upload

A few roads are temporarily blocked, don't panic, continue to observe other functions of CMS. On the administrator's page, it was found that there is an avatar upload function. Simply select one to t.phpupload. The page prompts that the file type is wrong. It is not ruled out that this is just a front-end verification. We continue to upload by modifying the file suffix by capturing the package:

After the test, it was found that the upload point here really only performed front-end verification on the file suffix, directly when uploading .phpthe file with the suffix:


0x05 Code execution function parameters can be controlled

In addition to the direct violent file upload of the profile picture function (too simple...) of this CMS, are there other possible loopholes? For example, user input can be directly used as a parameter of some code execution functions, leading to arbitrary code execution . With doubts, we continue to dig further on CMS, PHPStormstart! XDebugConfigure!

Common code execution functions in PHP are, eval systemetc., and the command+shift+fentry point can be found by performing a global search for these function name keywords. After some investigation, a suspicious place was finally located listenrain/vae/lib/Auth.php 194 getAuthList :

We continue to analyze backwards from here to see if it can be controlled by the user.

In evalthe presence of a function of the variable parameter $command:

The variable comes from the previous line $rule['condition']and is replaced {(w*?)}, but no other filtering operations are performed:

$command = preg_replace('/{(w*?)}/', '$user['\1']', $rule['condition']);

$ruleIt is 186 $rules = Db::name($this->config['auth_rule'])->where($map)->field('condition,name')->select();part of the data obtained from the database query. As you can see from the author's comments, it is read .

We can roughly understand the function of this function through analysis and function name, which is to obtain user group permissions through user id and return the permission list.

Continue to view getAuthListthe call situation, is in the checkfunction:

Backtracking checkfunction, it is found that the call is in:

At this point, it can be basically determined that this process will be triggered in the function module. Next, breakpoints are used for dynamic debugging, which is convenient for viewing the variable value. We select any option in the menu to access, and the execution process will go through the above-mentioned inspection function that we have analyzed:

After analysis, it can be determined that the rule conditionfields corresponding to the permissions of the user in the database will eval()be executed as parameters

Then continue to determine conditionwhether the fields in the data table are user-controllable. After analysis, it can be found / there are operational functions for the data table in the background page, and the corresponding conditionfields in the data table :

After trying to modify the content, visit any page in the menu, and dynamically debug and observe:

As you can see, the controllable content has not been filtered, and successfully triggered the :


0x06 end

This article is aimed at simply mining and analyzing vaeThink v1.0.1 from the perspective of configuration files, log files and cache files writing, file uploading and function execution parameters controllable. The content of the full text is relatively simple, the purpose is to record and share exchanges, please spit it lightly.

Finally, thanks for reading!