Nico's hax0r blog

Deltascripts.com promo code!

Mon, 06 Feb 2012 20:35:00 +0100

Get everything for free with this unique promo code: pastebin.com/j9Qkdsyg

This gets you everything off their site, such as their $349 “PHP Classifieds” script.

I’m posting this to raise awareness. If a company like this can’t even protect what’s most valuable to them, how do you think they can protect what’s most valuable to you and your users?

It has been around since 1998 and was the first PHP Classifieds script introduced in the world.

I wouldn’t be surprised if it hadn’t been updated since 1998 either! Their requirements are funny too:

The following PHP settings:

- Magic_Quotes ON

Magic Quotes? Really? This feature has been deprecated in PHP 5.3, and will be completely removed in PHP 5.4. I’m not exactly sure how PHP 5.4 users are going to enable this feature to meet their requirements.

“PHP Classifieds” is a horrible script. I wouldn’t even use the *free* version.

Stay far away from it.

(Let’s see how long they take to fix this)

Note: This is not a real promo code, but it works regardless. Using the scripts you get with this code might get you in trouble. Use at own risk!

BigDump, big goof!

Tue, 31 May 2011 18:17:00 +0200

I just had to import a big database, and I used BigBump for that.

My dirty mind immediately thought, how many people do actually leave the script on the server after importing their databases? Turns out, a lot.

Now that’s pretty careless, but hey, their loss is my gain. Pretty quickly I found my first victim: A phpBB board. I always used to be more of a vBulletin guy, and since I have no experience with that particular software (as to what hashing algorithm, salts, etc, it uses), I figured I’d just download it and install it locally. After doing so, I went to my phpMyAdmin, and exported the users table, which only had two users in it. My new admin account, and some random ‘Anonymous’ account, which makes no sense to me without further investigating, but I don’t care enough at this point.

I just removed said account from the exported .sql file, leaving only my account in it. I changed the user ID to some ID the forum wasn’t likely to have already. Seeing as the forum has 1500 something users, so I just used the ID 2000, considering it probably has some banned users which are not counted. Make sure the user group ID is set to 5, otherwise you won’t be admin.

I grabbed the file, uploaded it via BigDump to the server, and hit ‘Start import’. Since it was a single query only, it went rather fast.

I went back to the forums, and logged in, using the moniker and password I picked during the local installation. Directly after logging in, the forum showed me a link at the bottom to the admin control panel… Success!

It was unbelievably easy, and yet it’s a very dangerous attack!

If I wanted, I could change anyone’s password, and log into their account. I could delete whole accounts, and what not…! I can run any MySQL query I want to, UPDATE, DELETE, DROP, etc…

On a further note, older versions of BigBump (v.0.28b, I believe) use eregi() instead of preg_match() for the file name validation. And since eregi() is not binary safe, you probably could just prepend a null character (\0) to the file name, and upload .php files this way. It’s only theory, though, as I haven’t actually tried it.

And on a last note, you may be able to create .php files with your own code using native SQL.

SELECT '' INTO OUTFILE '../../public_html/hacked.php'

MySQL isn’t very likely to have permissions to write to that directory, but it’s worth a shot.

Client-side password hashing before log-in.

Fri, 28 May 2010 21:58:00 +0200

UPDATE: This method protects your password (slightly, at least), but it does not protect user accounts on the forum. If someone *sniffed* your password hash, it could just be captured and resent to the server it was gathered from, along with your user name. The forum would not know whether the hash was directly submitted, or if your Javascript code created it before logging in.

I’ve seen vBulletin doing this, and I thought it was very interesting.

What they do is, they hash the user password using JavaScript before logging in. How MD5 hashing works is no secret. And not even reverse engineering the code that generates these hashes will make them “decryptable”. But I don’t want to get into this now. What I’m saying is, that JavaScript can create valid MD5 hashes, just like PHP would do. And we can take advantage of this to make our systems a little more secure.

