The WordPress Backup Migration Plugin is a powerful tool for simplifying the backup and migration process of WordPress websites, offering a range of easy-to-use features.
Recently, CDNetworks Security Lab discovered a remote code execution vulnerability in versions of the Backup Migration plugin older than 1.3.8. This vulnerability has been rated 9.8 in CVSS 3.1 with a critical danger level. It allows malicious attackers to remotely execute commands on the target website via backdoor access, thereby gaining complete control of the site.
The conditions for exploiting this vulnerability are relatively straightforward but have wide-ranging impacts. To prevent exploitation, enterprises should check the version of this plugin and fix the relevant vulnerabilities or, even better, introduce web protection solutions.
In this quick guide, we run through an analysis of the vulnerability.
Vulnerability Analysis & Replication
The vulnerability exists in the plugin file /includes/backup-heart.php. The first step to replicating this vulnerability is to locate this file and set a breakpoint. You then perform dynamic debugging by sending data to the path /wp-content/plugins/backup-backup/includes/backup-heart.php. When the server receives the data, it is found that the request header data is stored in the variable $fields.
Continuing further, we can see that the field values in $fields are defined as constants. The main focus here is on the constants BMI_ROOT_DIR and BMI_INCLUDES. The value of BMI_ROOT_DIR is determined by the content-dir value in the request header, and the value of BMI_INCLUDES is formed by concatenating BMI_ROOT_DIR with “includes”.
Additionally, it is found that BMI_INCLUDES is concatenated with “bypasser.php” and included using the require_once function. As a result, the parameter of require_once is controllable, making this a typical file inclusion vulnerability.
In some encodings, a fixed prefix is used as the starting character of the encoding. Below are characters for different encodings. For example, in Korean character encoding (ISO-2022-KR), the encoded message must begin with the sequence “\x1b$)C”.
| Encoding Identifier | Prepended Characters |
| ISO2022KR | \x1b$)C |
| UTF16 | \xff\xfe |
| UTF32 | \xff\xfe\x00\x00 |
There are almost 7,000 languages spoken worldwide. Various printable characters are necessary to facilitate global internet communication.
The basic ASCII encoding table is well-known, but it has limitations. It cannot express Japanese characters or include symbols such as “λ”, “ν”, “π” from the Greek alphabet. To display characters from other languages and emojis like “☺”, various encoding tables have been developed.
These encoding tables can convert characters from one language to another. The conversion process is affected by factors such as encoding length, and prefix characters and may even generate new characters.
On the host, we can use iconv -l to view the supported encoding conversion tables.
These conversion tables can be used via the php://convert.iconv.*.* filter. For example, convert.iconv.CP861.UTF-16 means converting the file’s character encoding from CP861 to UTF-16.
In the following code example, by converting the string “START” through ‘CP861’, ‘UTF16’, ‘L4’, and ‘GB13000’ encodings, it is possible to insert a new character ‘B’ at the beginning of the string.
So how do we handle the junk characters generated during encoding conversion? In PHP, base64 decoding has a feature where it only recognizes the 64 characters ‘0-9’, ‘a-z’, ‘A-Z’, ‘/’, ‘+’, and the padding character ‘=’. If the string to be decoded contains other characters, PHP will directly ignore these characters and concatenate the remaining recognizable characters for decoding. For example:
As you can see, during decoding, characters such as ‘@&>>_’ in the string are automatically ignored. We can use the loosely parsed base64 decoding to eliminate junk characters generated during the encoding conversion process. It is important to note that if the junk characters include ‘=’, which can affect the decoding of the convert.base64-decode filter, we can use UTF-7 encoding to convert the ‘=’ sign into another symbol without affecting the decoding of the convert.base64-decode filter.
Using the above method, we can generate arbitrary base64 characters. After decoding the generated base64 characters, we can obtain any original characters. Finally, we concatenate the constructed original payload with php://filter/{filter}/resource=php://temp (specifying resource=php://temp allows appending any .php file to ensure the path is valid). The payload is written to a file, and by including the file using require_once, we achieve file inclusion to code execution.
On GitHub, an author has written an encoding conversion tool that can quickly use the php://convert.iconv.*.* filter to generate the corresponding base64 characters.
The payload generated by this script is set as the value of the request header content-dir.
It is evident that the malicious code generated after the encoding conversion is successfully written and included, completing the process from file inclusion to code execution.
Set up locally using WordPress 6.4.3 + Backup Migration Plugin 1.3.6. Use the php_filter_chain tool to generate the payload code for the <?php \date > 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 the content-dir in the request header and send the data packet to the path http://localhost/wordpress/wp-content/plugins/backup-backup/includes/backup-heart.php.
Access http://localhost/wordpress/wp-content/plugins/backup-backup/includes/out.txt. Which will allow you to see that the execution result of the system command date has been written into the out.txt file.
Vulnerability Remediation Solution
The latest version of the Backup Migration Plugin has fixed this issue, and we recommend updating to the latest version as soon as possible.
Minimizing Vulnerability: CDNetworks’ Cloud Security 2.0
CDNetworks’ Cloud WAF provides immediate protection against this vulnerability exploitation. It continuously investigates and analyzes other variant attack methods and various component vulnerabilities, promptly deploying protection rules to minimize the “window of vulnerability” for businesses.
In a recent month, CDNetworks upgraded its Cloud Security solution to Cloud Security 2.0, introducing several key features of WAF:
- Built-in Ruleset: Over 1,000 rulesets for 0-day/N-day and OWASP Top 10 attacks.
- Intelligent Analysis (Self-Tuning): AI-driven learning of user behaviors, automatically generating rule exceptions to reduce false positives.
- Virtual Patch for 0-day Attacks: Continuous monitoring of vulnerabilities, generating new rules hourly.
- Managed Protection Mode with AI Tech: Enhanced threat detection and response.
- Scalability and Ease of Deployment: Scaling on demand with easy deployment.
By integrating these features, CDNetworks aims to meet the evolving security needs of businesses in the APAC region, ensuring organizations remain protected in a competitive market.
