Solutions: The Hex Factor v2010 (Level B300)

Good day my dearest readers!

Please find below a description of the B300 v2010 solution! If anything is not clear, please don't hesitate to drop a mail to erik.van.buggenhout@thehexfactor.org!

You can find a step-by-step guide below and there is also a full movie clip at the bottom of the page!

Enjoy!

--------------------------------------------------

So... The Royal Bank of Ireland has returned. Apparently, this year they have managed to increase the security posture of their web application... So let's have a look! First of all, we start by pushing all traffic through a web application proxy such as BurpSuite. This allows us to easily intercept and tamper any parameters and pages sent between my browser and the web app server.


When first having a look at the web application it does seem to have been improved: The vulnerabilities identified in 2009 seem to have been fixed and a WAF (or something alike) has been implemented that is denying requests containing XSS or SQL Injection payloads.


However, when further browsing the application, we can see that a PDF has been published under Publications. In this PDF (which does not contain any suspicious payloads :P), we can find some interesting metadata (author = i89054):



Now, let's have a look at what services are running on the WAF:


There seems to be an SSH service running on port 22... This looks interesting, no? Let's try a dictionary attack with the identified user account (i89054). We opted to use Hydra and used the wordlist included in John The Ripper:


We can use this password to access the proxy server with a limited privileges user account. After doing some analysis on the compromised host, we can find the /etc/apache2/httpd.conf file. This configuration file shows us the IP address of the internal web server:


Now let’s abuse our SSH configuration in order to tunnel HTTP traffic through the SSH session, over the reverse proxy to the web application (which is at 192.168.62.136). On Linux, this can be achieved by opening the SSH session as following:

ssh -L 8090:192.168.62.136:80 i89054@192.168.1.105

When we now browse to our local IP address on port 8090, our traffic is being tunnelled through the SSH session over the WAF (thus bypassing the ModSecurity) towards the internal web server port 80. This can be verified by again submitting some XSS payloads in user input parameters:


When we now abuse our found credentials (i89054 – letmein) on the application, we have some more functionalities that become visible. When doing some basic input validation checks on this one, we can easily identify a blind SQL injection vulnerability in the backup functionality:



