this past weekend was the Nullcon HackIM CTF; again, i competed with the #misec team. it was a Jeopardy-style CTF, with a wide range of challenges to solve.

Programming 200 was a challenge called “lazy baba”. the challenge just said gives answer once in every 4 hours, and then linked to a page called answer.php. when i clicked on the link to the page, it was blank.

j3remy, one of my teammates, asked if someone could write up a script to grab that page every minute. i wrote the following bit of python, and set it running on a shell server to which i have access:

#/usr/bin/python

import time
import urllib2

while True:
    filename = time.time()
    filename = str(filename)
    response = urllib2.urlopen('http://ctf.nullcon.net/challenges/programming/answer.php')
    html = response.read()
    f = open(filename, 'w')
    f.write(html)
    f.close
    time.sleep(30)

the script worked very simply: it grabbed the contents of that answer.php page, saved it as a text file with the timestamp as the filename, slept for thirty seconds, and then repeated. even though j3remy suggested every minute, i decided to do it every half a minute just to be on the safe side, since i didn’t figure that it would be a huge deal from either a network resources or disk space perspective.

a few hours later, i went into the directory, and ran an ls -l. there were a bunch of files titled with time stamps: the vast majority were one-byte files, but two consecutive ones were 32 bytes long, not one. i catted them, and each of the 32-byte files were the same:

Flag is ABRAKADABRAGILIGILIGILI

sure enough, that was the flag.

if i were more on top of things at the time, i could have added some logic to exit the program to kill it if i pulled something that looked different than the other files it pulled, or to not save the file if it was just a one-byte file. you live, you learn, and you program more efficiently next time, i guess.

however, this quick and dirty little guy did the trick.

in furtherance of my goal to get better at CTFs, i’m taking a stab at another one. some of my co-workers told me about Mini CTF, and i’ve finally started attacking them after two weeks of being sick, out-of-town meetings while sick, and generally being too exhausted to think.

i’ve tackled one of them so far, entitled “Crack the Code”. it’s a zip file, and when you unzip it, you get a python script called crackthecode.py. i’m always happy to get a CTF problem that starts with a python script; since i’m a fairly decent python programmer, it means that i have a snowball’s chance of figuring out what the code is doing.

reading the script, it takes a seven-digit code as an argument, and checks it for certain two-digit sequences at the beginning of its SHA-1 hex digest, its SHA224 hex digest, its SHA256 hex digest, and its SHA512 hex digest. if all four of those match the digits prescribed in the validatecode() function, then it uses the code to decrypt a ciphertext, which ostensibly gives the key when decrypted.

fortunately, it’s obvious from the code that the key is the string representation of a seven-digit number. seven-digit numbers sounded like a relatively small keyspace, so i decided that i’d write a little script to brute force the answer: looping through each possible seven-digit code, using the validatecode() function from the code in the problem to test the hashes on each possible code, and then printing out a code that worked. this was the script i wrote:

#!/bin/python

import hashlib
import sys

def validatecode(code):	
	sha1 = hashlib.sha1()
	sha1.update(code)
	
	sha224 = hashlib.sha224()
	sha224.update(code)
	
	sha256 = hashlib.sha256()
	sha256.update(code)
	
	sha384 = hashlib.sha384()
	sha384.update(code)
	
	if sha1.hexdigest()[0:2] == 'a6' and sha224.hexdigest()[0:2] == '7b' and sha256.hexdigest()[0:2] == '57' and sha384.hexdigest()[0:2] == 'db':
		return True
	else:
		return False
		
		
if __name__=="__main__":
	digits = ["0", "1", "2", "3", "4", "5", "6", "7", "8", "9"]
	for numone in digits:
		for numtwo in digits:
			for numthree in digits:
				for numfour in digits:
					for numfive in digits:
						for numsix in digits:
							for numseven in digits:
								code = numone + numtwo + numthree + numfour + numfive + numsix + numseven
								if validatecode(code):
									print code + " works!\n"
									sys.exit()

i wasn’t completely sure how long this was going to take, given that crypto functions in python aren’t the fastest things in the world, but it was worth a shot given the relatively small keyspace. fortunately, after about a minute, a key popped up in my terminal:

root@bt:~/minictf/crackthecode# python codemaker.py 
3495745 works!