Here’s an example JavaScript code that creates MD5 hashes:

http://github.com/kvz/phpjs/raw/master/functions/strings/md5.js

(Feel free to use it.)

If the user has JavaScript enabled on his browser, vBulletin converts his password as soon as the form is being submitted, and removes the value from the original password field. So that only the hashed password will be sent to the server.

POST /forums/login.php?do=login HTTP/1.1
Host: www.xxxxxx.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: […]
Accept: text/html,application/xhtml+xml,application/xml;q=0.8 […]
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.xxxxxx.com/forums/index.php
Cookie: [ … ]
Content-Type: application/x-www-form-urlencoded
Content-Length: 198

vb_login_username=Nico&cookieuser=1&vb_login_password=&s=&securitytoken=guest&do=login&vb_login_md5password=577********************f03d&vb_login_md5password_utf=577******************f03d

This is an example request that my browser sends to the server. As you can see, my password is only being sent in form of MD5 hashes. No trace of the real password!

So why are they doing this you might ask?

Security is the obvious answer. If you’re not connected to the server using a secure (SSL) protocol, your request is being sent “as is”, meaning PLAIN TEXT, and can be seen by others, using certain packet analyzing or HTTP sniffing tools.

Since SSL certs are not always an option, and sometimes a little pricey too… And since I’m yet to see a message board actually using a secure log-in system, I find this method rather interesting. I’m by no means trying to say that this method is anywhere as secure as SSL connections, or that it can replace them.

Implementing this method into existing log-in systems might be a little bit difficult or even impossible if you’re using “salts” or anything besides just MD5.

However, In case you’re interested, here’s an example on how to use this method in your own forms.

The md5() function from phpjs relies on their utf8_encode() function as well, so we must include it.

The above code looks pretty much like most log in forms, except that I’ve added a hidden field called “md5password”, which will later hold the hashed password. And I’ve added an “onsubmit” handler to the

tag.

The JavaScript code does the same as vBulletin’s does. It prevents the original password from being sent (meaning it removes its value), and instead it includes an MD5 hash of it.

Please note that this only works if the user has JavaScript enabled. So on the server-side, we cannot rely on the password being hashed. We have to check for it.

In this example I’m assuming you’re only using MD5 without salts or any other ingredients on your user’s passwords.


