PicoCTF is a capture-the-flag competition that happened in 2014. It was originally aimed at high school and middle schoolers, with an actual time limit and awards and whatnot. The organizers were kind enough to leave the puzzles up, however, so that future people (aka me), could still try to solve their challenges. Even though it’s originally aimed at high schoolers and middle schoolers (and has a storyline involving killer cyborgs and kidnappers) the challenges themselves are pretty enjoyable for all ages, and more accurately would be for beginners in the infosec world. I fall neatly in that category, and so as work permits, have been working through the different problems they have. Below is a write-up of the more interesting puzzles I’ve solved so far.

secure_page_service (100 pts)

The puzzle was presented as follows:

The bad guys have hidden their access codes on an anonymous secure page service. Our intelligence tells us that the codes was posted on a page with id 43440b22864b30a0098f034eaf940730ca211a55, but unfortunately it’s protected by a password, and only site moderators can view the post without the password. Can you help us recover the codes?

It then links to a webpage where you log in or register. You then have the option to view a page by giving the ID, or creating page. When you’re viewing a page based on the ID, you can also report it to administrators, and they’ll look at the page and do whatever moderators do.

At first, my inclination was to make sure their authentication code was up to snuff. I tried adding an admin=1 or admin=true to the query string where the ID of the page is (e.g. http://sps.picoctf.com/view_page.php?page_id=43440b22864b30a0098f034eaf940730ca211a55&admin=1), but no dice. I then tried adding javascript into a new page I made, and viewing it. It worked. So now I knew I could trigger javascript on anybody viewing the page I made. Pretty nifty, but not that much closer to my goal. I re-looked at my cross-site scripting stuff and what you can do with it, and saw one way people exploited javascript was stealing the session cookie of authenticated users. After mentally rolling my eyes at myself for not thinking of it, I devised a plan. I would use the XMLHttpRequest in javascript to send the session cookie of whatever user visits my page to me. I could then set it on my local browser. But two problems still existed a) where to send the cookie, and b) how to get an admin to visit my evil page. The second one was easy, with the nifty “report page to moderator” button right there. But the first part was a bit tricky. After a bit of futzing around, I came up with this:

I created a script that created a new page, and told the webservice the contents was just the document.cookie. This code I put into a new page (let’s call that A). Now I needed an Admin to visit that page. I cannabalized the code I had just written to send a post form to report.php, so I could report the page I had just created (page A). When the admin visisted page A, my script ran, and created a new page B, that I then visited to find the cookie. (I had set the ID for the newly created B page to something I wanted, so I knew where to find it). With the knowledge of the cookie, I set document.cookie on my own browser to take that session, then visited the admin required page to get the flag.

Format (70 pts)

This problem was presented as follows:

This program is vulnerable to a format string attack! See if you can modify a variable by supplying a format string! The binary can be found at /home/format/ on the shell server. The source can be found here.

I hadn’t played with format problems before, so it required some research on my part. The code was using the printf() from C to print user input, and I had to change the value of a variable to a specific number in order to get the flag. After some googling I found a nice writeup on stack overflow (because of course I did) http://stackoverflow.com/questions/5672996/format-string-vulnerability-printf. It gives a solid explanation of what is actually happening with the printf function, and gave me a handle on where to go next. As the stack overflow answer says, the variable I wanted was actually on the stack already, and so was my formatted string I had passed in. I can user the pointer that is supposed to be pointing to the next argument passed into the printf function, and move it around. And with a very nifty %n variable that lets me print out the number of characters I’ve already printed to the console, I had all the pieces I needed…

Since the pointer to secret is on the stack, I can use %08x to move the printf pointer up until it’s pointing to secret, then use %n to write the number of characters printed so far into the secret variable So the exploit string should be of format:

[1337 characters][%08x the number of times to move the printf pointer to the ptr variable on the stack]%n

I have 1337 characters listed there because I’m supposed to right 1337 into the secret variable. But the %08x also prints things, so I end up using slightly very characters. The eventual command I ran was:

./format $(perl -e 'print "A" x 1273 . "%08x%08x%08x%08x%08x%08x%n"')