27 Oct

Vulnerability Details: SQL Injection Vulnerability in Ultimate Form Builder Lite

From time to time a vulnerability is fixed in a plugin without the discoverer putting out a report on the vulnerability and we will put out a post detailing the vulnerability so that we can provide our customers with more complete information on the vulnerability.

Recently Wordfence made an under-sourced claim that there was a zero-day vulnerability in the plugin Ultimate Form Builder Lite. ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

07 Jul

Wordfence’s Lack of Understanding of SQL Injection Vulnerabilities Leads to False Claim About WP Statistics Vulnerability

Yesterday we touched on how the web security company Sucuri and others in the security community were overstating the threat of a vulnerability recently discovered by Sucuri in the plugin WP Statistics. While looking over something else related to that vulnerability we came across the web security company Wordfence using that vulnerability basically as an ad for their products and services, while reminding people that are actually knowledgeable  about web security that Wordfence really don’t have a good grasp of it.

Their post starts out:

It’s been a tough week for the WP Statistics plugin. Last Friday, Sucuri (now owned by GoDaddy) discovered a SQL injection vulnerability in the WP Statistics plugin version 12.0.7 and older. To exploit the vulnerability, an attacker needs to register an account (or use a compromised account) with subscriber-level access. They can then exploit a weakness in a WP Statistics shortcode to launch a SQL injection attack. This allows them to, for example, create an admin-level user and sign in to your website as an admin.

The vulnerability doesn’t allow someone to create an admin-level user, which is something that Wordfence should know considering shortly after that in the post they tout their plugin will protect against SQL injection vulnerabilities. If you don’t understand the basics of them, then you are not likely to be good at protecting against them.

They certainly shouldn’t be out there making claims that are false like this, but considering this company even goes to the level of claiming they care more about security than WordPress while making up a threat, it really isn’t surprising.

This isn’t all that complicated, here are the vulnerable lines of code in the plugin (as identified by Sucuri):

737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
switch ( $time ) {
case 'today':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d' )}' AND {$search_query}" );
	break;
 
case 'yesterday':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -1 )}' AND {$search_query}" );
 
	break;
 
case 'week':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -7 )}' AND {$search_query}" );
 
	break;
 
case 'month':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -30 )}' AND {$search_query}" );
 
	break;
 
case 'year':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', -365 )}' AND {$search_query}" );
 
	break;
 
case 'total':
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE {$search_query}" );
 
	break;
 
default:
	$result = $wpdb->query( "SELECT * FROM `{$tablename}` WHERE `last_counter` = '{$WP_Statistics->Current_Date( 'Y-m-d', $time)}' AND {$search_query}" );
 
	break;

In that code the value of the variable $search_query, which contains user input, is used in used in multiple SQL statements without being sanitized. The important part here is that the SQL statements are SELECT statements which allow reading data from a database, they don’t allow insert anything, so you can’t add admin user or anything else (the INSERT statement would be used to insert data). What you could do is slowly read out the contents of the database, which isn’t something that we see any evidence of hackers doing against the average website (it could be used in a targeted attack).

Wordfence Fails To Mention Many Plugin Vulnerabilities

While Wordfence’s post titled a “Vulnerability Roundup” they only mentioned vulnerabilities disclosed recently in two other plugins, both of which were already fixed, while not mentioning any of the  numerous vulnerabilities in plugins that were recently disclosed that haven’t been fixed. Telling someone to update a plugin that already has been fixed is really not all that helpful, since what you really should be telling people is to keep all of their plugins up to date at all times. When vulnerabilities haven’t been fixed that is when it would be useful to make people aware of the issue. As example of Wordfence of not warning about those unfixed vulnerabilities, here are just the vulnerabilities that we disclosed last week that haven’t been fixed:

If you used our service you would know about those vulnerabilities and many others that remain unfixed, including many that are likely to be exploited.

08 Jun

Vulnerability Details: SQL Injection Vulnerability in Save Contact Form 7

From time to time vulnerabilities are fixed in plugin without someone putting out a report on the vulnerability and we will put out a post detailing the vulnerability. While putting out the details of the vulnerability increases the chances of it being exploited, it also can help to identify vulnerabilities that haven’t been fully fixed (in some cases not fixed at all) and help to ...


To read the rest of this post you need to have an active account with our service.

For existing customers, please log in to your account to view the rest of the post.

If you are not currently a customer, when you sign up now you can try the service for half off (there are a lot of other reason that you will want to sign up beyond access to posts like this one).

If you are a security researcher please contact us to get free access to all of our Vulnerability Details posts.

24 May

False Vulnerability Report: SQL Injection Vulnerability in Featured Image Resize

As part of our cataloging the vulnerabilities in WordPress plugins for our service we come across false reports of vulnerabilities from time to time. So that others don’t spend their time looking over these as well, we post our findings on them. The data on these false reports is also included in our service’s data.

Earlier today a thread was started on the WordPress Support Forum claiming that plugin Featured Image Resize contained a SQL injection vulnerability. Between us being notified of the thread and when went to check over things, half the message was removed. It isn’t clear if was removed by the poster or silently removed by a forum moderator (they do some strange stuff along those lines), whichever it was it causes a problem, as what was removed makes it easy to see that the vulnerability doesn’t exist.

Currently the message just states:

This plugin appears to be vulnerable to SQL injection. Recommend it is not used until fixed.

Previously right after that it included this:

$thumbnail_id = $_REQUEST[‘thumbnail_id’];
$wpdb->get_row(“SELECT * FROM $wpdb->posts WHERE id = ‘” . $thumbnail_id . “‘”, ‘ARRAY_A’);

