Ghost in the Shellcode on System Overlord

Ghost in the Shellcode 2014

david@systemoverlord.com (David Tomaschik) — Tue, 21 Jan 2014 04:57:33 +0000

A quick Ghost in the Shellcode 2014 summary. Great CTF, but you better know your binary exploitation. I’m pretty happy with the overall 27th finish Shadow Cats managed. Here’s a summary of our team writeups, the first 3 by me, the last one by Dan.

Ghost in the Shellcode 2014: Radioactive

david@systemoverlord.com (David Tomaschik) — Sun, 19 Jan 2014 20:21:46 +0000

Radioactive was a crypto challenge that executed arbitrary python code, if you could apply a correct cryptographic tag. Source was provided, and the handler is below:

#!python
class RadioactiveHandler(SocketServer.BaseRequestHandler):
 def handle(self):
 key = open("secret", "rb").read()
 cipher = AES.new(key, AES.MODE_ECB)

 self.request.send("Waiting for command:\n")
 tag, command = self.request.recv(1024).strip().split(':')
 command = binascii.a2b_base64(command)
 pad = "\x00" * (16 - (len(command) % 16))
 command += pad

 blocks = [command[x:x+16] for x in xrange(0, len(command), 16)]
 cts = [str_to_bytes(cipher.encrypt(block)) for block in blocks]
 for block in cts:
 print ''.join(chr(x) for x in block).encode('hex')

 command = command[:-len(pad)]

 t = reduce(lambda x, y: [xx^yy for xx, yy in zip(x, y)], cts)
 t = ''.join([chr(x) for x in t]).encode('hex')

 match = True
 print tag, t
 for i, j in zip(tag, t):
 if i != j:
 match = False

 del key
 del cipher

 if not match:
 self.request.send("Checks failed!\n")
 eval(compile(command, "script", "exec"))

 return

So, it looks for a tag:command pair, where the tag is hex-encoded and the command is base64 encode. The command must be valid python, passed through compile and eval, so you’ll need to send a response back to yourself via self.request.send.

Ghost in the Shellcode 2014: Lugkist

david@systemoverlord.com (David Tomaschik) — Sun, 19 Jan 2014 19:43:56 +0000

Lugkist was an interesting “trivia” challenge. We were told “it’s not crypto”, but it sure looked like a crypto challenge. We had a file like:

Find the key.

GVZSNG
AXZIOG
YNAISG
ASAIUG
IVPIOK
AXPIVG
PVZIUG
AXLIEG

Always 6 letters, but no other obvious pattern. I did notice that the 4th character always was S or I and the final character G or K, but couldn’t make anything of that. I realized the full character set was ‘AEGIKLONPSUTVYXZ’. Searching for this string revealed nothing, but searching for the characters space separated revealed that this was the same character set as used by the codes for the original Game Genie. And Game Genie codes were 6 characters long.

Ghost in the Shellcode 2014: Pillowtalk

david@systemoverlord.com (David Tomaschik) — Sun, 19 Jan 2014 19:11:27 +0000

Pillowtalk was a 200 point crypto challenge. Provided was a stripped 64-bit binary along with a pcap file. I started off by exercising the behavior of the binary, looking at system calls/library calls to see what it was doing.

Client connects to server
Server reads 32 bytes from /dev/urandom
Server sends 32 bytes on the wire (not same bytes as read from /dev/urandom)
Client does same 32 byte read/send
Loop:
- Server reads a line from stdin
- Server sends 4 byte length
- Server sends encrypted line
- Client does the same steps

My first approach was by trying to use scapy to replay the pcap to the server, but this only gave complete noise, so I decided the two 32 byte values must be significant. I even tried controlling /dev/urandom (via LD_PRELOAD) to see if putting in the 32 bytes from the pcap would get to the right key. It didn’t.