#hackthissite

[comp6841]

Hack This Site - Forensics #2

This one here is quite interesting in the sense that we have to determine if an image has been digitally modified. The image we’ve been given is below; looking at it from a distance nothing seems too obvious and stands out. If you zoom in on the edges of the woman they look a bit dodgy but we need to prove this more definitively.

I looked into some of the techniques you can use for determining modification of an image - one of them is known as “error level analysis”. The idea behind it is that if another object has been “photoshopped” into an image, there will be different compression artifacts in different sections of the image. For example, if the image of the woman was extracted from a higher resolution image, you would be able to distinguish this when it is compressed to be added to the selfie above. There is actually a pretty cool forensics tool online at www.fotoforensics.com to do this:

You can see in the ELA how she was clearly cropped into the image and conveniently enough the password appears to be written in the top left corner, “ELA4LIFE!!”

[comp6841]

Hack This Site - Application #17

Not just from the fact that this was marked as hard, this one definitely looks difficult in the sense that our password (or key) is unique to the username. As usual we start with the Intermodular References to look for reading the console input:

We put a breakpoint on this call and then follow it up:

Here I’ve discovered a loop of sorts which will read one character at a time from the input. Following it up further we’re inside a larger loop:

I don’t really need to know the details of this loop, except to know from debugging that we exit all the loops after pressing “Enter”. Now this returns to another function (I’ve conveniently already debugged it all and labelled):

So basically we read in the username, assembly a “Password :” string and print it, then read in a password. Then we call a function which appears to verify the password. I’ll go into the contents of this in more detail:

The first important thing in this function is that we are grabbing the password input and comparing the first 4 characters to a code - namely [0x120, 0x150, 0x14C, 0xB4]. This involves bitshifting the input character left by 2 first - therefore we can reverse this code by bit shifting it to the right which gives us [’H’, ‘T’, ‘S’, ‘-’]. So basically we’re just checking it is of the required format.

The next bit seems to be referring to the section beyond the “HTS-” in the user’s password. It seems to be expecting this length to be of 13 (based on the loop length) so passwords should be of the form “HTS-XXXX-XXXX-XXXX”. In this loop (as commented) it basically checks that the dashes are all in the correct positioning. In the next bit we are removing the dashes:

I didn’t bother commenting it as it’s easier to just observe the debugging output and see it places the resultant string after the loop:

So now we have a string with the “HTS-” and other “-” removed. Then next part I’ve gone through and debugging quite detailed:

Basically we’re verifying that the extracted password (without dashes and “HTS”) is exactly 2 times the length of the username. We also check the username isn’t 0 and then extract the hexadecimal value of the first 2 characters in the given password.

The next section is quite confusing however I’ve documented what is happening alongside the assembly code. (if you want to read) I’ll try and summarise what is happening:

Start with a code of 0

Loop over the length of the username (for each i)

shl eax, cl => username[i] << (code & 0xFF)

sub esi, esx => username[i] - code

sar esi, 1 => (username[i] - code) >> 0x01

not eax => ~(username[i] << (code & 0xFF))

and esi eax => (username[i] - code) &  ~(username[i] << (code & 0xFF))

Set the code to this result

ModifiedKey += Hex(Code) (2 character value)

Add the “HTS-” to front of modified key and add a “-” after every 4 characters

So basically I only really needed the first section; the second half of the above image didn’t really matter at all. In the end I implemented this in a keygen in python:

Running the program we get the following:

And running in the program we get the result:

And we have completed the challenge! This one was definitely complex and took forever, however it was pretty cool to get more experience with x86 assembly.

[comp6841]

Hack This Site - Application #9

This challenge was interesting in the sense that when you click the “Play” button it produces a sequence of sounds and tells you to match it with the buttons. I think they are just screwed with us here so let’s just decompile it. The first thing I decided to take a look at was the “Intermodular References” as it had helped us in previous challenges... one of the calls sparked my interest, namely “msvbvm60.rtcMidCharVar()”:

When I inserted a breakpoint on this section of code, it didn’t actually run so I thought I would trace back and see where it goes back to:

This section bit looks kinda familiar to some of the previous VB6 challenges - it’s an event handler of sorts. Naturally I just breakpoint all the sections to see what’s up - these were my findings:

Basically the first couple jumps were triggered by the buttons and the final one (I had to disable the breakpoint again) was some sort of function that kept on getting called on a loop. Digging into the “Play” button functionality:

Interestingly enough we see 3 calls to app9win.sub_40519C() and we actually hear 3 beeps when we click this button - if you dig down further you can see the actual call it makes to the system. However we have two input arguments named (0x64, 0x12C) in the first one which correspond to the (frequency, duration) arguments of the call. You can see how the duration remains the same in all the calls, however the frequency varies. Now I looked into the call for “Match 1″:

We can see the beep call being made again with the same duration, however it is putting in the value of EDX which comes from [esi+34]:

I basically went into each of these buttons and set the frequencies of the values called into the beeps to the values specified in the ‘Play Button’ - this was a buffer set earlier in the main; I could have dug up the buffer, but it was just as easy to stop execution at [esi+34], etc and just modify the values for each. The buttons gradually changed to green then finally I got the result:

So that must have been what the secret loop function down the bottom did... and we have our answer!

[comp6841]

Hack This Site - Application #5

This challenge here involves a Console, so hopefully its not ‘clusterfucked’ with all the Windows GUI bloatware.. a quick decompile and we already get some cool stuff:

Now this line here is the important one:

All we need to do is force this call with a “jump” and we can skip the invalid password call...