$username = $db->escape_string((string) $_POST['username']);
$query = $db->query("
	SELECT `username`, `password`, `salt`
	FROM `users`
	WHERE `username` = '{$username}'
");

if (!$userinfo = $query->fetch_assoc())
{
	// Error... user not found
}
else
{
	if ((!empty($_POST['md5password']) AND $_POST['md5password'] == $userinfo['password']) OR
		(!empty($_POST['password']) AND md5($_POST['password']) == $userinfo['password']))
	{
		// Success... user logged in
	}
	else
	{
		// Wrong password
	}

}

?>

Please also note that this code is for reference only. A simple copy and paste will not work. Furthermore, I cannot provide many more examples as the password hashing can be done in too many ways. But I’ll post one more for vBulletin-a-like systems where a custom salt is being used:

if ((!empty($_POST['md5password']) AND md5($_POST['md5password'] . $userinfo['salt']) == $userinfo['password']) OR
	(!empty($_POST['password']) AND md5(md5($_POST['password']) . $userinfo['salt']) == $userinfo['password']))
{
	// Success... user logged in
}

Make sure you’ve previously selected the user’s salt from the database and it’s present in the $userinfo array.

As I said earlier, implementing this method into your existing log-in system might be impossible. It all depends on how you’ve been handling the passwords from the beginning.

Questions?

Dear "CyD Software Labs"...

Thu, 27 May 2010 18:38:00 +0200

CyD Software Labs claim themselves “WEB security specialists”.

Sounds great… so I decided to look at the stuff they’re actually doing. After a short while, I stumbled up on this post about Cross Site Scripting (XSS).

While they make a good point about HTML entities, they’re completely forgetting SQL injections. The code they’re suggesting to prevent Cross Site Scripting is completely worthless, considering I can exploit their SQL query. I can still inject any HTML code, as if htmlspecialchars() never existed in their code.

$username= htmlspecialchars($_GET['username']);

$message= htmlspecialchars($_GET['message']);

$result=mysql_query("INSERT INTO minibbtable_posts 

VALUES(NULL, 1, 1, 1, '$username', '$message', 1, 1, 1)");

I mean,… seriously? That’s all you have to suggest? This post is probably still from the PHP 4 days, when Magic Quotes were enabled by default, but still… this suggestion is more than ridiculous. Especially for a “WEB security specialist”.

Since they don’t suggest mysql_real_escape_string(), I can insert single quotes into the query, and manipulate it that way. (For more information, I posted about this type of exploit a while ago here.)

They are however suggesting to apply htmlspecialchars() on the input, AND the output, which is pretty stupid, because it’ll result in ugly output to the user. This method does not prevent code injection, but it prevents the code from executing on the client’s side. That means I can save valid HTML in their database, but it won’t be executed by the client because it’s being converted to HTML entities.

But there are other types of attacks I can execute using the exploit. What if I’m not interested in the user’s cookies, or redirects to spam sites, or anything else JavaScript can do? What if I inject a sub-query that selects user passwords and adds them to my posts?

It’s as easy as inserting something like this into the “Name” field of their page:

’, (SELECT `password` FROM `users` WHERE `userid` = 1), 1, 1, 1) #

This can be way more harmful than any XSS attack. Allowing me to insert JavaScript can give me some options to steal user information, and maybe even hijack their sessions by stealing their cookies and what not.

But in all honesty, why bother coding a script that can steal user’s cookies and save them on another server, when I can get their info directly and more accurately?

There are some parts of their code that needs to be analyzed before continuing:

They’re for example using a mysql_query() call without error control. Meaning, there’s no “OR die(mysql_error())”. That’s good for them, and bad for us. Since we’re not getting any useful errors, it can be hard to inject code as we don’t know what we’re really doing. However, there are still thousands of sites using proper error control, and most of them naively show the error to the user too.

Another thing is that we usually don’t see is the actual code behind the user interface, so we don’t necessarily know how many fields we need to insert into the database. In this example, they’re inserting data into 4 columns before the user name and the message, and more data into 3 columns after that:

INSERT INTO minibbtable_posts   VALUES(NULL, 1, 1, 1, '$username', '$message', 1, 1, 1)

The data before the message ($message) is rather unimportant, as we inject code right after it. What we need to know is how many fields there are after it, as they might be required (can’t be empty). Obviously, when injecting code we start with the minimum amount of columns.

We’re first closing the initial single quote by inserting another one. Thus, resulting in a query like:

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, ''

Now we add a comma, and then the actual SQL code we want to execute. This could be a SELECT sub-query, or a CHAR() call to write characters which would usually be converted by htmlspecialchars().

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]))

This query alone would be valid, but the rest of the original query is hard coded into the PHP script and we can’t modify it. So we have to tell MySQL to ignore it, by adding a # to the end.

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...])) #

Now the actual code will be send to the database like this:

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...])) #', '$message', 1, 1, 1)

In SQL, the # character stands for a command. Meaning it’s “just” information for the programmer, and therefore ignored by MySQL.

However, in this case, the three 1s are unknown fields that can’t be empty. So we’re getting an error like this:

Column count doesn’t match value count at row 1

This error means we’re inserting less (or more) columns than required. From there we keep adding more, until it works.

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]), 1) #

(Note the 1 after the SELECT sub-query. This would still produce the same error as we’re not yet inserting the required amount of fields.)

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]), 1, 1) #

(Still no luck… keep trying, and add one more field.)

