Tag: wordpress

esc_sql Doh! WordPress SQL Injection Vulnerability

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.

Ultimate Member Plugin 1.0.78 Critical Security Vulnerability

by James Golovich

March 16, 2015

While sitting and waiting for my daughter at gymnastics several weeks ago I noticed an announcement for Ultimate Member plugin, sounded interesting so I bookmarked it to check out later.

Fast forward till last week when I noticed it sitting there and decided to take a look at it. I noticed a couple security issues and contacted the developers.

There were a few minor issues that they fixed, but the major ones are critical. If you are using this plugin, Update Immediately!

Delete any file

We’ve got an un-authenticated AJAX action to delete files here.

We definitely need some authorization on the user and/or the specific file to be deleted there when the AJAX call comes in.

Well at least delete_file() is calling um_is_temp_upload() to make sure the file is a temporary file.

Uh-oh. It’s only pulling ‘/ultimatemember/temp/’ off the beginning. So it will happily take ‘../’ in the path and you can use it to delete any file that the user running php has permissions for.

Upload arbitrary files

Multiple issues all come together to make this especially evil.

First off, the um-file-upload.php can be called directly and it bootstraps WordPress. I’d rather send every request through WordPress and not allow direct access to anything.

Then we call check_file_upload() and only move the file if it doesn’t return an error.

Cool, check_file_upload() at least checks for allowed extensions from an array. So if I try to upload something ending in .php it sets ‘$error = $data[‘extension_error’]; Here’s the rub, since user input is passed into check_file_upload(), get_field($field) call will return null if $field is some invalid field. So the end result is check_file_upload() is going to return null;

Now we’ve got a file uploaded and it even kicks back the full path that you need to call the file. Assuming the host will allow code execution from the uploads directory, you can now run code as the user running php.

Timeline

3/9/2015 Issues discovered
3/10/2015 Developer contacted
3/10/2015 Delete file issue fixed in Ultimate Member version 1.0.79
3/13/2015 Followup describing how the upload issue still worked
3/13/2015 Issue resolved in Ultimate Member version 1.0.84

Custom Field Suite 2.4 Security Vulnerability

by James Golovich

March 12, 2015

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.

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.

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