Well that’s not exactly what I hoped for, so something else must be going on here... I decided to play around and debug the code for a bit and there was a particular check and jump which sparked my attention:

Note the comparison which occurs at x4010c3 and the subsequent conditional jump instructions - if we don’t meet the condition we go straight to ‘Invalid Password’. Now notice this value is dependent upon ‘ebp’ (the stack pointer) and a temporary value known as ‘edx’ - if we look up a bit further we can see that it this value appears to be set initially and we are subtracting 1 from it each time... in fact if you trace the operation you’ll notice that this is actually a loop. From the debugging session on the first run I was however to dump what was at the given address:

The dword referenced on the first run of the loop is ‘powe’, ‘rtri’, then ‘ppin’ and finally ‘g’. So I thought I would try this as the password on my unmodified version of the file:

Sure enough it didn’t repeat ‘Invalid password’ and repeat the password back to me!

[comp6841]

Hack This Site - Realistic #11

Looking at the source code of the main page, everything seems to be controlled from a Perl script:

If you fiddle around will calling the Perl script, you can see it actually checks to see if files exist in a pages directory. We can abuse this script to pipe in a “ls” command through |ls| as the input; this should print out the directories/files:

I checked out the admin page and it seems legit and not actually vulnerable. “client_http_docs” actually contains all the web servers they host, however the one we need to break into actually has their account suspended. There is only one other web server which is really active which is under the name of “therightwayradio”. Clicking on some of the user info on the site I noticed the following:

You could switch around the user “id” and find all the different users - interestingly enough looking at the base case of id=0 gave me some admin user of sorts.

I was basically able to set the password under this panel then login to the moderator account. There was a page for SQL access for mods:

However this only provides SQL access to the database for this local website if you look in the code:

However from our directory scan earlier we know the main database is “bs.dbase” so we can modify this so it’s working on the database we’re after at “../../bs.dbase”. Then since we know its SQLite we can try a query to look around a bit:

Now we pull from the “web_hosting” table:

Then I logged into “therightwayradio” and had a look around - interestingly there is a download button. If you dig into the source after clicking the button:

If you watch where the download is coming from in the network table, you can see that “d.pl” is actually under the admin directory... so from this you can craft a URL to download the actual file:

I should probably mention I also tried hijacking sessions with XSS which involved me setting up a website to supply the cookies too. However this didnt work unfortunately.. however, maybe I might be able to use this in a future challenge!

[comp6841]

Hack This Site - Stego #2-#5

Stego #2

So in this challenge we’re basically given a .wav file that we need to extract information from. Now we could walk into this blind and keep trying to extract bits or we could use a cool Sonic Visualizer tool. Basically what you have to do is add another layer to the visualizer - you need to use a add a spectrogram to it. Basically what this will do is provide a visualisation of the sound file - you have time along the x-axis, frequency along the y-axis and intensity is determined by the colour at that particular point.

Applying this information to our “.wav” file we can extract the codeword:

Stego #3

Basically looks like a completely empty image at first-sight however my first instinct was to apply error-level analysis to it. Then I was immediately able to see where the small text was located:

Stego #4

My immediate instinct with the ‘hexed’ message was to bring it up in a HEX editor... looking right at the bottom I see something suspicious in binary:

Plugging this section into a binary converter online:

and we get the code ‘p68cq1hb’.

[comp6841]

Hack This Site - Forensics #3

Looking down the file names nothing seems to stand out in this one, except for the fact of how damn big that “shh.jpg” is - it is in compressed JPG format and has a resolution of only 500x500 pixels. Right next to it is a file “siggies.txt” which contains header codes for a number of files..

So there is probably a good chance we’ve got to search that damn image file for all these headers. Now my initial thought was just to grab some software to dig it for the formats, however where would be the fun in that! (plus I doubt they made it that easy). So basically I wrote a program in Python to dig for JPG, PNG and RAR headers and terminating byte strings. Initially I couldn’t find anything but I adjusted it to flag potential matches with header corruptions. Here’s the code:

It’s a kinda “hacky” and inefficient method of doing it but it gets the job done. Basically we search for the headers and find to what % they match; if the user accepts the terminating header we give them the option to save the file. The program will patch the basic headers to fix any potential minor corruption. Now I searched the JPG file for these components:

(I had a fair bit of trouble with the “RAR” file and had to play around with the termination points to get the right result) So we found a couple of images and a .rar file (note how the RAR header file had been corrupted and it didn’t initially show up). Here’s the result:

So we have found an extra image file with “GL0zMe” and the RAR file is password encrypted... I wonder how we could open it?

And would you look at that - so much incriminating pizza evidence of illegal pizza trading!! Plus a secret login file...

Reflection

I actually found these 3 forensics challenges pretty fun - number 2 was pretty cool in looking into the sort of details you can extract from modified images that we don’t normally think about. In number 3, having to write a program to locate the headers and whatnot to extract out of an image file was pretty interesting too. It just gets you thinking about how many different locations information can be hidden within file systems. In terms of transferring data securely, it could be a pretty cool method to steganographically hide an encrypted message inside an image, video, application, etc.

[comp6841]

Hack This Site - Programming #2

In this challenge here we are essentially required to extract a Morse code out of an image based on the positioning of the dots. Then we need to translate to an ASCII code; all of which we must be able to do in under 15 seconds. I implemented a class to solve this for me:

Basically what we do is keep scanning a directory in a loop for “PNG.png”.. so when the challenge opens I just drag the image in. Then it will load up the image, and traverse the pixels to extract the Morse code. Then we can just use the inverse dictionary to find the representative characters.