Gantry Web Theme Framework 4.1.3 Vulnerability

April 9, 2015

I noticed a minor potential security vulnerability in the Gantry Web Theme Framework for WordPress. This allows arbitrary code to be executed remotely, fortunately it requires a WordPress account (does not have to be admin) and also requires some crafty building of JSON text to pass through.

By POSTing an AJAX request with action=gantry_admin&gantry_action=widgets-mass-actions you can get into this chunk of code.

It took some really complicated building of the $_POST[‘data’] JSON to get all of the quotes balanced, but it is possible to get that code executed by eval().

All of the other AJAX functions appear to check a nonce and current_user_can() so they are secure, this function initially pushed this authorization into the gantry_widgets_save() function which would get called after the JSON is decoded.

The lesson here is to always do your authorization as early as possible.

Timeline

3/4/2015 Sent request via web form with details
3/5/2015 2:26am Response received saying details forwarded to development team
3/10/2015 Updated version released

All-in-One WP Migration 2.0.4 Security Vulnerability

by James Golovich

March 19, 2015

There is a serious security vulnerability in All-in-One WP Migration version 2.0.4. Update immediately. This vulnerability can allow users without any authentication to export a copy of your database, plugins, themes, and uploaded files.

My story

It wasn’t supposed to happen like this. I was setting up a couple of test servers for a project I’m working on and I wanted to be able to backup and move the data around easily. Why not try out one of the tools designed to do this rather than roll my own?

I found All-in-One WP Migration, with 40,000+ installs it should be solid. Of course, I couldn’t just install it and use it as is. I had to pull back the curtain and take a peek.

At first, I saw our familiar friend AJAX without proper protection, but the import call actually checked permission. The other exposed AJAX calls couldn’t really do anything useful/threatening.

Then I noticed this little gem:

Could be benign as long as it’s called from some place that has some form of authorization. Unfortunately it is called from the ‘init’ action.

Luckily the import function is protected so you can’t make any changes, but there is plenty of fun stuff that can be exported.

Just having access to the database should be enough to panic any site administrator, but having all of the uploads, themes, and plugins bundled up in a zip file is terrifying.

I will not distribute a PoC for this. Please upgrade your sites immediately!

Vendor Response

ServMask was very quick to respond and was planning on releasing an update asap. I suggested they contact plugins@wordpress.org and see if there is the possibility to have the plugin force updated like the Yoast WordPress SEO plugin update was last week.

Timeline

3/12/2015 2:40pm Vendor contacted
3/12/2015 2:47pm Vendor response
3/14/2015 Update released on wordpress.org

esc_sql Doh! WordPress SQL Injection Vulnerability

by James Golovich

March 16, 2015

Update: This is not about a specific vulnerability, but a series of vulnerabilities due to trusting the use of a sanitizing function in a situation where it should not be used.

WordPress has a number of data sanitizing functions. esc_sql is one of them and it is frequently used, when used the way it was intended it performs perfectly. Unfortunately some of us developers assumed that esc_sql was magic and would sanitize anything related to SQL queries.

Fortunately the codex has been updated to make it more obvious.

Here is a screenshot of the previous codex page taken from the Internet Archive Wayback Machine

Here is the most recent version:

The function was designed to sanitize user data that is used within query strings of SQL statements. It basically escapes quotes in the string so user input cannot break out of the string.

So the string:

username’; DROP TABLES wp_users;

becomes:

username\’; DROP TABLES wp_users;

which makes for a terrible username, but SQL doesn’t execute the command: DROP TABLES wp_users;

D’oh

When the esc_sql function is used to sanitize data that is not inside quoted strings, it’s pretty much useless. Many developers (myself included) used and overlooked it’s use in this fashion. We look at the function name and assume that it is fine for sanitizing any data that is used in a SQL string. $wpdb->prepare should be used in almost every case unless it’s just not possible to do so.

Here is an excerpt from the Pods advisory that I helped with that shows the input and how it ends up getting passed to SQL even though esc_sql() was called on it.

For other examples of how this has been mis-used, check the advisory links below.

In almost all of the cases reported so far, this specific SQL Injection Attack is secured behind the admin interface because the orderby SQL command is used to sort list of things in those places and the admin page trusts the user enough to do no harm.

As always, an administrator should not click links from untrusted sources (or even trusted people). Use an account with the highest credentials as little as possible, you should be posting as a user with lower privileges, and only login as the highest level account when you need to do actual administrator type things.

First Contact

As far as I can tell Ryan Dewhurst of Dewhurst Security and the WPScan Team was the first to discover and document this. Since then numerous people have detected and reported other issues. At this time I have not heard of any of these vulnerabilities being used in the wild.

Plugins with known (and fixed) esc_sql issues

I’d like to keep this list up to date, I’ll add to it as I hear about more issues or send me a message @Pritect

Props to all of the developers for taking these issues seriously and getting fixes out asap. It’s easy to blow the severity of these issues out of proportion, so let’s try not to let it get out of hand.