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!