Solutions: The Hex Factor v2009 (Level D300)

Category D, time to think outside the box again. The question was straightforward :
"What is the hidden number in this file?"

The file accompanying the question was a little bit more complicated, which could be expected, given it was a level 300 challenge. Knowing that Didier Stevens, yes the evil PDF doctor, was on the THF team should have given you a strong hunch to the solution. Let's see what we got.
At first sight, this looked like an ordinary pdf, containing a message and a barcode :
What? Didier wants us to go to the nearest supermarket to get the solution ? For sure he doesn't, he's much crueler than that :-D

Using a tool like bcTester, we are able to retrieve what the barcode represents :

Uyy uspsvn ecqf zm c bhnsyt: tvwv ykuuu fhg tbvi tgfb uylgs

Allrightie ... what does this mean? It's obviously cyphertext, but what cypher did we use? And more importantly ... what was the key ?
Some of the contestants went at it and tried to find the cypher and the key themselves. They lost a lot of time :-) Looking at the PDF file you could see that there was more there than you would initially see in a regular PDF reader. Didier created a PDF file with incremental updates and as such, there was another barcode hidden in the file. This barcode revealed the golden nugget you were looking for :
Encryption Vigenere Key BRUCON

And thus you could decrypt the cyphertext, to finally find the solution:

The secreT cOde iS a NUmber: five eight ONe fOuR ZerO thRee

Thank you to all who competed in 2009. The rankings for BruCON in 2009 are here and for SANS in London are here.

We look forward to serving you a new load of exciting, mindboggling, sometimes devious, sometimes plain wicked challenges at Brucon in 2010!

Solutions: The Hex Factor v2009 (Level C300)

The binary foo level 300 reverse engineering challenge was designed to be difficult to solve, but not too hard. Designing challenges nobody can solve isn't hard, the difficult part is finding the right balance so that people can still solve the challenge in the allotted time.

The challenge is completely written in assembler, and no libraries were used. This gives me full control over every byte emitted by the assembler and linker to produce the executable. But it also implies that I had to write my own I/O routines, instead of using printf and scanf.

When you open re-300.exe with IDA Pro, you'll get this warning:



This is a good indication that the executable is packed. The name UPX1 of the code segment is another good indication:



Trying to decompress re-300.exe with UPX succeeds:

copy re-300.exe re-300-unpacked.exe
upx -d re-300-unpacked.exe

So you might be tempted to believe that the executable was just packed to obfuscate the code, and that you can solve the challenge by analyzing the unpacked executable. This is not completely true. Take a look at the UPX decompression stub of re-300.exe:



This stub is slightly different from the standard decompression stub used by UPX. I inserted the instruction dec ecx as a first anti-reversing trick.
When a normal executable is launched, register ECX has value 0x00000000 when the entry-point of the executable is called. When a UPX packed executable is launched, register ECX also has value 0x00000000. But in our challenge executable, the stub decreases the value ECX with 1 just before jumping to the entry-point. So ECX has value 0xFFFFFFFF when the packed challenge passes execution to the entry-point. If you unpack the challenge executable and run it, ECX will have value 0x00000000. Needless to say, I use this value ECX later on in the challenge, and if it's not equal to 0xFFFFFFFF, you'll never find the right answer.

So you can continue your analysis of re-300-unpacked.exe (the unpacked challenge), but remember to initialize ECX to 0xFFFFFFFF when you perform dynamic analysis (like debugging).

When you analyze the unpacked challenge, you'll notice that it uses Dave Aitel's shellcode method to locate 4 win32 API functions (GetStdHandle, WriteConsoleA, lstrlenA and ReadConsoleA), mainly used to read from and write to the console.

But here also, I've added an anti-reversing trick:



The value pointed to by [eax+2] in the PEB is equal to 0x00000001 when you execute the challenge under the control of a debugger, and it is equal to 0x00000000 when it runs without debugger (this value is set by Windows when a process is created/debugged). So when you run this code under the control of a debugger, the win32 API locating code will fail.

