What this means is that for every request that calls on PHP, it sends an additional header that looks something like this:

X-Powered-By: PHP/5.2.3-1ubuntu6

Since I installed this via apt-get, it added a 1ubuntu6 to the end, which I think is a slight security risk in and of itself, but that's not what this is about.

But what it always does, no matter how you installed it, is show the PHP version. In this case, 5.2.3, 2 revisions ago (Hooray outdated repositories! Seriously, it's from May. Though you do have Debian beat.).

Now, in the perfect world, this wouldn't be a security risk, since everyone would have the most updated version of their software, but as everyone knows, that just doesn't happen. Mine was just installed, and it's already out of date.

This means that for 80% of the PHP population (98% of statistics are made up on the spot), PHP is advertising itself as an outdated, and probably vulnerable, version. Most likely you aren't even using any of the vulnerable functions, or even knew they existed, but there's still a chance you are. During the month of PHP bugs, there were more than a few functions with vulnerabilities that I used on many occasions.

Wordpress also does something of the same. It gives out your Wordpress version in meta tag on every pageload, with the only way to get rid of it is editing your template. Wordpress is even harder to upgrade than PHP, so expect to find them outdated in a much higher frequency.

Apache, and pretty much every other server out there, does pretty much the same thing with their Server header, but Apache gives you the options on how to display it. Apache/1.3.37 (you have to show all of that from the 1337 though) or Apache/1.3 or Apache/1 or maybe just Apache.

With PHP, it's all or bust. Not PHP/5 or just PHP. You can overwrite every version by doing something like:

<?php
header("X-Powered-By: Love-Cookies-and-Hamsters/2.4");
?>

Or something similar, but you have to do it manually for every script. There isn't really a server wide override.

Now, this point can almost be moot, since it's just so easy to find phpinfo()'s.

Here is the vulnerable function

function wp_suggestCategories($args) {
        global $wpdb;
 
        $this->escape($args);
 
        $blog_id                             = (int) $args[0];
        $username                            = $args[1];
        $password                            = $args[2];
        $category                            = $args[3];
        $max_results            	     = $args[4];
 
        if(!$this->login_pass_ok($username, $password)) {
                return($this->error);
        }
 
        // Only set a limit if one was provided.
        $limit = "";
        if(!empty($max_results)) {
                $limit = "LIMIT {$max_results}";
        }
 
        $category_suggestions = $wpdb->get_results("
                SELECT cat_ID category_id,
                        cat_name category_name
                FROM {$wpdb->categories}
                WHERE cat_name LIKE '{$category}%'
                {$limit}
        ");
 
        return($category_suggestions);
}

Namely this part

if(!empty($max_results)) {
     $limit = "LIMIT {$max_results}";
}

Way to not censor or check if the variable is valid. That's some pretty poor programming practices right there.

It took the whole of 2 seconds to fix it.

if(!empty($max_results) && is_int($max_results)) {
     $limit = "LIMIT {$max_results}";
}

This was fixed in the trac by typecasting the variable to an int. Whatever. Both ways work.

$max_results = (int) $args[4];

The issue was posted in the trac on May 28, and instead of issuing an update or informing people, nothing has been mentioned. Just let it get disclosed, have people try to exploit.

It does, however, not look to be too bad. You have to know the user's username and password to exploit it, though I'm not sure what user level is need for this (I was too lazy to get the exploit working without C#). If it's subscriber, shit. If it's anything other than admin, it's still not very good.

First off, SQL Injection. It showed 48 cases of successful SQL Injections. Crap! Luckily, all 48 injections were for one page, the deleting of private messages. These consisted of setting POST variable 5 or 7 or 1 to ' or %27 or %2527 or " or '" and so on, and the response it would get would be:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1

Once this gets out of development, I would change this to email me instead of just showing it, but it was still giving a valid SQL problem. This was kinda confusing, since it only cares if POST variable 5 is set and equal to "on". If it's anything else, it just ignores it.

First, I'll explain how my message deletion system works. The inbox consists of a table of message titles, the sender, time sent, and a little checkbox to delete the message. The checkbox name is equal to the message id. Then there is a hidden input that lists all the message ids seperated by commas, like

<input type="hidden" name="messages" value="10,7,5,1" />

So, once the form is submitted, it explodes $_POST['messages'] and runs through each one to check if the POST variable matching the message id is set and equal to "on". (Note: I could've just put the $_POST array in a foreach loop and done it from there, like foreach($_POST as $key => $value) { /* check it */ }, but for some reason I didn't.

Here's the code to it. There is also a check to make sure that the POST variable hash is set to what it should be. This is used to protect from someone putting a form to delete a user's messages in an iframe or something.

if(isset($_POST['delete']) AND $_POST['delete'] == "Delete Messages") {
	if(isset($_POST['messages'])) {
		$messages = explode(",",$_POST['messages']);
		$where = ($_POST['type'] == "sent") ? " WHERE `sender_id` = '$logged_user_id' AND ( " : " WHERE `receiver_id` = '$logged_user_id'  AND (  ";
		$done = false;
		foreach($messages as $message) {
			if(is_numeric($message) AND isset($_POST[$message]) AND $_POST[$message] == "on") {
				if(!$done) {
					$where .= " `msg_id` = '$message' ";
					$done = true;
				}
				else {
					$where .= " OR `msg_id` = '$message' ";
				}
			}
		}
		$where .= " ) ";
 
		$query = "UPDATE `privmsgs` SET ".(($_POST['type'] == "sent") ? "`senderbox` = 'Deleted'":"`receiverbox` = 'Deleted'")." , `timedeleted` = ".time()." $where";
 
		mysql_query($query) or die(mysql_error());
 
 
	}
}

If you notice, the POST variable 5 doesn't get anywhere near the query. It's checked to see if it's set and equal to "on". The variable from $_POST['messages'] is the one put in the query, and that's only if it's also numeric.

So, I launched the attack in it's HTTP Editor and set the page to just echo the query, and it printed:

UPDATE `privmsgs` SET `receiverbox` = 'Deleted' , `timedeleted` = 1175118688 WHERE `receiver_id` = '1' AND ( )

Aha! No messages where equal to "on", but the query still fired. Simple fix. Just enclose the query in the if statement if($done), and that bug is squashed. There was no possibility of SQL injection though. So even though it was inaccurate, it did help me find a bug.

Next, Blind SQL/XPath Injection. It states that the variables post and posthash are vulnerable. Uh, no? These are never placed into the database, just to make sure the person is posting instead of previewing and prevent people from automatically creating posts just by running a script or the iframe protection like mentioned for the PM's. It's never even close to the query.

Apache mod_ssl vulnerabilities. XAMPP problem. It's not for production anyways.

PHPSESSID session fixation. This means that someone can set the session id using a GET parameter, like

http://example.com?PHPSESSID=h4x0redsessionid

Now, the attacker knows that value and doesn't have to steal it at a later time. But since there is no sensitive data being stored using sessions in my script, this isn't so much a problem. To fix this, set session.use_only_cookies = 1 in php.ini.

User credentials sent in clear text. 48 of these. I actually have it built to be able to use a secure login, but probably won't use it.

The rest were basically all false positives. It says it found sensitive directories, files, ASP.NET files, Access databases, and most anything you can think of. This turns out to just be a simple glitch with mod_rewrite. Here's the line:

RewriteRule ^browse-posts/show-sold(/category/([a-zA-Z0-9-]+))?(/page([0-9]+))?/? browse.php?show=sold&category=$2&page=$4 [L]

I didn't put $ behind the match. So, /browse-posts/show-sold/password.txt would be show a page, and /browse-posts/show-sold/Web.config would show the same thing, /browse-posts/show-sold/CVS/Repository same thing.

Even though there was no real problem, just an annoyance, it was an easy fix:

RewriteRule ^browse-posts/show-sold(/category/([a-zA-Z0-9-]+))?(/page([0-9]+))?/?<b>$</b> browse.php?show=sold&category=$2&page=$4 [L]

Now, /browse-posts/show-sold/password.txt sends a 404.

So, if you don't include the mod_ssl problem, it found 0 vulnerabilities, 1 bug, 1 possible problem, and about 300 false positives, so I'm not really sure of the usefulness of this. If you have an app you want to easily test, it can help, but I don't see this as a sure fire way to test it.