Monday, April 14, 2014

This was a very interesting and fun challenge. First in order to debug the program live we had to install some dependencies:

Libseccomp: libseccomp2_2.1.0+dfsg-1_i386.deb

Libjansson: libjansson4_2.2.1-1_i386.deb

Now we are presented with the following message when trying
to run the tenement program:

We need to provide a config file for the program. Upon
further inspection of the executable we found that the config file needed to be
in json format and the program expects the json to have two elements a string "key" and an integer array "addrs".

We see that the flag is snprintf into the heap in
the following format: PPPP: FLAG. This will be important to us later when we
want to find the flag in memory. After the config file is read into memory the
executable calls mmap, then verifies (integer inside the addrs array – address
returned by mmap = 4000h). If this check passes the executable copies
the flag into the virtual address space created by mmap and marks the whole
section as read only.

Using this information we were able to recreate the json
config file required to run program:

{
"key":"HEREISTHEFLAG" , "addrs":[-1208098816]}

Sure enough we can verify at run time the flag is
copied into a very high address in memory: 0xB7FDA000.

Vulnerable Function

After the config file information is loaded it calls the
vulnerable function. The function reads 0x80 bytes onto a stack address that is
pointed to by edi, then calls edi.

So we have the ability to put and run any shellcode we want
on the stack. Unfortunately however, if you attempt to run shellcode that executes a
system command like “ls” you get the following message: Bad System Call. The
solution to this problem is to write shellcode that we will use as an egghunter to search memory for the “PPPP” tag, once the tag is found we can call write
and print out the flag the assembly of our egghunter is as follows:

Thursday, March 13, 2014

We're given a hint (Universal dangerous positive) along with an IP (194.226.244.125) and a port (1024) to connect to. They also gave us a password to connect:

We assumed it was UDP because of the hint. Every time we attempted to use netcat UDP, however, it would not respond. We just thought it was down, until eventually it connected once I decided try to connect using python instead. I'm assuming that netcat didn't work because it was also sending the newline character with the sent password, so it would not authorize.

When you first connect, you are are told which directions you can go in the maze, which are other ports on the box. The passwords for those directions are also given.

When you connect to any other port, however, you are not given the port number. So, I guessed that the distance between the starting ports was the same for that entire specified direction and that it was the reverse distance for the opposite directions.

I wrote a script in python to reach each found port. The script can be found here.

The script to a awhile to run (~1 hour), since the maze was almost 256 by 256. The port that contained the key was port 65534. When I first say my script printed the response, I was confused because I didn't remember adding any printing. Then I realized it was the key...

Wednesday, March 12, 2014

For this one, they give us a link to a website and tell us to find the key.

When you visit the site, you're greeted with the english or russian version of the Capture the Flag entry in Wikipedia:

From the hint, "Language was detect automatically", we figured we had to modify the Accept-Language header to obtain the key.

After several attempts, we found out that we have the page echo back any page we want, however, it will attempt to run any PHP code. When we tried to have it echo back index.php, it would attempt to load the file infinitely because the file itself is attempting to echo itself:

After recalling some knowledge of PHP, I remember about the IO streams that you can call, such as php://stdout or php://stdin.

After some googling, I discovered the filter stream. The filter stream can be used to read from a file, not only in its ASCII representation, but in several available formats. We then decided to open index.php encoded in base64:

Tuesday, March 11, 2014

So, first things first, I opened the image using StegSolve. I saved all 8 frames using the frame browser. I then wrote a python script (using PIL) that XOR'd the images pixel with each other. The output was an image that looked similar to this:

I couldn't find any hidden data within the pixels of the image. I then realized that the frames were using palettes, so the mode for the image in python was labeled as 'P'. I decided to convert each one of the frames to mode 'RGBA' instead, because, originally, when I would get a pixel, it return a single value. This way, I could then XOR each red, green, blue, and alpha value of each frame with each other.

I then modified my current script to XOR each of these 'RGBA' mode frames with each other.

I never checked the alpha channel previously or if the image originally had an alpha channel. So, naturally I then found that there was no difference in the new images alpha channels. I then set all alpha channel values to 255, so I could visually see the image (the XOR results were 0 since there was no difference between the images.)

I also noticed how some red pixels of the newly created XOR'd image were not all 0. I then set any red pixel value that was not 0 to 255 so I could easily view a hidden image if there was one. The resulting image was this:

I immediately though that there was some sort of hidden text within those pixel values that were set. So, I open the image in StegSolve. I checked the red channel for steganography and found the key:

Soon after, we discovered that the original paper document was a print screen of an email within GMail. We eventually decided it would be easiest to print out the image and physically put the pieces back together.

Using our terrible school printing system, we eventually managed to print the image. Alas, the image that was printed only contained about 3/4ths of the original image.

So, I then put what pieces I had cut up together and looked at the original image for pieces I did not have.

I ended up numbering the pieces of paper that contained the key, which eventually resulted in finding the actual key:

It also only allows the following characters to be used:' \n\r0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ(),.:;<=>[]_{}'

It also clears the current built ins and replaces them with the "safe" variables:

True False type int

Our code is then executed with access to the divider function which calls we_must_be_sure_flag_part1_is_ready() and returns a different divider function. Divider(v2) checks if int(v1) / int(v2) is EXPECTED, which was initialized to 13.37.

So, somehow magically we're supposed to make two 'integers' equal a float?import black_magic

I first decided to attempt to create another object that inherits the int object. I modified __int__ to simply return what its given. I also modified __div__ to return the float 13.37 every time it is called. I used type to create my new pseudo-integer class object.

This allows so that when I create a new_int using an integer, a(1), performing int(new_int) will return an integer value, but still be of type new_int. Using a float, a(1.0), would cause int(new_int) to return a float value and throw an exception.

The jail doesn't allow me to enter the quote ( ' ) character sadly. Good thing there is a listof strings in div.func_code.co_freevars:

But wait! The plus (+) operator cannot be used AND replace(), join(), format(), and translate() cannot be used!!!

Good thing there is a ljust() function then!
The ljust function takes a given string and returns a modified string at least n wide and fills any extra characters with optionally given padding (default is space).

Monday, January 27, 2014

Given the address: http://54.237.107.251/web5/index.php?page=home, find a key.

Immediately we think that it's directory traversal given the page=X in the URL. We attempt various combinations of /etc/passwd, /flag.txt, /key.txt and so on. We look around for a little while and found

on the index.php page. So we try that e.g. ?page=etc/flag and still get an error. Maybe they're checking for single forward slashes? Seems weird but we'll try to double up on the slashes

Pretty easy for a 500 point challenge considering that many people had a ton of issues with the 100 (we never finished it).

Given an MP3 we are asked to find a key. Normally I just assume that the challenge with MP3 either has multiple tracks or that something that has hidden text.

So I took the track and drop it in Audacity:

We notice immediately that there's a second track...

So we change to spectrogram:

Scroll in...

And we have Morse code. We know that it's morse code given that the longer lines are 3x that of the shorter. So that seems pretty easy for a challenge.. What did we miss? We translate the morse code from left to right and end up with garbage.

We sit around for a little while and figure we just missed something. Maybe it's binary somehow, maybe it's some other representation. After about 15 minutes, someone notices that the actual sound-track (track 1) sounds like it could be backwards. So we read the code from right to left and we get..