Home » Archives for James Golovich » Page 10

Author: James Golovich

Custom Field Suite 2.4 Security Vulnerability

Recently I was looking at the Custom Field Suite plugin. I’d never used it before and as always before using it I had to quickly go through the code to find an obvious security issues.

cfs-ajax1

The frequent offender AJAX jumped out at me. Luckily this is not the ‘nopriv’ type, so an attacker would have to have an account on the WordPress site, but any basic account will work.

cfs-ajax2

  • Import custom fields
  • Export custom fields
  • Search for posts by title (via includes/fields/ajax.php:search_posts() )

The only AJAX function that was secured was ‘reset’ which would remove everything CFS related from the database and deactivate the plugin.

With all the awesome stuff that CFS can do, I’m sure an attacker could find something fun to do once they can export your setup and re-import it.

Matt was quick to respond and get a new version out there. Here is the Changelog. I recommend everyone update immediately.

Timeline

  • 3/3/2015 12:45pm Initial disclosure email
  • 3/3/2015 12:59pm Response and issue fixed in github.com
  • 3/4/2015 Updated version (2.4.1) released on wordpress.org

Tweet Wheel 0.3 Security Vulnerability

I was looking for a WordPress plugin that would add some Twitter functionality to my website last week. I ran across Tweet Wheel from Nerd Cow (awesome name BTW!)

I personally can’t use a plugin that I haven’t at least done a quick inspection on the code so I took a look and saw a minor AJAX issue. One that wouldn’t even stop me from using the code unfixed in this specific case, because nobody besides me has access to the site.

Props to Thomasz Lisiecki for taking security seriously and getting an updated version out right away, even on such a minor issue. Changelog posted here

tweetwheel-ajax

Fortunately, none of the actions are ‘nopriv’ so you at least require a valid WordPress user account to use the functionality.

tweetwheel-ajaxtweet

Of all of the actions, this was the worst and it is pretty minor. The result would just be spamming Twitter with the same tweets over and over. Without further access you can’t even adjust what the Tweet says.

Timeline

  • 3/1/2015 11:43am Initial disclosure email sent
  • 3/1/2015 11:46am Reply received
  • 3/4/2015 Plugin updated on wordpress.org

IgnitionDeck 1.1.6 Vulnerability

Yesterday I noticed this tweet from IgnitionDeck ignitiontweet

I’d never heard of them before so I decided to take a quick look at their page and see what code was available to look at. They have several paid plugins but also a free plugin on wordpress.org.

I spent a couple minutes looking at the code while I was eating breakfast. Right away I noticed a couple of issues and sent off an email. They were quick to respond and within a few hours had released an update version.

Analysis

One of the first things I search for is AJAX handlers, often developers forget to verify if the user is actually allowed to do the action especially if the page that links to the action is behind an admin interface that requires a login.

Here a simple POST lets an un-authenticated user change the active theme.

ignitiontheme

This one lets an un-authenticated user activate an installed plugin. Right away I thought some directory traversal would be fun, but since the same variable is used for the directory and filename it won’t work.

ignitionextension

Next up I noticed a function that runs during the ‘init’ action that acts on user input.

ignitionaddmedia

If ‘create_project’ or ‘edit_project’ are passed as GET variables or in the HTTP_REFERER then idc_add_upload_cap is called. This would of course require the user to be logged in.

ignitionuploadcap

Look at all those fun capabilities we’ve got now. The capabilities will be removed by the idc_remove_upload_cap() function call if the variables aren’t passed.

 
Please developers, trust but verify!