Just seeing those two lines makes it look like there is a SQL injection vulnerability, but looking at the lines in context in the file /featured-image-resize.php shows that there isn’t. That is due to the fact that right after setting the value of the GET or POST input “thumbnail_id” to $thumbnail_id, there is check to make sure it is numeric:

13
14
$thumbnail_id = $_REQUEST['thumbnail_id'];
if( !is_numeric($thumbnail_id) ) return false;

If you were try to do a SQL injection using that input then the code should exit at this point, so the value never gets used in SQL statement and therefore there isn’t a SQL injection vulnerability.

The code could be improved by using a prepared statement to better insure that SQL injection couldn’t occur.

03 Oct

SQL Injection Vulnerability in Party Hall Booking Manager

One of the things we do to make sure we are providing our customers with the best data on the vulnerabilities that exist and are being exploited in WordPress plugins is to monitor our websites for hacking attempts. Through that we have found a quite a few vulnerabilities that exist in the current versions of plugins that it looks like hackers have already started exploiting. In the most recent case though we are still not quite sure what the hacker was targeting. Recently we found a hacker probing for usage of the plugin Party Hall Booking Manager, along with five other plugins at the same time. As we started looking over the plugins, one connection we found was that they all contained code that looked susceptible to SQL injections. That type of vulnerability is not one we often see target by hackers, so it is possible there is an additional issue with the plugin.

In a number of places in the code, user input is included in SQL queries without sanitization being done or a parametrized query being used. Below in one of those that we confirmed is exploitable.

In the file /scbooking.php the function ccb_get_roomprice_by_custompost() is made accessible to those not logged in through WordPress’ AJAX functionality:

220
add_action( 'wp_ajax_nopriv_ccb_get_roomprice_by_custompost','ccb_get_roomprice_by_custompost' );

That function takes the GET or POST input “post_id” and inserts into a SQL query:

209
210
211
212
213
214
215
216
217
218
219
function ccb_get_roomprice_by_custompost(){
  if($_REQUEST){
    global $table_prefix,$wpdb;
    $post_id = $_REQUEST['post_id'];
 
    $sql_room_price = "select * from ".$table_prefix."postmeta where meta_key='_room_price' and post_id=".$post_id;
    $result = $wpdb->get_results($sql_room_price);
    echo json_encode($result);
  }
  exit;
}

Proof of Concept

You can see that SQL injection is occurring by comparing the time it take for the following requests, with one that adds a ten second delay to the the SQL query, with to be completed.

Make sure to replace “[path to WordPress]” with the location of WordPress and “[post id]” with the ID of a room. That ID can be found by going to /custom_bookings/, going to a page of a room and the getting the ID from the source code. The ID is usually listed at the end of link for the “shortlink” in the head section.

No delay:

http://[path to WordPress]/wp-admin/admin-ajax.php?action=ccb_get_roomprice_by_custompost&post_id=[post id]

10 second delay:

http://[path to WordPress]/wp-admin/admin-ajax.php?action=ccb_get_roomprice_by_custompost&post_id=[post id]

Timeline

  • 10/3/2016 – WordPress.org Plugin Directory notified.
03 Oct

SQL Injection Vulnerability in bbPress Like Button

One of the things we do to make sure we are providing our customers with the best data on the vulnerabilities that exist and are being exploited in WordPress plugins is to monitor our websites for hacking attempts. Through that we have found a quite a few vulnerabilities that exist in the current versions of plugins that it looks like hackers have already started exploiting. In the most recent case though we are still not quite sure what the hacker was targeting. Recently we found a hacker probing for usage of the plugin bbPress Like Button, along with five other plugins at the same time. As we started looking over the plugins, one connection we found was that they all contained code that looked susceptible to SQL injections. That type of vulnerability is not one we often see target by hackers, so it is possible there is an additional issue with the plugin.

The vulnerable code can be found the file /json_logs.php whenre the extract() function is used to set variable from POST inputs and then those are used in a SQL query without any sanitization or the query being parametrized:

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
extract($_POST);
 
//Defaults
if(!isset($sortname) || $sortname == ''){
    $sortname = 'meta_id';
}
if(!isset($sortorder)){
    $sortorder = 'desc';
}
if(!isset($rp)){
    $rp = '1000';
}
if(!isset($page)){
    $page = 1;
}
$sortorder = strtoupper($sortorder);
$offset = ((Integer)$page - 1) * $rp;
 
//Get the data
global $wpdb;
$table_name = $wpdb->prefix.'postmeta';
 
$results = $wpdb->get_results("SELECT * FROM $table_name where meta_key = 'bbpl_like' ORDER BY $sortname $sortorder LIMIT $rp OFFSET $offset",ARRAY_A)

Proof of Concept

The following proof of concept will permit SQL injection to occur.

Make sure to replace “[path to WordPress]” with the location of WordPress and the “[SQL injection input …]” with appropriate input.

<html>
<body>
<form action="http://[path to WordPress]/wp-content/plugins/bbpress-like-button/json_logs.php" method="POST">
<input type="hidden" name="sortname" value="[SQL injection input after ORDER BY]" />
<input type="hidden" name="sortorder" value="[SQL injection input after ORDER BY]" />
<input type="hidden" name="rp" value="[SQL injection input after LIMIT]" />
<input type="submit" value="Submit" />
</form>
</body>
</html>

Timeline

  • 10/3/2016 – WordPress.org Plugin Directory notified.