Jashan Bhoora | blog

Posted: 10/12/2015

For the past 3 years, I've had the great fortune of being able to participate in a series of Capture the Flag (CTF) challenges hosted by the BAE Systems Applied Intelligence branch. Around each October since I started, they have made the trip to the university (York being just one of the universities they visit) for a day filled with extremely fun, interesting and educational cyber challenges...and free food!

For anyone that hasn't heard of this type of event, CTFs are cyber security competitions. Entrants (usually in teams) are presented with a set of problems covering a variety of topics, and a clue for each one. The aim for each problem is to script/decode/process the problem presented to you in order to find a flag/key. Entering the correct key from the solved problem into the competition website awards points to your team (the amount of points representing how hard the question was to solve). Within most challenges there is also the option to unlock hints, at the cost of being awarded a reduced number of points for that puzzle should you subsequently solve it. The easiest challenges begin at 10 points, and the most complex can award as much as 500 points. (This style of CTF is called Jeopardy. Other types include Attack/Defense and Mixed.)

The BAE CTF has 8 different categories:

  • Binary Exploits - Usually consist of logging in to server via SSH and tricking an executable to giving you the key e.g. causing a buffer overflow.
  • Crypto - Encryption based challenges.
  • Forensics - Digging for hidden messages within an ordinary looking file (.e.g a pptx or jpg).
  • Packets - Analysis of network traffic, often completed using Wireshark.
  • Problem Solving - Quite varied, often involves writing a script to automate some task whilst interfacing with a server.
  • Reverse Engineering - Analysing how a file/executable is written/runs, then modifying or exploiting some detail to get the key.
  • Web - Exploiting weaknesses within a website to access otherwise forbidden content that contains the key.
  • Trivia - Obscure technological facts (and unashamedly geeky) puzzles, that (in my teams case always) require a lot of Googling to solve.

My favourite go-to catagories for the challenges are usually Reverse Engineering, Packets and Forensics, but in the heat of the competition everyone usually just jumps straight in to solve whatever they can for the team.

The challenge lasts from 10:00 til 16:00, and aside from a break for a free Pizza Hut lunch the day is a fun and frustrating (in a good way!) frenzy to try and get as many points as possible.

This event has easily been one of my biggest highlights over the last 3 years. (I made the trip up to York from Cambridge this year just to compete!) I've learnt so many small details and tricks from participating, and it offers the chance to do all the sorts of things with computers that we aren't normally allowed to do!

An important point about the BAE CTF is that anyone (in the department) is allowed to enter, regardless of year of study or experience. This push goes a very long way to getting lots of people involved, and making it all the more fun. Indeed, I had little idea what I was in for when I entered in first year, but it didn't matter!

I thought I'd use a couple of blog posts to walk through a couple of the challenges that really captured my interest, and how I went about solving them. All the challenges are written by the CTF team at BAE Systems, so all design credit goes to them.

The first one I wanted to walk through is one of the Forensics challenges, called "A Place For Everything". In this challenge we were given just a file (without a filetype extension), and were told to find the key.

The first thing we need to know is what kind of file it is, before we can start trying to read anything from it. The Unix file command is useful for this task. (In the screenshots below I'm using an Ubuntu VM under Windows 10, which is exactly what I used in the latest competition).

Ok, so now we know the file is an ELF file, which is a Unix executable. Wikipedia gives us some good information about it's internal structure etc. Naturally, we'll want to try and run it and see what it does.Changing the permissions of the file the allow it execute and running it give us this...

Our first clue in the challenge! It even mentions the key, so we know we are on the right track.Running the file multiple times gives the same output, so that's a dead end. Something I always like to try at this stage is running the file in question through the Unix strings command, which simply prints out any strings it comes across in the file.

A couple of interesting lines to point out are 11 and 501-504 (and similarly 529 etc.). 11 is the string that was printed out when the program was run, but more interestingly 501 to 504 refer to something to do with a .key1, .key2, .key3 and .key4.

Strings can sometimes be useful, but alone it is quite a limited approach. To me, the biggest hint so far was the word "sectioned". I haven't worked much with ELF binaries in the past, however it struck me that the standard parts of a binary are called sections. Therefore, maybe the key is in one (or all) of these sections? A quick search for "ELF sections" confirmed what I thought, Google even presents a table with some of the standard sections of an ELF binary.

Notice how all the standard sections begin with a dot (.). Having run strings, I know that the standard sections (shown in the table) were found (line 500, 505 etc.). Also notice how all the section names are found in the same area in the output (this is a bit of a tenuous link). It might therefore be possible that the .keyX's are actually custom sections themselves that somehow contain the key? Again, a search for custom ELF sections brings up results showing it is possible to do, and then go on to detail how it might be done. However, we are more interested in what they contain...

So, now we need to dive in to the ELF sections themselves. Wikipedia is an excellent place to start to read about the internal format, and a crucial Unix command to work with the format is readelf.

Let's first make sure the key sections actually exist. I'll run readelf aplaceforeverything -S to print out the section headers and offsets. Looking at the output, we can clearly see that sections 25 to 28 are indeed the keyX sections.

Lets dump a section to find out what it contains. .key1 seems like the right place to start, so I run readelf aplaceforeverything -x .key1, which gives this terminal output.

The big clue is in the very first line of the hex dump. JFIF is part of the file header for a JPEG image. Therefore, if we assemble the key sections into one file in the correct order, we might get a valid image.

Readelf doesn't dump the raw output of a section, so an answer from Stack Overflow prompts me to use objcopy instead. I used objcopy -O binary --only-section=.key1 aplaceforeverything key.jpg to dump the binary output of .key1 into a file called key.jpg. Quite unexpectedly, a valid image immediately falls out!

So there's the key for this challenge! For the sake of completeness I ran the same command for the remaining 3 sections and concatenated the resulting files, which gave this image (which in itself I find quite interesting):

Of course, this is by no means the only/best/most efficent way of going about solving this problem. For example, in hindsight it probably would have been quicker to skip using strings entirely, and have used readelf as soon as I knew I was working with a ELF binary. This is just how I happened to approach the problem the first time around.

Recognising the JPEG header in the first key section was the big hint (for me) in working out how to find the key. The best part about this is that I only recognised the header because a question involving JPEG headers had come up in a previous CTF, and at the time I completely glossed over it. Only by playing the challenge again and again was I really able to apply what I had learnt, and it's for reasons like this I think that anyone with such an interest in these sorts of problems should enter CTF's if the opportunity should arise. Regardless of experience, there is something for everyone to do and learn. There will always be a challenge that every team can do easily, and (in the case of the BAE CTF's), there's always been one or two challenges at the end that no team was able to solve in time.

I personally haven't entered any CTF's other than the BAE events hosted at York, but I'm definitely hoping to do more in the future, inside and outside of University. Hopefully I'll post a walkthrough of another challenge at some point too. CTF Time looks like a very interesting place to get more involved, so I think I may start there, and maybe I've persuaded you to give them a try as well...

6/2/16 - I've entered my first public CTFs since writing this. There was a bit of a learning curve compared to playing in the BAE CTFs, but the team is improving. All the challenge writeups I do in the future will be posted on a central CTF Writeups Repository on Github, which you can find here. Hope you can take a look!