CanYouCrackIt Part3

Part 3
Postfixing the extracted URL we get http://canyoucrackit.co.uk/da75370fe15c4148bd4ceec861fbdaa5.exe which clearly looks like it will download something executable so time to consider some form of quarantine as allowing some unknown party run arbitary code on your machine is probably inadvisable (not that my computer or attached network controls a nuclear powerplant etc).
The .exe suggests it is back to Windows land.
For disassembly there are a number of options but the sledgehammer is IDA from http://www.hex-rays.com of which v5 is freeware.
Opening the executable in IDA tells us some interesting things...


The program imports cygwin .dlls cygwin1 and cygcrypt-0 so we are looking at a cygwin executable. Cygwin is great; it is free and provides lots of unix tools on the rather command line challenged environment that is Windows. (hm.. Maybe that's why it's called Windows?). I already have cygwin so the temptation to run the .exe it is great but need to resist a bit longer and check the disassembly.

The top



We can see the program likes to be called keygen.exe which is hopeful; we can rename it in a minute in case that is significant.


Now a reference to a file called license.txt and a call to open it for reading.

If it is missing we get...

Otherwise we read it...

We can see an area of memory (a buffer) of 18h i.e. 24 bytes is zeroed and then used to read in a line from the file. There is a possible buffer overflow issue here if the line in the file is more than 24 bytes and potential for code injection but given we don't have a file we aren't too concerned! What this does tell us is that the file content is probably one line of 24 characters.

Then there is a check that the first 4 bytes are hex 71 68 63 67 which given the ordering of bytes packing into a quadbyte register is the character sequence 'gchq'. Cool!

So the 24 byte line must start with 'gchq'


Now it gets a bit more interesting.

This advances 4 characters (past the 'gchq') and calls crypt with a salt of 'hqDTK7b8K2rvw'



Now the details of crypt can be found at http://linux.die.net/man/3/crypt (amongst other places). crypt is a one way hash function which has historically been used for storing hashed passwords; unfortunately it is very weak and open to brute force attacks since only the first eight characters of the password are used. The specification also tells us that only the first two characters of the salt are used so in fact we are just calling crypt on the 8 characters in our string after the 'gchq' with the salt 'hq'. We want the answer, i.e. the hash to be 'hqDTK7b8K2rvw' so all we have to do is find 8 characters that do this and search using brute force to find a solution.

I knocked up a quick program, horrible though it is, as it is single threaded and sub-optimal but it would do the job...

#include <stdio.h>
#include <time.h>
#include <unistd.h>
#include <crypt.h>

int main()
{
   char* seed = "hqDTK7b8K2rvw";

   int i;
   char buffer[8];

   for (i=0; i<8; i++) buffer[i]='a';

   while (0==0)
   {
           char stuff[9];
           sprintf(stuff, "%8s",buffer);

           char* result = crypt(stuff, seed);
           if (strcmp(result,seed)==0)
           {
                   printf("Solution: %s\n", stuff);
                   break;
           }

           int index=0;
           while (0==0)
           {
                   char c = buffer[index];
                   if (c<'z')
                   {
                           buffer[index] += 1;
                           break;
                   }
                  buffer[index]='a';
                   index++;
           }
   }

   return 0;
}

Whilst my brute force program ran it was time to keep investigating the program...


Given our 24 byte string the program then prints a few messages but at the same time it takes a four byte chunk and stores it away as the 'key' from stage 1. It then takes two four byte chunks and stores them away as the keys from stage 2. (Makes you wonder doesn't it... remember the extra baggage we encountered along the way...?)


A check that the preamble in the first 12 (4+8) characters was correct. This is a obviously candidate for a bit of tweaking by patching the executable either by NOPing (90) it out or by adjusting the condition to always branch (but hopefully will have the hash soon...)


This looks quite fun. We are going to resolve a host address and open a socket connection to it. Port 80 (i.e. 50h) looks quite hopeful, probably a web server of some kind supporting HTTP.


Now here we have the business! It will construct a get from a string and the 3 quadbyte hex values. I would expect the string to be the password that matches the hardcoded hash but instead the string reference points at the hash itself... hqDTK7b8K2rvw.

Now speculating that the baggage is the three quadbytes we get 4 bytes from just after the jump in part one and the 2 quadbyte words for 'firmware' in part 2 which gives.

http://canyoucrackit.co.uk/hqDTK7b8K2rvw/a3bfc2af/d2ab1f05/da13f110/key.txt

I must admit I got the byte ordering wrong initially but a quick flip of the four values got the right result. There must be records of my failures at canyoucrackit but I only tried about four possibilities so I don't feel too bad.

The GET results in...

Pr0t3ct!on#cyber_security@12*12.2011+

Which is the final password to be entered back in the original screen....



But you might have noticed we haven't found the password yet so life feels somewhat incomplete... but a few hours later my brute force search finds a solution 'cyberwin'

So all that remains is to construct a license.txt file and try the program.... or should we. If we run the program then potentially we are downloading a file (which might vary between GETs) which could exploit a buffer overflow and run arbitary code on my machine.



I wouldn't run it would I....



Oh well... almost... my licence file validates and generates the right URL... the GET worked from a browser so something funny must be going on...

... but now it's time to get back to my Christmas shopping.

Thanks for the entertainment.

PS

http://en.wikipedia.org/wiki/Roger_Needham would never have published before the end of the competition.. RIP Roger