Simple Download Monitor 3.2.8 Security Vulnerability

by James Golovich

The WordPress plugin Simple Download Monitor has a few security vulnerabilities that allows unauthenticated users to list all uploaded files, delete thumbnails associated with them, and uploaded files with password protection can be download without entering a password.

As of 1/19/2016 the wordpress.org information says there are 10,000+ active installs of this plugin.

The vendor Tips and Tricks HQ has released version 3.2.9 to resolve this issue.

List all uploaded files

Unauthenticated AJAX allows any user to access the ‘sdm_tiny_get_post_ids’ action which will return a JSON encoded list of all ‘post_id’ and ‘post_title’ that were uploaded with the Simple Download Monitor plugin. In many cases these files are publicly visible already so this isn’t a major security issue in most cases.

sdm_ajax_list

Delete thumbnails

Unauthenticated AJAX calls again allow any unauthenticated user to delete thumbnail images that were added using this plugin via the ‘sdm_remove_thumbnail_image’ action.

sdm_ajax_delete

Download files without password protection

This is the biggest security issue here, they do provide an AJAX command that verifies the post password to allow downloading the file but there is also this backdoor method to access the file that can be used without any password verification. Though the access is logged if logging is enabled.

sdm_view_init

Early on by the ‘init’ action the handle_sdm_download_via_direct_post() function is called. Which then takes the supplied ‘download_id’ and retrieves the post containing a file.

sdm_download_part1

After the bit of logging it finally happily redirects the user to the proper download URL.

sdm_download_part2

One additional note, these files are not actually password protected, just the posts that contain them. So if someone has the direct URL to a file they can download it without any further authorization.

It’s always wise to ensure that any request is properly authorized.

Timeline

  • 1/12/2016 2:16pm Initial contact email sent to find appropriate security/developer contact
  • 1/12/2016 10:16pm Vendor responds with contact information
  • 1/13/2016 10:16am Complete disclosure sent
  • 1/14/2016 7:31pm Vendor reply stating they are working on issue and requested more information
  • 1/16/2016 7:37pm Vendor reply stating a new version has been released

WP Ultimate CSV Importer 3.7.1 Critical Vulnerability

by James Golovich

WP Ultimate CSV Importer plugin also available free on wordpress.org allows direct calling to code that can read files on the filesystem without authorization. The WordPress plugin directory reports there are 10,000+ active installs of this plugin.

This is a very serious issue that allows unprotected read access to any file that the user running php has access to.

wpultimatecsvimporter

templates/readfile.php can be called directly to read any file via directory traversal. You would have to iterate over each line in the file, but that is a trivial task.

On 3/30/2015 a new version was released to fix this issue. Here is the new code.

wpultimatecsvimporter1

Unfortunately, that just added a tiny road bump to the issue. Since ‘HTTP_REFERER’ is trivial to set, you just need to do a bit more work to include that as well and it is easily scriptable.

wpultimatecsvimporter-readfile

Here is the final fix added.  Which does what is essentially the commonly recommended WordPress security practice of not allowing a script to be called directly.

wpultimatecsvimporter-security

In almost every case there is no reason to allow code to be called directly. If you have the WordPress tools available to you then you should use them. Something like current_user_can() and a nonce should always be used.

Timeline

  • 3/26/2015 12:30am Sent inital contact to vendor
  • 3/26/2015 4:16am Email received from “Sales” requesting more info
  • 3/26/2015 8:49am Vulnerability information sent to vendor
  • 3/26/2015 9:15am Vendor says information forwareded to developer
  • 3/30/2015 9:38am Vendor notified that the issue is resolved in version 3.6.78
  • 4/14/2015 10:20am In preperation to post, determined that their fix was insufficient.  Re-contact vendor
  • 4/16/2015 7:42am Re-contact vendor to check status
  • 4/16/2015 9:14pm Vendor replied saying they are working on it and would follow up when resolved (they never did)
  • 4/20/2015 Version 3.7.1 released

EDD Upload File 1.0.3 Security Vulnerability

by James Golovich

The premium extension EDD Upload File for Easy Digital Downloads has a major security vulnerability in version 1.0.3 that was fixed in version 1.0.4. I’m not sure how many active installs there are of this plugin. If you are running version 1.0.3, upgrade immediately. This version allows someone to delete files, upload files, and potentially execute PHP code via those uploaded files.

As I’ve discussed previously, Easy Digital Downloads allows any WordPress action/filter that begins with ‘edd_’ to be called remotely and each function is supposed to do the authorization.

This gives us the opportunity to do two evil things in the EDD Upload File code.

Delete any file

eddupload-delete

By calling GET ‘edd_action=upload_file_delete’ we get into this chunk of code and you can pass a ‘delete-file’ to specify a file to delete. The user running the PHP code would need appropriate permissions on the file in order to delete. The directory base is get_temp_dir() but you can use directory traversal to get out of there.

Upload arbitrary files

eddupload-uploadWith the ‘edd_payment_receipt_before’ action we are able to upload arbitrary files. If the administrator setup extensions to allow then it would restrict files to be uploaded, but by default there isn’t any setup.

The files are renamed with a unique filename, presumably to eliminate conflicting filenames but also for a bit of security. Unfortunately, it uses uniqid() which isn’t very secure especially if we know the time the upload happens (or close enough).

Guessing the filename uploaded with uniqid() would be pretty easy, but in this version you don’t even have to do that because of another bug.

eddupload-createdir

The code always checks to make sure the upload directory exists and if not it creates it as well as inserting a ‘index.php’ and ‘.htaccess’ to try to keep the webserver from listing the directory contents. Unfortunately in this case it is missing a ‘/’ so the index.php created would be something like ‘wp-content/uploads/edd-upload-filesindex.php’.

As I always recommend it is wise to keep your webserver from allowing directory listings in these directories as well as executing php/cgi from the uploads directory. In a default configuration it is trivial for someone to upload arbitrary php files and execute them remotely without any authorization.

Timeline

  • 2/26/2015 1:12am Initial disclosure
  • 2/26/2015 1:39am Developer response
  • 3/17/2015 Updated version released