in ,

Vulnerability Analysis | WordPress Backup Migration Plugin Remote Code Execution Vulnerability (CVE-2023-6553)


Vulnerability Analysis | WordPress Backup Migration Plugin Remote Code Execution Vulnerability (CVE-2023-6553)

Date: April 26, 2024
Viewed: 74

WordPress Backup Migration Plugin is a powerful WordPress plugin that provides a series of easy-to-use tools and features to simplify the backup and migration process of WordPress websites. Recently, Wangsu Yanwu Security Lab discovered that there is a remote code execution vulnerability in Backup Migration versions less than 1.3.8. The vulnerability is rated 9.8 in CVSS3.1 and the risk level is critical. It can allow malicious attackers to remotely execute on the target website. By executing the command, you can also gain backdoor access and then take full control of the website.

The conditions for exploiting this vulnerability are simple and its impact is wide. It is recommended that enterprises and institutions check the plug-in version and fix related vulnerabilities, or introduce a web protection solution to prevent the exploitation of this vulnerability.

Backup Migration <= 1.3.7

This vulnerability exists in the plug-in file /includes/backup-heart.php. Locate the file, set a breakpoint, and send data under the path /wp-content/plugins/backup-backup/includes/backup-heart.php. Dynamic debugging. After the server receives the data, it finds that the request header data is stored in the variable $fields.

Continuing down the page, we find that the field values ​​in $fields are defined as constants. Here we mainly focus on the BMI_ROOT_DIR and BMI_INCLUDES constants. The value of BMI_ROOT_DIR is determined by the value of content-dir in the request header. The value of BMI_INCLUDES is determined by splicing “includes” from BMI_ROOT_DIR. become.

Then go down and find that BMI_INCLUDES is used to splice with “bypasser.php” and include the file through the require_once function. It can be seen that the parameters of require_once are controllable and it is a typical file inclusion vulnerability.

Continue to think about how to further utilize file inclusion to achieve code execution.

  • File included into code execution

In some encodings, there will be a fixed prefix as the beginning of the characters of the encoding. The following are the encoding preset characters of some encodings.For example, in Korean character encoding (ISO-2022-KR), the encoded message must start with the sequence “\x1b$)C”

Encoding identifier Prepended characters
ISO2022KR \x1b$)C
UTF16 \xff\xfe
UTF32 \xff\xfe\x00\x00

There are nearly 7,000 languages ​​in the world. In order for people around the world to interact with information on the Internet, different printable characters must be used. We are all familiar with the basic ASCII encoding table, but this table is very limited and cannot express Japanese, and cannot even include characters such as “λ”, “ν”, and “π” in Greek. Therefore, many different encoding tables were created in order to be able to display characters from other languages, even the emoji “☺”. These encoding tables can convert characters from one language to another, but the conversion process will be affected by factors such as encoding length and preceding characters, and may even generate new characters.

On the host, we can view the supported encoding conversion table through iconv -l

These conversion tables can be used through php://convert.iconv.*.* filters. For example, convert.iconv.CP861.UTF-16 means to convert the character encoding of the file from CP861 to UTF-16. The following code is an example. By converting the string “START” to 'CP861', 'UTF16', 'L4', and 'GB13000' encoding, a new character 'B' can finally be inserted in front of the string.

So how to deal with the garbage characters generated during encoding conversion? Base64 decoding in PHP has a feature. Its decoding only recognizes 64 characters of '0-9', 'az', 'AZ', '/', and '+'. and the padding character '='. If the string to be decoded contains other characters, PHP will directly ignore these characters and concatenate the remaining recognized characters for decoding.as follows

It can be seen that the '@&>>_' mixed in the string during decoding is directly ignored. The garbage characters we generate during the encoding conversion process can be eliminated using a loose parsing method such as base64. It should be noted that if '=' is generated among these garbage characters, this will affect the characters decoded by the convert.base64-decode filter. You can use UTF7 encoding to convert the '=' sign into other symbols without affecting convert. .base64-decode filter decoding.

Through the above method, we can generate arbitrary base64 characters, and then base64 decode the generated base64 characters to obtain any original characters. Finally, the original payload will be constructed and spliced ​​with php://filter/{filter}/resource=php://temp (after specifying resource=php://temp, any .php file can be spliced ​​to ensure that the path is valid) , write the payload to the file, and finally implement the file inclusion into code execution through require_once reference.

In github, an author has written a coding conversion tool that can quickly use php://convert.iconv.*.* filters to generate corresponding base64 characters.

Send the request using the payload generated by this script as the value of the request header content-dir.

It can be seen that the malicious code generated after encoding conversion was successfully written and included by reference, completing the process from file inclusion to code execution.

Built locally using wordpress6.4.3+ Backup Migration Plugin 1.3.6. Use the php_filter_chain tool to generate payload code for the out.txt`; ?> command. (https://github.com/synacktiv/php_filter_chain_generator/blob/main/php_filter_chain_generator.py)

Copy the result as the value of content-dir in the request header and send the data packet under the path http://localhost/wordpress/wp-content/plugins/backup-backup/includes/backup-heart.php.

Visit http://localhost/wordpress/wp-content/plugins/backup-backup/includes/out.txt. It can be seen that the execution result of the system command date has been written into the out.txt file.

The latest Backup Migration Plugin version has fixed this problem. Use the latest version of the Backup Migration Plugin in a timely manner.

Wangsu's full-site protection-WAF module has supported the protection against exploit attacks for the first time, and continues to explore and analyze other variant attack methods and various component vulnerabilities, and launch protection rules as soon as possible to shorten the protection “window period”.

Based on edge nodes widely distributed around the world, relying on more than 10 years of security operations and massive attack and defense data, “Wangsu Security” builds an intelligent security protection system from edge to cloud, providing DDoS protection, Web application protection, crawler management, and remote access secure access. , secure SD-WAN, host security and other comprehensive security products and services, covering cloud security, enterprise security and security services and other fields, helping enterprises build a new security architecture based on zero trust and Secure Access Service Edge (SASE) model to escort Cybersecurity protects the digital age. Wangsu Technology (300017) was founded in 2000 and was among the first to be listed on the GEM in 2009. It is the world's leading edge computing and security service provider, with operations in more than 70 countries and regions around the world. The company has always been committed to improving users’ digital experience and meeting their needs for safe and reliable data processing and interaction anytime, anywhere.

What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *

GIPHY App Key not set. Please check settings

N-days Chaining Vulnerability Exploitation Analysis Part 3: Windows Driver LPE–Medium to System

In-depth analysis | Mirai new sample: new camouflage method makes it harder to identify