INSERT INTO minibbtable_posts VALUES(NULL, 1, 1, 1, '', (SELECT [...]), 1, 1, 1) #

Bingo…

Most of the times, hacking involves trying. You can’t always know everything.

I’m aware that they’re also addressing htmlentites() and htmlspecialchars()’s “quote style”, but they’re neither using it in their code, nor do they say how dangerous it is not to use these functions.

Not sure what exactly makes them think they’re WEB security specialists, but this post proves pretty much the opposite. It’s just giving their readers a false sense of security.

Some common PHP security pitfalls...

Fri, 07 May 2010 19:31:00 +0200

… and how to exploit them.

Chapter One: Image uploading.

Allowing users to upload files to your server needs to be done carefully. Very carefully. If a user manages to upload a (PHP) script, they’ll be able to do pretty much anything with your server, including the database (if any).

Let’s assume for a moment that you only want to allow images to be uploaded. So how can you make sure the file is really an image? Some might say “Hey, there’s $_FILES[‘file’][‘type’], which holds the file’s content type.”

I’ve seen many people (INCLUDING w3schools!) relying on this value for verification. But not only comes this value directly from the CLIENT, it can also be easily modified/faked.

I could upload a PHP file with an image/jpeg content type, and it would pass the verification. Everyone’s site using the code from w3schools is vulnerable.

Don’t EVER rely on this value.

The first thing you should do, is validate the file extension. Only files that are parsed by the server (or the user’s browser) are dangerous to us. And by default, the server only parses certain files with certain extensions, such as .php, .asp, .pl, .py, etc… Depending on what you have installed.

Validating the extension is quite easy:


// Valid file extensions.
$valid_extensions = array('.jpg', '.jpeg', '.png', '.gif', '.tif', '.tiff');

// Get current file extension
$extension = strpos($filename, '.') !== false
	? strrchr($filename, '.')
	: 'none';

$extension = strtolower($extension);

if (!in_array($extension, $valid_extensions))
{
	// Invalid file... throw error and DO NOT UPLOAD
}
else
{
	// Everything is cool... continue.
}

?>

NOTE: Some servers parse .gif files by default. I’m not exactly sure why, but try it out to be on the safe side. Valid and normal looking GIF (as well as other) images can contain PHP code. So you don’t want to have those images parsed.

Secondly, you can use PHP’s image functions to verify if the file is an actual image. They’re not 100% bullet-proof, but it’s a fairly good start.

$type = @exif_imagetype($_FILES['image']['tmp_name']);

if (!$type OR !in_array($type, array(
	IMAGETYPE_JPEG,
	IMAGETYPE_GIF,
	IMAGETYPE_PNG,
	IMAGETYPE_TIFF_II,
	IMAGETYPE_TIFF_MM
)))
{
	// Invalid image... do not upload
}
else
{
	// Everything's cool
}

If you don’t have the EXIF extension installed, use getimagesize().

As I said, this is not 100% bullet-proof, meaning this can be exploited as well. But it’s a very good start.

Another option:

Upload the files to a non-public directory. The user needs to access the file using his browser in order to execute it. And this is impossible if the file is outside the public directory.

If you need to display the images at some point to the user, use a PHP script to read the file’s contents. This way they won’t be parsed and can’t cause trouble.

$file = '/path/to/some/file.jpg';

if ($type = @exif_imagetype($file))
{
	header('Content-Type: ' . image_type_to_mime_type($type));
	readfile($file);
}
else
{
	// Error, not an image...
}

Another safe, but “not-so-optimal” option is storing the file in a BLOB field in the database. I wouldn’t suggest doing this if you plan on storing a lot of images, though.

And last, I highly suggest you to read this PDF from Scanit. It’s a good and mind opening read. (It also contains a Perl script which allows custom content types).

Chapter Two: HTTP header redirects.

This is one of the things I’ve seen too many times as well. People have protected areas on their pages which require some kind of authentication. If the users fails to be authenticated, they’re redirected to the log-in page. Usually, there’s nothing wrong with that. But a lot of people seem to forget to EXIT their script after redirecting.

