Our Proactive Monitoring Caught a Remote Code Execution (RCE) Vulnerability in the WordPress Plugin PropertyHive
With the recently widely exploited WordPress plugin WP GDPR Compliance there were two serious vulnerabilities that were fixed before one of them was widely exploited, there was also another issue that was fixed and brought up in passing at the time, but we were left unclear as the seriousness of, that being ability to pass arbitrary values to the do_action() WordPress function. We really should put a post on what we found when we went to look further in to that, but the short version is that it looks like at least with what code you can cause to execute from WordPress, that this is threat looks to be somewhat limited and even more limited if user input is only used to specify the action to be executed and not additional arguments. But in any case that type of issue would be a remote code execution (RCE) vulnerability, so we updated a check included in our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities and Plugin Security Checker to spot possible instances of that type of vulnerability. That led to us spotting an instance of the vulnerability in the plugin PropertyHive through our proactive monitoring.
This vulnerability has been in the plugin for 18 months without being noticed before.
You can check if plugins you use possibly have the same issue or a number of other possible security issues with the previously mentioned Plugin Security Checker.
Due to the moderators of the WordPress Support Forum’s continued inappropriate behavior we are full disclosing vulnerabilities in protest until WordPress gets that situation cleaned up, so we are releasing this post and then only trying to notify the developer through the WordPress Support Forum. 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).
Technical Details
The plugin makes the function run_custom_email_log_cron() accessible to anyone as it runs during admin_init, which occurs when accessing the right page even if someone is not logged in to WordPress (in the file /includes/class-ph-emails.php):
74 | add_action( 'admin_init', array( $this, 'run_custom_email_log_cron' ), 10, 1 ); |
The code in that will pass the value of the GET input “custom_email_log_cron” through do_action() if that input exists:
77 78 79 80 81 82 83 | public function run_custom_email_log_cron() { if( isset($_GET['custom_email_log_cron']) ) { do_action($_GET['custom_email_log_cron']); } } |
Proof of Concept
The following proof of concept will cause the WordPress action/function do_feed_rss to run.
Make sure to replace “[path to WordPress]” with the location of WordPress.
http://[path to WordPress]/wp-admin/admin-post.php?custom_email_log_cron=do_feed_rss
I’ve run across this kind of issue before, and done some research on it. You are correct that it is more useful in cases when you can pass arguments to the called action as well, and I’ve seen instances where that is the case. I don’t know if there are major avenues of exploitation of this kind of vulnerability in WP core, but some plugins’ code is designed in a way that this type of vuln can be very useful. It can sometimes be used to harvest nonces that otherwise you wouldn’t be able to access, for example. Then you can use the nonce to perform another action, if proper capability checks are not also in place. Other information disclosure issues are also exploitable through this in some cases. Then of course sometimes there are other more serious actions that can be performed.
The takeaway is that anytime a function is hooked to an action, it probably ought to check user caps if necessary, and also should require an nonce in that case. It can’t just assume that the action will only be called under the right conditions. That way even if another plugin does something silly like this, your plugin’s code would still be safe.
That also brings to mind the idea that this type of vuln could be combined with CSRF in cases where a function hooked to an action did include a cap check but not a nonce check.