GITS 2015: CloudFS

This CTF was what I’d call an humbling experience; it was an absolutely great contest, don’t get me wrong, but damn! it was hard!, and since I’m not a CTF veteran, let me say that I learned an important thing: “There is no limit to the evilness people can put in their effort of creating challanging puzzles”.

Ok but let’s get back to this specific challenge. For 200 points we were asked to extract an hidden key from a pcap file.

The name of the challenge was an hint itself: cloudfs made me think about something that was used to transfer a file, and by opening a pcap all i could see were some HTTP traffic packets to wikipedia, and loots and loots of ICMP ping requests/responses.

Before diving into the pcap itself i ran through some usual checks you do to spot obvious things, and after having verified that nothing was appended at the bottom of the pcap file, and that it wasn’t a polyglot i started looking closer at the packets themselves.

Fresh from the Persistence competition I figured out pretty quickly that the icmp packets could have been used as a cover channel to hide something, and in fact if we look at the payload data from a couple of random icmp requests we could easly notice that the ping pattern was containing custom data.

The interesting things start at packet 1040 in the pcap file, where we can see the header for a bzip2 file

which was repeating onwards every 4 packets till the end of the pcap file.

I’ve then tried to extract the data payload of the four interesting packets and use binwalk to see if it could extract something useful.

# binwalk -e filtered.pcap

DECIMAL   	HEX       	DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
20        	0x14      	bzip2 compressed data, block size = 900k


It was actually detecting and extracting a bzip2 file, the header was there, after all, but if i tried extracting its content it was informing me that the file was corrupted.

# bunzip2 14.bz2

bunzip2: Data integrity error when decompressing.
Input file = 14.bz2, output file = 14

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

bunzip2: Deleting output file 14, if it exists.


It took me a little while to notice that the pings were sent in an incorrect order, and that it was necessary to reorder them properly.

In fact, let’s look at the icmp packet identifier.

Here it’s possible to notice that the identifier are ordered as 13 14 16 15

I’ve tried to extract the packets payload data separately (after all they were only 4 packets) and reassemble them by hand.

# cat 13.raw 14.raw 15.raw 16.raw > reassembled.raw
# binwalk reassembled.raw -e

DECIMAL   	HEX       	DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
20        	0x14      	bzip2 compressed data, block size = 900k

# ls -la
total 64
drwxr-xr-x 2 root root  4096 Jan 20 20:00 .
drwxr-xr-x 7 root root 36864 Jan 20 20:00 ..
-rw-r--r-- 1 root root 24556 Jan 20 20:00 14

# file 14
14: POSIX tar archive (GNU)

# mv 14 14.tar; tar xvf 14.tar
key
ping/ping.py


and appearently we got the tar archive containing both the key, as well as the python script that was used to create the cover channel

# cat key
key{WhyWouldYouEverUseThis}
`

And this one was one of the simpliest challenges in this contest… so well… congratulations to all the teams that solved a lot of them :)