Cmd+Ctrl Logo

DEFCON 25 was the first security conference I had ever attended. It was a new experience and I learned a lot but all of that is for another post. Here I want to talk about one of my favorite experiences at DEFCON: Cmd+Ctrl hackathon. The goal of the hackathon was to “explore vulnerable web applications, discover security flaws, and exploit those flaws.”

The Web Application Hacker's Handbook cover

Over the previous year, I worked my way through The Web Application Hacker’s Handbook so I was excited to have an opportunity to try out all the things I learned in the book. The authors of the book repeatedly mention the suite of tools they wrote called Burp to facilitate a lot of the research needed to explore and exploit web applications. I was excited to finally try out that as well.

Competition Setup

First though, let’s talk about how the hackathon worked. The set up was really cool so I was very impressed by Security Innovation who were the organizers of the hackathon.

Once you registered for the hackathon you had access to the leaderboard and two sections for each web application that you tried to exploit. Unlike other CTF’s, there isn’t a list of challenges to solve and no secret flag values to provide. Instead once you went to the target website, you were on an isolated (meaning its just for you) website that auto-captured exploit events and reported that back to the central dashboard to reward you with points. It was really cool to see that in action. You would try something and if you succeeded, the website would give you a pop up saying “You just did {blah}. Your score has been updated with {blah} points”.

Central Dashboard talks to exploit catchers that wrap the web apps

As the diagram above shows, each participant is hacking away at their own copy of the website. So when a participant changes the state of the website, the impact is limited to that participant. Additionally, when the participant finds an exploit, the “exploit catcher” that wraps the website catches the exploit and talks to the central dashboard to reward the participants with points. I am not sure how the communication between the web app and the exploit catcher worked but it was very cool to see it in action.

My Setup

Kali cool snake logo

I was using Kali Linux via virtualbox using an image provided by OffensiveSecurity. Using that image was great, getting set up was fast and easy. Kali Linux is a good choice as it comes prepackaged with a lot of useful tools, like Burp and Hashcat, for this competition.

Since I had already set up the VM, the only setup for the competition was to set up my browser to proxy through Burp (instructions). This allows Burp to capture all traffic and manipulate requests and responses (including headers and cookies). Burp has MANY other features but this was by far the most critical.


Unfortunately since the competition was so long ago, the list of vulnerabilities I found isn’t available anymore. So I will cover some of the ones that I remember.

Request Manipulation

Request manipulation was a common trend. For example, the first web app was a store. When you added an item to your cart, the cost of the item would be sent as part of the request. Manipulating the cost in the request would result in the cost of the item changing! Similarly, it also stored the contents of your cart in a cookie. So at checkout time, simply manipulating the cookie resulted in you controlling how much you wanted to pay for the item.

Cost was an easy thing to start with since the current cost is known and the range of “valid” values that are likely to succeed is known as well. Other fields I was able to manipulate usually tended to be of a “serial id” type. For example, once I added a credit card to the store I noticed that my request to the webapp sent a request with an integer credit_card_id. I was able to lower the integer by one to edit/use credit cards of other users.

Bypassing Authentication

The little authentication the website did have was bypassable. The login entry itself was susceptible to SQL injection. After reading about SQL injection hundreds of times, this was the first time I had actually tried to use it. Escaping things the right way took longer than I would have expected but it was cool to see when it worked!

Once you logged in, the website set a session cookie for you. The structure of the cookie looked suspicious. hash-identifier confirmed that the cookie was a hash (I can’t remember of which kind). Plugging in the hash over at CrackStation showed that the session cookie was just a hash of the username. I obviously got lucky here since my username was just “test” and so CrackStation had that value already. However, if this hadn’t worked, using hashcat for this would have been the next step. In any case, since I could determine any user’s session cookie, I was able to impersonate any user.

I can’t remember how exactly but I was able to find the “encrypted” passwords of other users. The values seemed to be base64 encoded but the padding character = was at the front so I reversed the string and decoded it. The resulting string looked like it was a reversed base64 string too! I did that a few more times and I was able to “decrypt” the password.

Leveraging Personalization Options

One of the webapps gave you a profile page. XSS was the first thing I tried. Again I had to play around with the escaping but I was finally able to make that work.

The profile page also let you upload an image so that when your profile is loaded, the image is loaded as well. After playing around with that I realized that I could upload a PHP file (which is what the webapp seemed to be using based on some error messages I had seen) and when that image is queried, the file would be executed!. The “exploit catcher” understandably kicked in before my uploaded script was actually run though. I imagine they felt that there was no reasonable way to reign in the possible damage with that one!


I found Cmd+Ctrl at DEFCON 2 hours before it was wrapping up and had a lot of fun with it. Security Innovation folks were nice enough to open up the website again after DEFCON so I was able to play around with it over the next couple of weekends. By the time the competition was deactivated again, I must have put in 20 hours into the competition and I had managed to climb to the 8th spot! I was very happy with the result!

Scoreboard showing azeemba at #8

Since I enjoyed the challenge so much, I definitely want to continue with things like these. I think I might try to play around with some projects like Damn Vulnerable Web Application and hackazon. Back in college I worked on a personal web app to help me keep track of my time spent on activities. It would be cool to revive that and see how many different ways I can exploit it.

After DEFCON, I participated in the MicroCorruption CTF which was a fun learning experience as well. Maybe I will write another post to cover that!