The full scoreboard is available on CTFTime.org and includes 22 teams (limited to teams which solved at least one task).
As far as tasks go, the CTF offered 19 tasks altogether, split as following:
5 x Exploitation
4 x Reverse Engineering
3 x Web
2 x Cryptography
2 x Steganography
1 x Miscellaneous
1 x Networking
So yes, it was a binary heavy CTF with some diversity in other categories. A brief solution to each of the task can be found on the following slide deck (originally used during a post-CTF task presentation just after the CTF):
And that's it for this year's edition. Once again, a big round of thanks to all the players, as well as to the CONFidence conference organizers and Dragon Sector team members and our friends for making this happen!
Our CTF in Kraków ended today - big "Thanks!" goes to each and every team and player that participated, we hope you had fun :). After 27 hours of playing and quite a lot of shuffling going up all around the scoreboard, the winners were decided: 1. MSLC 2. H4x0rPsch0rr 3. SpamAndHex Congratulations! We'll probably write another post about the CTF/tasks/etc later on (after everyone gets enough sleep - currently some of our team members had forgotten what "sleep" is), however due to popular demand we wanted to publish the slides of our post-CTF presentation during which we explained the key points of all tasks we published during the CONFidence 2015 CTF:
Link: Tasks Explained
(It's a Google Slides presentation. To download in PDF please click File → Download → PDF.)
Please also find a quick photo of the final first page of the scoreboard below. And with that we'll end this post for now - good night!
This is just a short reminder that the CONFidence Teaser CTF organized by Dragon Sector will take place this weekend, and more specifically starting 25 April 2015, 10:00 CEST until 26 April 2015, 10:00 CEST.
The registration has just started at the event's website, https://ctf.dragonsector.pl/, and will stay open all throughout the game.
A quick rundown on the basic information is as follows:
Start: 25 April 2015, 10:00 CEST
End: 26 April 2015, 10:00 CEST
Duration: 24h
Format: online, jeopardy, team-based, no team size limit, teaser
After selecting this challenge we were welcomed by a rather laconic description:
Once connected to the service, we were greeted by the following menu:
Menu
It appeared to be some kind of a storage service for ASCII art. We could upload ASCII arts, add comments and apply filters. After fuzzing the input for a while we didn’t discover anything useful, so it was time to look inside the executable.
Reversing the binary
The file command
revealed that it was an x86 ELF executable. After opening it in IDA we
could see a main loop which was responsible for displaying the
minimalistic menu shown in the previous picture. Its C representation looks something like that:
Main function
Because vulnerabilities are often caused by badly handled user input it is a good idea to look for some potential overflows. There are 3 places where input from user is requested:
the read_3_digitsfunction
the add_artfunction
the add_commentfunction
Unfortunately we were not able to find any obvious problems in the code. In every single place the length of input was limited and buffers were large enough to store the input data.
When adding a new structure, the program looked for the first free slot and placed the structure there. We reconstructed the “art” and “comment” structures, which were both 256 bytes long:
Vulnerability
These structures were filled when a new ASCII art or a comment was added. The interesting fact was that, when a comment was added, 252bytes of input were read into a buffer of size 251, so there was an overflow after all!
It was just a single byte, but that was all we needed. Using this one byte we could overwrite the first byte of the next structure which was a type field. So we could convert a comment object into an art object and vice versa. The first one was particularly useful because when a comment was interpreted as an ascii_art then the first 4 bytes of the comment string were interpreted as a function pointer named “filter_method”. By applying a filter we would be executing arbitrary address with our string as first argument. In other words, we could simply call system() and get a remote shell. :)
All we needed was to overwrite a comment and change it to art.
After that there would be two ascii_art structures with the same id
(ascii art and its comment converted to ascii_art). We needed our
transformed comment to be earlier in memory so that it was selected
first. We achieved this by making use of the remove_comments function. This step could have been done in many different ways but we discovered the following first:
Add two ascii_arts A1 and A2.
Add two comments C1 and C2 (Cx is a comment for Ax).
Add ascii_art A3.
Remove comment C2 and add comment C3 (it will be put in C2’s place).
Remove comment C1 and add comment C2 (it will be put in C1’s place).
With
the last one we overwrited C3’s type field and turned it into an ascii
art. It was placed before the original A3 and thus when ascii art with
id=3 was requested our spoofed art was selected. Applying a filter
resulted in arbitrary address call with the argument being an address of
a controlled string.
Exploitation
Because ASLR as well as NX were enabled (no PIE/RELOC though), we needed a memory leak in order to call the system function (or we could have created a ROP but come on - we had function call with our string as argument).
Fortunately for us, there was a printf
function imported by the executable, so we could force a format string
vulnerability by simply calling it with a controlled string. Sadly, our
format string was not stored on the stack, so leaking .got entries
became much, much harder than it typically is.
Cheer up, not everything was lost. The “main” function is not called directly at program startup but through the __libc_start_main function which is a part of libc, so the return address from the main function also resides in libc. And this one is definitely on the stack.
After
finding the correct offset and leaking the address, all we needed to do
in order to get the flag was to find out what version of libc the
system was using (so we could calculate the distance between the leaked
return address and the system
function).
In the end, we failed to identify the specific libc build
and consequently had to brute force the offset remotely. It took
approximately 8 hours, but we eventually got the system address right and obtained the flag.
Conclusions
To exploit this challenge we used function pointer overwrite, combined with custom memory management, and then forced format string vulnerability by calling printf function. Knowing libc base address we called system() and spawned remote shell.
It was a great CTF challenge and I personally enjoyed how the solution leveraged one vulnerability to cause another. I thank the organizers for interesting contest and I hope it will be even better next year.
Here you are, playing a CTF with you mates in Hamburg. You notice there's a new task, “Nokia 1337”.
Enter the trilogy: pwn this phone. Please use only the qemu provided. Remote instance requires proof of work: nc 188.40.18.78 1024Connect locally via telnet to localhost:10023 after qemu booted completely.
Club Mate and Rum (it's called a Tschunk!) in hand, you give it a shot...
The challenge
The challenge is the first part of a trilogy of awesomeness prepared by the organizers of the 31C3 CTF. You were given a qemu machine that booted up into a Nokia-like ncurses interface. The machine was an emulated Xilinx Zynq ARM SoC. There was a low-privileged mobileuser and a root user. The mobile user had the ncurses UI (a binary with DWARF debug symbols, phew) set as a shell. There was also a baseband communication coprocessor that was essential to solving the second and third parts of the challenge.
Locally, we could log in as root and see that there was a /home/mobile/flag file, containing placeholder text. Remotely, we could only access the ncurses UI via telnet. Obviously, we had to get remote code execution through the UI and read the flag.
The “phone” didn't have that much functionality. You can send and receive SMS messages, save, remove and retrieve contacts, and save, remove and use SMS templates. All storage was handled by an SQLite3 database.
The bug
As previously mentioned, the UI is a DWARF-enabled ARM binary. It's nonrelocatable, and has a writeable and executable data section. This makes our life easier.
After doing some analysis of the binary, I found an interesting function - db_get_template, which is used to retrieve a saved template from the database into a buffer. Why is it interesting? Well, let's take a look at its' signature:
Set sail for fail.
The index parameter is given by the caller to identify the ID of the template we want to retrieve. intidptr can be provided by the user to get information on the internal DB ID of the template. textptr is the output buffer address given by the caller. lenptr can be passed to receive the amount of data written to the buffer.
As you might've noticed, there isn't really a way for the caller to get the template length before calling the function - this looks bad. So, where is this function used? Well, when we wish to insert the template into our SMS. Here's the relevant code:
Iceberg, right ahead!
This is the code called when the user selects a template to be inserted into an SMS message. text, at 0x1C600, is a global buffer of the currently edited text message, text_len is a global int of the current text message length. How large is text, you ask?
Your shipment of fail has arrived,
And since a template can also be 160 characters... Whoops! We have an overflow past the end of this buffer.
The exploit
Let's see what can we do with this. What's past this buffer? There's a 0x30-byte long structure named screen_input_dialog_arguments that contains data on how an input screen module should be called when inputting a number (when sending a message). While there's a few function pointers that we could overwrite there, there are also a whole bunch of pointers into complex structures. While doable, it's not something I'd like to have to fix up with my exploit in order to get one of the pointers called without crashing. Maybe there's a better attack vector?
Eww.
The next structure that we can overflow is screen_sms_write, a structure defining the callbacks that are called by the UI layer when we leave, enter, or input data in the SMS write screen. This looks promising! The first callback normally points to sms_write_enter, and is called when we enter the SMS write screen. So, in theory, we could overflow that pointer, leave the SMS text editor, re-enter it and then the code execution would jump wherever we want. Nice, let's try that.
Groovy, Baby! Yeah!
Let's say we make a 160-byte long template, with the last four bytes containing the address we want to write into the first callback at 0x1C6D4. Since the message buffer starts at 0x1C600, this means that our combined message+template text should have 216 bytes. Since the template is 160-bytes long, our message should be 56 bytes long. Here's what I did to test whether this attack works:
I created a new template, with 156 'B' characters and 4 'Z' characters. I saved it into memory.
I created a new message, with 56 'A' characters. I then inserted the previously crafted template at the end.
I exited the message editor and re-entered it.
I observed that the UI crashed.
So, we get a crash. If we attach GDB into the qemu stub and break around, we do indeed see a failed jump to 0x5A5A5A5A ('ZZZZ' treated as a pointer). So our smashing works!
Surprisingly, this was the easy part of the exploit. Now onto the hard part, especially if you're new to ARM exploitation....
Weaponization
We need a shellcode. Apparently, all public ARM shellcodes suck, especially if they can't contain 0x00, 0x0A, 0x1A, 0x1B and 0x1C characters. I ended up writing my own, and it's not very pretty:
'shiiii' is the sound I make each time I look at this.
The next step was to automate typing in the shellcode and other long strings into the UI. I wrote a proxy server in Python that would let me connect from a Telnet terminal and also trigger certain automated actions (typing in production token, credentials, template and SMS message). My final exploit looks like this:
Create a new template, with 156 'A' characters and 4 bytes of our shellcode address - 0x1C604. Remember, we can't send zeroes, so I had to add 4 to the message buffer address.
Create a new message with our shellcode, padded from the left with 4 'Z' characters, and from the right with enough 'Z' characters to make the whole thing be 56 bytes long. Now our shellcode is at 0x1C604 in memory.
Insert our template. Now we've overflowed 0x1C64, our shellcode address, into the sms_write_enter callback.
Exit the message screen, and re-enter it. Now we're executing our shellcode, which in turn dooes execve("/bin/sh\0", 0, 0).
An excellent challenge and CTF overflow. Thanks CCCAC and StatumAuhuur for the challenge, and thanks fail0verflow and pasten for the fierce competition!