When you analyze the input and output routines, you'll discover they are designed to write text and input and output 8-digit uppercase hex values, like this: 89ABCDEF.

Further analysis shows that the password and the code (the answer) are not hardcoded, but that they are calculated. This is done to prevent you from just changing the logic of the challenge so that any password would be OK. If you do this, you'll get a congratulatory message, but the provided code will be wrong.

Here is the code that calculates the password and the code:



Calculating the password is done by XOR-ing and left-shifting the program code, a rather simple exercise. The calculated password is in ECX, the password you provided is in EAX, and both registers are compared to decide if you provided the correct password. So you might be tempted to debug this program, and set a software breakpoint just before the passwords are compared. But this will not give you the right answer, because of a third anti-reversing trick I implemented. When you set a software breakpoint on a given instruction, the debugger will actually replace this instruction in memory with an INT3 instruction (opcode 0xCC). This means that setting a software breakpoint actually changes the program code, and because I calculate the password by XOR-ing and left-shifting the complete program code, the calculated password will not be the correct one!

How do you solve this?

There are several solutions. You could decide to write a program that calculates the correct password (for example by translating my assembly code to Python). Or you could use hardware breakpoints (these don't modify the program code).

I'm going to show you another solution using a debugger (ODBG).

Open re-300-unpacked.exe in the debugger:



Before you start the program, notice the value of ECX:



Remember that this value should be 0xFFFFFFFF, so change the ECX register:



And don't forget the second anti-reversing trick, so set a breakpoint here:



Now start the program. When the debugger stops at your first breakpoint, modify register ECX to replace 0x00000001 with 0x00000000.



Remove the breakpoint (otherwise the password calculation routine will provide the wrong password), and set a new breakpoint just before we enter the password calculation routine:



Continue running the program, and provide a password (any password will do for now, as long as it's a valid 8-digit hex number):



When the debugger breaks at the second breakpoint, remove this too, and then single step through the password calculation routine until you hit the SUB instruction. Remember, you can't set a breakpoint on the SUB instruction, because then the password calculation would give a wrong result. But single stepping doesn't change the code.



Now, register ECX contains the calculated password: 1FF29D9B (and register EAX contains the password you provided).



You've found the correct password, now you need to find the correct code.
You could change register EAX with the correct password, and then continue to debug the program until the code is calculated. But there are 2 more anti-reversing tricks you'll need to defeat. One trick calculates the execution time of the routine (by subtracting 2 timestamps provided by instruction RDTSC), and another trick calculates an XOR value of the program code. Both tricks are blended together so you can't use breakpoints or single step (single stepping would make the timestamp delta too long).

How do you solve this? Take a step back. You've the correct password, but you don't have the correct code. Just use the original challenge (re-300.exe), run it with the correct password, and it will give you the correct code! You don't have to debug anymore, you already have the correct password:



Enjoying the masochistic assembly tricks of Didier? Get your tickets now for BruCON (September, Brussels) or at SANS London (December, London)

Solutions: The Hex Factor v2009 (Level D200)

It's always a treat when you give hackers a box. It only takes a few moments before they break it down and create a completely new box. You guessed it, D-200 was another of our '09 out of the box challenges. Here we go.

ootb-200.exe looked like yet another binary, but was it ? Your first instinct might have been to reverse engineer it, but you would've wasted your time with that. It told so itself :Ok, no need for debuggers. There must be other ways to find the key to the kingdom ... Did I say key ?

I did. The binary is digitally signed. Let's look into the details then :

And there we have it. Hiding in plain sight. Those familiar with basic math recognize a fibonnaci sequence when they see it. The answer is right there : 55

Do you dare to take on The Hex Factor in 2010? Get your tickets now for BruCON (September, Brussels) or at SANS London (December, London)

Solutions: The Hex Factor v2009 (Level C200)

This is a straight-forward reverse engineering challenge. When analyzing the executable, we notice no packing was used by the coders. A simple tool like OllyDbg can tell this. This means we can jump right into the code without having to deal with exotic unpacking – good news!

First things first: we launch the executable and immediately notice a prompt, asking for a password. The username is fixed at “bruCon” – this is already a huge help, since we can use this string to look for clues in the ASM code later on.

Enter a random password: we get the following error message:

We get another useful clue when looking at the failed login screen: the message “Oops, incorrect password.” This is the second clue we get, and a second string we write down for later analysis in OllyDbg.

Next,we have a look at the literal text strings used in the executable from within OllyDbg:

The two strings we remembered from running the exe are already mentioned as the first entries in the string table! (username “bruCon” and error message “Oops, incorrect password”).

Let’s trace jumps to the error message. We arrive at the following location in the assembly trace:

Our string is mentioned at address 0x00401186. Why are we so interested in this error message? Well, whenever this error message is pushed on the stack from within the code, we can assume that somewhere close the keying algorithm is implemented (this is not always the case, but in this challenge, it is). So let’s have a look at what is happening in the assembly code just above this interesting error string.

Just above the call at 0x0040118B, we notice a short loop: since this is a fairly short executable, this loop could possibly be used by the keying algorithm to calculate the password – let’s have a closer look.

We set a breakpoint at 0x00401162, the entry point for the loop. Stepping through the code, we notice that each iteration is processing a different character of our username “bruCon” – a simple counter is incremented each iteration with the ASCII values for each individual character of the username, and this results in a total of 617 (decimal) – when stepping through the code, you will notice the register contains value 269, but this is of course the hexadecimal equivalent of 617.

After processing all characters and summing the ASCII values, we exit the loop at address 0x00401174. Next, the value of EDI (which contains 617 now) is multiplied by 61 – again, remember that OllyDbg is showing us hexadecimal numbers here!

The multiplication seems to be the last arithmetic operation used to calculate the password, so let’s give it a try. Our final result is 0x269 * 0x61 = 0xE9C9. Convert this to decimal, and we get 59849.

Launch the executable, let’s give this a try: bingo! We get a “Password correct!” message.

Do you dare to take on The Hex Factor in 2010? Get your tickets now for BruCON (September, Brussels) or at SANS London (December, London)

Solutions: The Hex Factor v2009 (Level B200)

This challenge is the first of two hacking challenges. In order to solve this exercise the attacker should have sufficient technical knowledge and a mindset that can think out of the box.

Before I can start the actual attack description it is important to know that the vulnerable machine, is hosted at 192.168.1.14 and the attacker’s computer hosted in the same subnet at 192.168.1.16.

I started this attack by performing some basic discovert on the system. I used the best portscanning++ tool every (nmap) to find the open ports:



Based on the information resulting from the nmap output I explored the HTTP part of the vulnerable machine, here I discovered a user exists with username “Hydra”. Next I tried to SSH towards the vulnerable host with the newly acquired username, this resulted in an authentication error because no password was provided. But with some simple brute forcing with SSHBrute, using a pre-defined wordlist available on BackTrack I found the correct password within minutes (of course, we made the password guessing SO easy because it is no fun to do a challenge when you have to wait three days to get your bruteforcing results ...)



Using the username Hydra and password abc123 I obtained access to the B200 system. However this user only has limited rights and cannot execute the binary that gave the maximum amount of points. As a consequence some extra exploring on the system itself had to be performed. After closely examining multiple files I found a bash history file that contained a username and password to authenticate with crashoverride to the system.


When authenticated with this user, I found a backed up shadow file in the users’ home directory. This backed up shadow file was accessible, I copied it back to my BackTrack and used John The Ripper to crack all the hashes available in it within seconds.



The root password found, did unfortunately not work. The acidburn password did work giving me access to the B200 machine with the user needed to score the maximum amount of points. The video below provides you with a recorded demo of the B200 hacking challenge.




Show us your fu at BruCON (September, Brussels) or at SANS London (December, London)

Solutions: The Hex Factor v2009 (Level A200)

Once again most of the answers can be found using Google (or other online search engines), however of the questions are more challenging and require more background knowledge of the hacker universum and as a consequence more searching on the world wide web.


Question: What is the message that is hidden in the ICMP packet located somewhere on the main page of “The Hex Factor” website?

The ICMP packet is located on the background of The Hex Factors logo, this ICMP packet should be decoded to get the answer below. You can identify the IP packet because the hex string starts "45 00", which means IP version 4 and 5 is the IP Header Length in Octets. If you further decode the packet using IP header specifications, you will see it is an ICMP packet with a message as payload.
Answer: My fu is too l33t for you

Question: Who is this?

Answer: Robert (Tappan) Morris

Question: What device is this?

Answer: Enigma machine

Question: What is the title of this book?

By using www.tineye.com you can search for similar pictures on the Internet. See there results here. Somebody during BruCON showed me this site, thanks for that! (sorry, no clue anymore who you were)
Answer: Secrets & Lies

Question: What can be considered the most famous novel in "the early years"? It has won the Nebula Award, an award given each year by the Science Fiction and Fantasy Writers of America. Hint: 2+2=5
Answer: Neuromancer

Question: In what country can you find the company that makes one of the best (if not the best) decompilers?
IDA Pro would be one of the better decompilers. It is created by Hex-Rays, a company based in Liege (Belgium). No, we are not sponsored by them (unfortunately though)
Answer: Belgium

Question: If you get on the ‘Rossiya’ at its most western starting point and get off after 3035 km. In what town are you then?
By combining information found on the homepage of Rossiva and information found on google maps (or any other atlas application) the town can be calculated where the Rossiya is at 3035 km.
Answer: Barabinsk

Question: What is the number (2 digits after comma) of Microsoft shares you could have bought when you sold 1 share of Google at NASDAQ closure at June, 3 2009?
Answer: 19, 86

More of that? Get your tickets now for BruCON (September, Brussels) or at SANS London (December, London)

Solutions: The Hex Factor v2009 (Level D100)

With permission of the author, Tomasz Miklas -- we shamelessly copy/pasted his original blogpost here below with the solution for the first Out of the Box challenge

---

My favorite category was Out Of The Box category (also known as Pure Leetness), where questions were really 'out of the box' and solving them was the best fun I had for a long time! First 100 points for finding a number 'hidden' in the message was really simple and here's how I did it:

Solutions: The Hex Factor v2009 (Level C100)

C-100 was the first of our reverse engineering challenges and since the main goal of THF09 was to provide everybody a challenge and a taste of what pwnage, reverse engineering, etc. really was, it was kept really simple.

the challenge consisted of a binary (re-100.exe) which was "password protected". If the correct password was entered, a code would be returned that you could use to claim your points on the THF scoreboard.
There were multiple ways to find out what the password was, including the well-known rubber hose technique, but the latter would've get you kicked out of the contest. By far the easiest one was running strings against the binary. The result would look a little something like this :

Aahh, the sweet sense of victory... Now get your behind out of that easy chair and come join us at BruCON (September, Brussels) or SANS London (December, London)

Solutions: The Hex Factor v2009 (Level B100)

Aaah, the agonizing USB device created by Didier...

As a reminder: the device consisted of a LCD display and 3 sensors. These sensors needed to be activated in a specific sequence in order to input a PIN code. When the correct PIN (correct sequence) was used, the device displayed a secret code.

We saw people yell at it, heat it and even rub it in vain. Today we give you the correct activation method for the sensors, as well as the correct order in which to use them.

Sensor 1: Activated by touching it
Sensor 2: Activated by lighting it
Sensor 3: Activated by using a magnet

The correct activation order to display the secret code was: 1 - 2 - 3 - 2 - 1. The secret code displayed was "KRIEK" also known as the Belgian Beer for Pussies

Video:


Do you dare to take on The Hex Factor in 2010? Get your tickets now for BruCON (September, Brussels) or at SANS London (December, London)

Solutions: The Hex Factor v2009 (Level A100)

As we are in the progress of designing and implementing the 2010 version of The Hex Factor, I guess it is time to save people from their agony and publish the solutions for the different levels on the 2009 version which was run on BruCON (Sep 09) and SANS London (Dec 09). As a reminder, these were the categories and levels:

• Once upon a time - History and Culture around hacking with levels A100, A200
• Pwned - Breaking into systems and applications with levels B100, B200, B300
• Binary Fu -Reverse engineering with levels C100, C200, C300
• Out of the Box - Crazy and rand() stuff with levels D100, D200, D300

From now on we will try to post the solutions every few weeks up to the point where v2010 is being released. First off all, here are the solutions for "Once upon a time - History and Culture around hacking A100"

Most of these questions can be found by using online search engines, whenever extra steps are required to solve a given question these are explained below the applicable question.

Question: What is the nickname of security guru RGFtZW9uIEQuIFdlbGNoLUFiZXJuYXRoeQ==?
In order to solve this question a BASE64 decoder should be used to decode the security guru's name. When doing this the following name is decoded: Dameon D. Welch-Abernathy, this name can then be googled resulting in the below answer.
Answer: Phoneboy

Question: What is the name of this device, invented by Mr. Draper?

Answer: Blue Box

Question: In which movie was this hack performed?
Simply by googling "nmap in movies" the answer to the question is provided.

Answer: The Matrix Reloaded

Question: Who hacked a famous media company from a copy center, using an 8-year old computer and a keyboard with 6 keys missing? He’s also known as “the hacker without a home”?
Answer: Adrian Lamo

Question: In what movie plays character ‘David’ Tic-Tac-Toe with a computer?
Answer: Wargames

Question: Decode the following:

Answer: Hackerspace

Question: What is the number of the payphone, located in the lobby of the New York Times building in Manhattan?
There is a website that is holds all the payphone numbers on this site you can search for the payphone of the New York Times building. http://www.payphone-project.com/
Answer: (212) 221-9508

Question: What’s the name of the candyshop, located at “Digue Gaston Berthe”?
This can be found using google maps streetmap and "walking" the street Digue Gaston Berthe.
Answer: Au Festival des Saveurs

Do you dare to take on The Hex Factor in 2010? Get your tickets now for BruCON (September, Brussels) or at SANS London (December, London)

Windows NT User Mode to Ring 0 Escalation Vulnerability

On the 19th of January 2010, a 0 day vulnerability was made public on Full Disclosure that could lead to privilege escalation on every version of Windows (from NT until 7). Both the source code and compiled executable are available on Exploit DB.



1. Get the exploit code from here
2. Extract the vdmexploit.dll and vdmallowed.exe files (or compile with Visual C++ if you do not want to run executables without reading the code)
3. Move the .dll and .exe to your target machine (through SMB, FTP or TFTP depending on the capabilities you have on your target machine)
4. Run vdmallowed.exe

On the 25th of January 2010, HD Moore added a script to the Metasploit 3.3.4-DEV to automatically exploit and execute the KiTrap0d. We noted some issues with the script, and a few hours later, an update was made on the KiTrap0d kit in Metasploit. Thanks HD Moore!

Our own blog!

In our busy lives, between setting up challenges for THF, drinking Belgian beers and doing security work as professionals, we decided to setup a small blog for random rants on topics.

Do not expect this to be a daily updated blog, or totally useless re-tweeting, re-posting, malware serving site. If we feel like something is worth publishing, we'll just do it ;-)

Anyways, in the next months, we will disclose the solutions of our The Hex Factor challenges one-by-one.