Home » Archives for James Golovich » Page 9

Author: James Golovich

All-in-One WP Migration 2.0.4 Security Vulnerability

by James Golovich

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:

controller

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.

allinone-router

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

allinone-cap

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

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

escsqldoh-codex

Here is the most recent version:

escsqldoh-codex2

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.

escsqldoh-pods

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

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.

ultikmate-delete

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

ultimate-delete2

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

ultimate-delete3

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.

ultimate-fileexecFirst 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.

ultimate-fileexec1

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

ultimate-fileexec2

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;

ultimate-fileexec3

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