and then, putting 3495745 into the original script from the zip file yields:

root@bt:~/minictf/crackthecode# python crackthecode.py -p 3495745
IRISSCON 2012 - Crack the code!

Code correct!. Decrypting message...
Hi There!
The KEY is: 44859c3554ee157264297d62d8aeef64685c57549051836001e14b8821ab6a0f !
Enjoy...

success! the answer really was right in front of me — given that the majority of my solver script was a function lifted right out of the original problem. most CTF problems aren’t that easy, but if they are, it’s nice to quickly identify that you don’t have to reinvent the wheel.

it’s amazing how you can space out on the most basic things while trying to solve a CTF problem.

last weekend, i was trying to help the #misec team with a few of the problems from the 29c3 Capture the Flag. the two i spent the most time on were a reverse engineering problem and an exploitation problem.

the one i’m going to talk about here is the exploitation problem, the Minesweeper game. there were two really idiotic mistakes that i made on it, and i would have had quite a good chance of solving it if i didn’t make these two blunders. i won’t go through a full write-up of the problem; there are multiple writeups on CTFTime from teams who actually managed to crack it during the time allotted. however, i shall touch on the lessons i learned.

we had a lot of information available to us for the exploitation problem: specifically, the Python source code for the Minesweeper game, as well as host and port information for the running instance on the CTF server. given my familiarity with the Python language, i grabbed the source code, read through it to get an idea of how it worked, and played around with it. i fired up telnet, connected to the game, and started interacting with the game. the problem was, i kept getting syntax errors. it didn’t matter whether i know i’m rubbish with regular expressions, but i was sure i had the commands for saving, loading, flagging, and opening spaces absolutely correct — not only did i spend a bunch of quality time with the python regex documentation, but i also compiled the regexes independently in my python shell and verified that the commands i was sending matched the regexes in the source. still, no dice. i was flabbergasted — here was this program that i was supposed to exploit, this program i thought i understood, and i couldn’t even get it to work the way it was supposed to!

turns out, the problem wasn’t in my understanding of the program. the problem was the way i was talking to it. once the CTF closed and i started reading write-ups of the problem, every single team talked about using netcat. one of them even showed a screenshot of their interactions with the game, and their commands looked exactly like the ones i sent. sure enough, i tried it with netcat, and it worked. i fired up the old wireshark, sniffed my traffic — and found out that netcat sends a \x0a as a line terminator, whereas telnet sends \x0d\x0a as the line terminator. since the script was only expecting \n as a line terminator and not \r\n, this was my fatal (and extremely silly) error.

even while the competition was going on, even while i could use the minesweeper game to actually play a game of minesweeper, i assumed the vulnerability was going to be related to the load function. it allowed you to interact with files on the machine, so i assumed that it could be somehow exploited to load arbitrary files, including flag.txt. however, i was so hung up on that and other things to go much further than that, and i envisioned the vulnerability to be something where i could get the code to read the flag in as a saved file.

that wasn’t quite right. it’s not so terrible, of course, that my idea wasn’t correct right off the bat. what’s shameful about all this is that i didn’t think particularly deeply about the module that the program was using to save and load games — specifically, the pickle module. i hadn’t thought twice about pickle in years, since back when i was learning python at first. i knew it was a module used for serializing and recovering python data, but it never really came up in code i was writing, so i never dug through the documentation. however…the pickle module documentation is emblazoned with a warning that it is not intended to be secure against maliciously constructed data, and a quick google search for python pickle vulnerable turns up several nice descriptions for how to make pickle execute arbitrary code.

i spent some time this afternoon playing around with that — refreshing my memory on how pickle serializes and rearranges data, and getting pickle to execute random commands on a my linux box. it’s good knowledge to have now, but it was really not particularly difficult to understand, or apply to a situation where a program processed arbitrary pickles. if i had thought to google the module that the load function was possibly using, i would have had some concrete advice on how to own that Minesweeper game.

lessons learned: one, try multiple ways to connect to a service. if code is not behaving in the way you expect it to, and i’m convinced that i understand the source code for the service with which i’m interacting, maybe the problem lies in the client i am using. secondly, when given source code for a problem, do some research behind the libraries and functions it uses, because there may be some related vulnerabilities that could provide the trick to the problem.