The browser follows the redirect header for your COMFORT. It’s just a function and can be disabled easily. And if you do not exit the script, it’ll continue to run, meaning, the user will be able to see the output even after sending the header.

I’ve exploited this here, for example. And even ImperialBB was vulnerable to this a few years ago, before i reported the issue. I was able to see protected administrator forums.

BAD:

if (empty($_SESSION['userid']))
{
	header('Location: login.php');
}

GOOD:

if (empty($_SESSION['userid']))
{
	header('Location: login.php');
	exit;
}

http://www.php.net/exit
http://www.php.net/header

Chapter Three: Cross site scripting (XSS).

Another thing I see on a daily basis:

I won’t even lie, I was guilty of doing this too in my early PHP days. Until I learned that I could append JavaScript to the URL in the address bar, and it would be injected directly into the page I was on.

example.com/page.php/

… the above is a valid URL, and PHP_SELF would contain this bit of JavaScript. Needless to say, this alert() is harmless, but I could inject any code, and this could be potentially harmful.

Some sites use .htaccess to block requests that contain

If the user input would have been escaped properly, I wouldn’t have been able to modify the SQL query, and I wouldn’t have been able to inject my code.

Read PHP’s mysql_real_escape_string() manual… DO IT!

How to take ownership of a forum.

Fri, 19 Feb 2010 09:44:00 +0100

UPDATE: I’ve patched this exploit using my newly acquired admin powers. It will no longer work. So don’t waste your time! ;p

I’ve been on this vBulletin message board for quite a while now, and we have a problem there; The administrator left us for dead. He hasn’t been online for… way too long, and we need some changes on the site.

I figured this was an appropriate moment to get my hax0r skills involved. I’m going to explain how I did this, but I’m not going to get into every detail, as I don’t actually want anyone on this site to try it out. If you have some SQL/PHP background, you’ll probably figure this out by yourself. You still shouldn’t try this, though. Something like a missing WHERE clause could make all user accounts unusable. All of them…

Having that said,… let’s get started! What I need to accomplish is to get admin rights, so I can make the changes we need. Luckily, the forum has some custom add-ons, made by the admin himself. I thought this was a good place to start looking for exploits. There’s one part where you can change other people’s user title (a little text which is being displayed beneath the user’s screen name).

I just entered a single quote ( ’ ) to see if the user input was being escaped properly, and… jackpot! I received this error:

Don’t EVER show errors like this to the user! Do you realize how useful this information is to me? I can see the table name (no table prefix), and the field names. I can see exactly what’s going on behind the scenes, and how to exploit this vulnerability.

Could this be any nicer? I don’t think so. This means I now have full “UPDATE” access to the “user” table.

The text input field which I’m using was limited to 21 characters, but luckily only on the client-side (big big mistake). I opened up Firebug and removed this attribute from the text field: maxlength=”21”… and the limit was gone. If you want to limit the input length, don’t trust the user. Do it on the server-side as well. (Hint: substr)

So how can I use this exploit now? I can write to the “users” table only, that means I can change my usergroup ID to “6” (which is vBulletin’s default ID for administrators). That would gain me access to the admin panel, but it will only give me a very limited amount of options (which are worthless to me). The real admin himself needs to give the user all wanted privileges, and this can’t be done in the “users” table alone. Ideally, I’d need access to his account so I can do this myself.

With this exploit, I could change the admin’s password, but needless to say, he’d realize that the next time he tried to log on. So what if I copy his password, (which by the way is an MD5 hashed string), to a temporary place? This way I could restore it when I’m done with the changes, as if nothing ever happened.

I only have “UPDATE” access to the “users” table, so I need a field in there that can hold at least 32 characters. I figured the “msn” field is just perfect for that (it holds up to 100 characters). Although, the “yahoo” and “skype” fields would have done it too:

(Having a local copy of vBulletin comes handy when investigating.)

So how can I SELECT his password, and copy it to my “msn” field? Remember that we have to do all tasks with just one single UPDATE query. And usually, you can’t use UPDATE queries with SELECT sub-queries if both access the same table. But there’s a trick too.

UPDATE `user` SET `msn` = (
SELECT `password` FROM (
SELECT `userid`, `password` FROM `user` WHERE `userid` = 1
) AS `x`
WHERE userid = 1
)
WHERE userid = xxxx

If you want some good piece of advice, don’t forget the WHERE clauses (none of them)! I accidentally selected 50+K users and temporarily crashed the MySQL server.

Sweet! Now my MSN field holds his hashed password, which I don’t want to (and can’t) reverse. But I need it so I can put it back later when I’m done, so he won’t notice I “borrowed” his account.

Okay, I have his hash, now I need to change his password. In pseudo-code, vBulletin does the hashing like this: md5 ( md5 ( password ) salt )

For security reasons, every user has their own salt stored in their database row. It’s used to create different MD5 hashes so no one can find the original password using rainbow tables. But in this case, it doesn’t secure anything. We can just grab this salt again and create a new password with it. We don’t even need to know what the actual salt is.

We can do this with native SQL.

UPDATE `user`
SET `password` = MD5(CONCAT(MD5('new pass'), `salt`))
WHERE `userid` = 1

Easy… Now that I have set my own password, I can just log in with his account, using his original username and the new password I just created, and give myself all admin rights. After doing that, I simply change his password back:

UPDATE `user`
SET `password` = 'The MD5 value from my MSN field'
WHERE `userid` = 1

This might be obvious, but you can get the hash by going to your profile and reading the value in the MSN field.

Done… I now have full admin rights, and the real admin won’t notice unless he takes a closer look. But then it’s gonna be too late anyway! ;)

UPDATE:

Since I have access to the plug-in system now, I could create and install my own ones. And thus, allowing me to upload/download files, or anything else I wanted to do. I have complete control…

ALTERNATIVE WAY:

I did not actually try this method, but it should work as well.

Users are identified by their unique user IDs rather than their names. This allows the system to let users easily change their name while their permissions (which are stored in different tables) remain. That means, instead of changing the admin’s password, I could set his user ID temporary to an ID that doesn’t exist (how about 0?), and set my own ID to 1.

There’s an important difference between those two methods, though. As soon as we set the admin’s ID to 0, he won’t have any powers anymore. And besides, he won’t be able to log in, due to vBulletin verifying the status like this:

if ($vbulletin->userinfo['userid'] == 0) { /* not logged in */ }

0 is the default user ID for “guests”, by the way.

The other difference is, that we cannot give our own account admin rights, because it already has them! But only as long as we don’t change the ID back to the old one, which we should do quickly, before anyone notices. So if we want our very own account, with permanent rights, we have to create a new one (this can be done easily through the admin panel). If you want to give your existing account new rights, the other method should be applied. (Or… register a new account before changing IDs, and work from there.)

Moving on… The user IDs start with 1, and automatically increment by one with each user that registers. The easiest way of not messing up IDs is probably setting the admin’s ID to 0. It’s considered an integer (INT), meaning the database field will be able to hold it, and more importantly, it won’t conflict later with other IDs.

We can change the IDs by running a simple query similar to:

UPDATE `user` SET `userid` = 0 WHERE `userid` = 1

And then we set our own ID to 1, running almost the same query.

UPDATE `user` SET `userid` = 1 WHERE `userid` = XXXX

Obviously, XXXX needs to be replaced with our own user ID. ~~I didn’t dig too deep into vBulletin’s code, but we might need to re-authenticate after making the changes. But you’ll see…~~

That’s most of the secret! Do whatever you need to do with the powers, and change the IDs back whenever needed, using the same queries as above, only swapping IDs.