We now gear up SQLNinja (sorry Windows h4x0rs, there's no SQLNinja release for Linux) in order to exploit the identified SQL Injection vulnerability. The following should be configured in the sqlninja.conf file to perform successful exploitation. Please remember, we're targetting our local machine and port (that are being forwarded through the SSH tunnel.

• host = 127.0.0.1 //Configure your host
  
• port = 8090 //Configure port
• method = GET //Configure HTTP method
• page = /admin/popup.php //Configure vulnerable page
  
• stringstart = id=backup’; //Configure vulnerable parameter

Attention, seeing as we need to have admin privileges to access the page, we need to also input the “Cookie” sessionid in between the --headers_start-- and --headers_end -- lines:

• Cookie: PHPSESSID=7f20q7qkg8pnkfue0c286n2a7

Please note that the cookie value is different for each session (thank god :p), so you’ll have to find out yours on your own. This can be easily achieved by analyzing the traffic in BurpSuite:


Now, let’s test our injection with SQLNinja:



Now we know SQLNinja is up and running, let's try to do some damage... One of the ideas would be to create a user account on the remote machine. This can be done by issuing a "blind OS" command:


So now we have added the user thf with password thf to the remote database server. It would be nice to have a more graphic control interface to pwn the box. Let's try our SSH tunneling trick again, but now let's try forwarding to port 3389 (remote desktop):

ssh -L 3390:192.168.62.136:3389 i89054@192.168.1.105

I'm forwarding my local traffic on 3390 to the database server port 3389. Let's try opening up our Remote Desktop and logging in with our thf-thf set of credentials:


Hmm, this doesn't seem to be working... While it does validate our credentials, we don't seem to have the necessary user rights to log on to the machine. Let's try adding ourselves to the Local Admin group, by abusing our SQL Injection one more time:


When we now try to access through RDP, we can smoothly log on and find what we're looking for: the gimmepoints_b300.exe file :)



Now sit back and relax and stay tuned for the THF 2011 challenges!

Complete movie clip:

Solutions: The Hex Factor v2010 (C200)

You and your team are close to hacking a very complicated CBC encryption algorithm. The missing piece of the puzzle is finding a key which has a special property: a key which only has groups of 2 identical characters. For example, "00 bb 44 22 11 ff dd" is such a key, where "12 42 de ff aa cc 34" is not. You and your team are searching for the "first" secret key with this property, meaning the secret key with the lowest possible number of iterations.

Hint: you can solve this level by only changing 1 byte! Enter your answer using the format mentioned previously, so "00 bb 44 22 11 ff dd" (without the quotes) rather than "00:bb:44:22:11:ff:dd"

As is the case with a lot of reverse engineering challenges, this one is pretty easy to solve once you know what you are looking for.

Run the executable. The output shows a password after going through 15 iterations.

The password is cd b0 de 90 7f 79 8d dd, so not the format we are looking for...

Reverse engineering the password algorithm (used in every iteration) is one option, playing with the number of iterations is another one. The solution to this challenge is the second option (the iterations are using DES encryption).

Load the binary in OllyDbg. We are searching for the loop controlling the number of iterations that are used to calculate the password.

If we search for strings in the binary, we arrive at the following interesting section:

Seems like we arrived right in the loop code! Since we want to play with the total number of iterations, let's scroll down and look for the conditional check. We arrive at the following code section:

Click the image for a larger view

The line at 004013A0 is checking the loop counter against a fixed value 0F (15 in decimal). The for loop starts at 0 (check this in the code!) and goes up to 15, meaning there are 16 iterations in total. This is exactly the number of iterations being used in the original code!

Let's try to increase the number of iterations. Change the instruction at 004013A0 from

CMP DWORD PTR SS:[EBP-34],0F

to

CMP DWORD PTR SS:[EBP-34],10

This adds one extra iteration. Run the modified binary and you will see that an extra iteration is used during the calculation of the password! The resulting password however is not the password we are looking for. To get to the correct password, increase the counter by one and run the application again until a password with the correct format appears.

Since this is a cumbersome thing to do manually, the easiest way to solve this solution is by writing a small script (for example in perl or python) that automatically increments the counter, runs the application and checks if the resulting password has the format we are looking for. However nothing holds you back from doing this manually (although it might take 1 or 100000 steps to get to the solution ... You don't know in advance!).

The solution to the challenge is found when using 46 iterations, resulting in the following password:

ee 88 00 88 77 00 88 00

Challenge solved!

---

Feel free to e-mail questions and suggestions to daan.raman@thehexfactor.og.

Solutions: The Hex Factor v2010 (Level D100)

When you listen to the MP3 file, you're bound to recognize Morse code, even if you can't understand it. Morse code is so universal that everybody recognizes it.

Decoding Morse code is not difficult, but it can be tedious if you have to do it manually. One way is to open the MP3 file in Audacity:



Now you can easily see the dots (short tones) and dashes (longer tones) and decode the message.
The Morse code of this challenge decodes as

"The password is 71401"

Or you can try to decode it with a program, like this one.

Solutions: The Hex Factor v2010 (B200)

For the second challenge in the pwned category we need to attack a workstation on which a user is browsing some random websites.

Before we start the description of the attack there are some things you should know. The target is located at 192.168.1.8 and my machine has the .9 IP in the same range.

The objective is to gain administrative privileges on the target and execute a binary that gives you points for the game.

You can either read the text or view the video posted below. If anything is unclear regarding the provided solution, don't hesitate to either drop an e-mail or to leave a comment on the blog.

---

As we already know the IP address of the target, we start by port scanning the target with NMAP. As we don’t need to be silent or non-intrusive we’ll just throw in everything NMAP has with the –A option (this includes service detection and the Nmap scripting engine for the top 1000 TCP ports as we didn’t specify any specific ports).





We notice that only port 139 appears to be open.

Let’s try and see what kind of traffic is send and received by the machine, using Ettercap (ofcourse we use the 1337 the graphical interface ;)).

By performing an ARP cache poison attack, we intercept all non-local traffic that is send and received by our target by spoofing the local gateway.



It seems like our target is surfing to several websites, using a very old version of Mozilla Firefox (Firefox 1.0.3). After a bit of research this version appears to be vulnerable to a buffer overflow that allows an attacker to execute remote code on the system. Let's fire up Metasploit :-)




With this setup Metasploit wil create a webserver hosting a meterpreter. As soon a client connects to the webserver it tries to exploit the browser using the Mozilla 1.0.3 exploit. So… now we only need to find a way to trick the target into connecting to this website so we can launch the exploit. A simple DNS spoof of Ettercap should do the trick!

In order to properly start the DNS spoofing with Ettercap you need to edit the following file:
/usr/share/ettercap/etter.dns and add the following rule

* A < yourip > < / yourip >;

This will intercept all DNS requests (*) and redirect them to your IP. If you want to be less intrusive you can add a specific website on the * location, e.g.:

www.thehexfactor.org A < yourip > < / yourip >;

If you got it configured correctly, the Ettercap output should look something like this:



When a client now performs a DNS request, he will be redirected to our machine and the exploit will be executed.



Ok that seemed to work quite well. The next step is to escalate to system privileges. Metasploit has some built in functions available for doing this trick. With the getsystem command it tries 4 different methods (including the “new” Kitrap0d method) to gain additional privileges.



Success! We have system privileges on our target, job well done :-)

Thanks for reading this short blog post. Please support the hex factor by twitting or blogging about this awesome project!

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)