WordPress Plugin Backup Migration Provides Anyone Access to its Backups
The changelog for the latest release of the WordPress plugin Backup Migration indicates that there was security improvement:
Added secret keys for restore process – should be much more secure now
Our monitoring systems notified us of that and we went to check if there was a vulnerability being fixed that we should be notifying customers of our service that were using that plugin about. Instead, we found that the plugin is very insecure and among other issues, allows anyone to download the backups made by the plugin.
After you have completed making a backup through the plugin, it provides you a link to download logs. The address for that is in this format:
/?backup-migration=PROGRESS_LOGS&progress-id=latest.log&backup-id=current&t=1626459661769
It wasn’t clear what the “t” parameter in that was for, but it could have been a unique value to required for the URL to work. That turned out to not be the case, as removing it had no impact on viewing the log file. The much larger issue is that you didn’t even need to be logged in to WordPress to view it.
That log file provided various non-public information, include the full name of database tables and the full file path for the website.
When viewing another of the log files through that you can get the unique name of the backup file created:
/?backup-migration=PROGRESS_LOGS&progress-id=complete_logs.log&backup-id=current
That is a big problem, as if you know that you can download the backup file by specifying it as the “backup-id” parameter with the address to download a backup:
/?backup-migration=BMI_BACKUP&backup-id=
That seems so obviously insecure that we thought maybe we were missing something there, so we checked on the underlying code and confirmed that the code is really that insecure. This in a plugin with 10,000+ installs.
The insecure code has been there since the plugin was included in to the WordPress Plugin Directory, which means it got past the security review that is supposed to be happening with new plugins. That is really troubling since backup plugins are well known to be a big security concern.
Underlying Code
The function that handles that is handle_downloading(), which is located in the file /includes/initializer.php, which runs during “init”, so when any WordPress page loads:
89 | add_action('init', [&$this, 'handle_downloading']); |
The first code in that function doesn’t include any security checks:
644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 | public function handle_downloading() { global $wpdb; @error_reporting(0); $autologin_file = BMI_BACKUPS . '/.autologin'; $ip = '127.0.0.1'; if (isset($_SERVER['HTTP_CLIENT_IP'])) { $ip = $_SERVER['HTTP_CLIENT_IP']; } else { if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { $ip = $_SERVER['HTTP_X_FORWARDED_FOR']; } if ($ip === false) { if (isset($_SERVER['REMOTE_ADDR'])) $ip = $_SERVER['REMOTE_ADDR']; } } $allowed = ['BMI_BACKUP', 'BMI_BACKUP_LOGS', 'PROGRESS_LOGS', 'AFTER_RESTORE']; $get_bmi = !empty($_GET['backup-migration']) ? sanitize_text_field($_GET['backup-migration']) : false; $get_bid = !empty($_GET['backup-id']) ? sanitize_text_field($_GET['backup-id']) : false; $get_pid = !empty($_GET['progress-id']) ? sanitize_text_field($_GET['progress-id']) : false; if (isset($get_bmi) && in_array($get_bmi, $allowed)) { if (isset($get_bid) && strlen($get_bid) > 0) { $type = $get_bmi; |
Then different code runs depending on the value of the GET input “backup-migration”.
Here is the code for downloading the backup:
700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 | } else if ($type == 'BMI_BACKUP') { if (Dashboard\bmi_get_config('STORAGE::DIRECT::URL') === 'true' || current_user_can('administrator')) { $backupname = $get_bid; $file = $this->fixSlashes(BMI_BACKUPS . DIRECTORY_SEPARATOR . $backupname); if (Dashboard\bmi_get_config('OTHER:DOWNLOAD:DIRECT') == 'true') { if (file_exists(BMI_BACKUPS . DIRECTORY_SEPARATOR . '.htaccess')) @unlink(BMI_BACKUPS . DIRECTORY_SEPARATOR . '.htaccess'); if (file_exists(dirname(BMI_BACKUPS) . DIRECTORY_SEPARATOR . '.htaccess')) @unlink(dirname(BMI_BACKUPS) . DIRECTORY_SEPARATOR . '.htaccess'); $wpcontent = trailingslashit(WP_CONTENT_DIR); $wpcs = strlen($wpcontent); $url = content_url(substr($file, $wpcs)); $path = wp_redirect($url); exit; } // Prevent parent directory downloading if (file_exists($file) && $this->fixSlashes(dirname($file)) == $this->fixSlashes(BMI_BACKUPS)) { ob_clean(); @ignore_user_abort(true); @set_time_limit(16000); @ini_set('max_execution_time', '259200'); @ini_set('max_input_time', '259200'); @ini_set('session.gc_maxlifetime', '1200'); @ini_set('memory_limit', '-1'); if (strlen(session_id()) > 0) session_write_close(); if (@ini_get('zlib.output_compression')) @ini_set('zlib.output_compression', 'Off'); $fp = @fopen($file, 'rb'); // header('X-Sendfile: ' . $file); // header('X-Sendfile-Type: X-Accel-Redirect'); // header('X-Accel-Redirect: ' . $file); // header('X-Accel-Buffering: yes'); header('Expires: 0'); header('Pragma: public'); header('Cache-Control: must-revalidate, post-check=0, pre-check=0'); header('Content-Disposition: attachment; filename="' . $backupname . '"'); header('Content-Type: application/octet-stream'); header('Content-Transfer-Encoding: binary'); header('Content-Length: ' . filesize($file)); header('Content-Description: File Transfer'); http_response_code(200); if (ob_get_level()) ob_end_clean(); fpassthru($fp); fclose($fp); exit; } } else { ob_clean(); header('HTTP/1.0 423 Locked'); if (ob_get_level()) ob_end_clean(); echo __("Backup download is restricted (allowed for admins only).", 'backup-backup'); exit; } |
And the code for logs up through the log that provides the name of the backups:
784 785 786 787 788 789 790 791 792 793 794 795 796 | } elseif ($type == 'PROGRESS_LOGS') { $allowed_progress = ['latest_full.log', 'latest.log', 'latest_progress.log', 'latest_migration_progress.log', 'latest_migration.log', 'complete_logs.log', 'latest_migration_full.log']; if (isset($get_pid) && in_array($get_pid, $allowed_progress)) { header('Content-Type: text/plain'); header('Cache-Control: must-revalidate, post-check=0, pre-check=0'); http_response_code(200); ob_clean(); if ($get_pid == 'complete_logs.log') { $file = BMI_CONFIG_DIR . DIRECTORY_SEPARATOR . 'complete_logs.log'; if (ob_get_level()) ob_end_clean(); readfile($file); exit; } |
They are also lacking security code.
WordPress Causes Full Disclosure
Because of the moderators of the WordPress Support Forum’s continued inappropriate behavior we changed from reasonably disclosing to full disclosing vulnerabilities for plugins in the WordPress Plugin Directory in protest, until WordPress gets that situation cleaned up, so we are releasing this post and then leaving a message about that for the developer through the WordPress Support Forum. (For plugins that are also in the ClassicPress Plugin Directory, we will follow our reasonable disclosure policy.) You can notify the developer of this issue on the forum as well. Hopefully, the moderators will finally see the light and clean up their act soon, so these full disclosures will no longer be needed (we hope they end soon). You would think they would have already done that, but considering that they believe that having plugins, which have millions installs, remain in the Plugin Directory despite them knowing they are vulnerable is “appropriate action”, something is very amiss with them (which is even more reason the moderation needs to be cleaned up).
Update: To clear up the confusion where developers claim we hadn’t tried to notify them through the Support Forum (while at the same time moderators are complaining about us doing just that), here is the message we left for this vulnerability:
Is It Fixed?
If you are reading this post down the road the best way to find out if this vulnerability or other WordPress plugin vulnerabilities in plugins you use have been fixed is to sign up for our service, since what we uniquely do when it comes to that type of data is to test to see if vulnerabilities have really been fixed. Relying on the developer’s information can lead you astray, as we often find that they believe they have fixed vulnerabilities, but have failed to do that.