woFF

Background

Not so long ago it turned out that Vadium (congratulations!) and me got a “shared” first place in “How Strong Is Your FU Hacking Tournament #1″, so I decided to archive my feelings, findings and the penetration test here.

A few weeks before when I saw the above banner on offensive security’s blog I got excited. Well I’m not a Jackie Chan fan, but I had a feeling that this must be something really good. Couple of minutes later I was registered and started to think about the things I had to do to prepare for the “hacking tournament”. I got a new version of Ubuntu on my computer and googled for security tools nearly every night for a week. I know… BackTrack is great, but I wanted to refresh my memories and look after some new tools.

As it turned out more than 1000 contestants got the mail with the required information to “start the fight”. The rules were simple:

• no denial of service (DoS) attacks
• no disruptive attacks
• no attacks against “non-target machines”

There were three target machines, but to gain access to two of them the contestants had to hack their way through the “n00bfilter”. I really don’t want to repeat my “official” report here, if you are interested in every technical detail you can download the document from here, if you are interested in others reports you can grab them from here. Of course there were no ultimate solutions, but these worked for me.

n00bfilter

As I said to gain the required access to the “internal” network the machine “n00bfilter” had to fall. First step was to enumerate the machine, run a portscan, grab some service banners if necessary. SSH and HTTP were open.
After checking a default login page on the HTTP port I started trying some basic sql injection attacks to bypass the authentication. Some probes resulted in a warning page from the web application firewall (WAF) called “dotDefender” that it blocked my request. I tried some more advanced sql injections, but I always got the error message, so I moved my “cross-hairs” from the login page to the WAF. I checked some information about the software and it turned out, that the installed version is vulnerable to a post authentication remote command execution vulnerability.
The web interface of the software was in the default directory, I got a Basic HTTP auth popup asking for my username and password. Actually the popup provided a valid username (admin) and the password was “manually bruteforced”… well, it was the word “password” (not too hard to find out indeed).

So I got a valid “Authorization” header, used it in a forged packet sent out against the target with Paros.

In fact before I sent the working packets I wanted to take a look on the admin interface of the WAF. It was a mistake… logging in triggered the firewall and I got banned for 5 minutes every time (ideal for some coffe and small-talk with the girlfriend ). But Paros got the result quickly… one search for the proof file (n00bSecret.txt) and one to “cat” its contents. After entering the proof into the tournaments control panel I was very surprised (and of course extremely happy) to see my nick show up first on the scoreboard.

killthen00b

Despite the fact that the attack flow in the above image is very short and easy this machine had some interesting things to explore.

After running an nmap and analyzing the results I decided to go after the installed SurgeMail application. With google I found some exploits against it, but all of them needed a valid SMTP user and password. We were given with an FTP user and password, but a quick check confirmed that that user is not a valid SMTP user. Port 3389 was open, so i started rdesktop and tried to connect to the computer, in a sec a Windows 7 login screen showed up. Just to be sure I checked if the FTP user is able to log in here, the result was good, but not excellent… he is not in the “Remote Desktop Users” group (but this error message means that he is a valid local user and we know his password!).

I grabbed the installed FTP servers banner with netcat and found an excellent directory traversal attack against it on explo.it. Just to be sure I downloaded some config files, SurgeMails administrator (admin.dat) and user (nwauth.dat) database and found the cgi-bin of SurgeMail’s “WebMail”. Running john against the two SSHA hashes provided me one valid SMTP user (n00b with password pippo123). Since I found the cgi-bin directory and had a plan in my mind I didn’t launch SurgeMail related exploits against the server. Why not use metasploit to generate a reverse payload, upload it, run a meterpreter listener and execute the uploaded executable “through” a browser.

Yeah, it was that simple, the proof.txt was in the administrators desktop (and since we got NT AUTHORITY/SYSTEM it wasn’t problem to access it).

ghost

For me this one was the nightmare at the beginning. I just couldn’t find anything to attack. Port 80 was only open, a dummy login page was available and thats it. I tried to silently portscan it, ran nikto, httprint… everything I knew. It looked like an IIS/ASP, but it wasn’t. Some default ASP files were found by nikto for example, but they were 0 byte long. So after deciding this is a linux and the webserver is apache 2.x I was stuck… no exploit, no input field to play with. I left the tournament for 10 hours to be with my friends, to celebrate a birthday and got back to finally find something new, which I should have found 12 hours before. A javascript on the test.asp page (which I just didn’t try manually…). From here it was just a few hours left to gain a root shell. Following the traces of the javascript I found another directory and a vulnerable PHP login script. Started my own webserver, rewrote a PHP shell script (to work correctly) and used the remote file inclusion vulnerability to include it.

Using the PHP shell I uploaded and executed a reverse perl shell connecting to port 4567… just to have a more comfortable environment to hack.

I got www-data, but needed root… local privilege escalation would be ideal, but the kernel was pretty new, so after some check I gave up on the kernel and searched for another clue. I opened upsecurityfocus.com and started to look for vulnerabilities affecting Ubuntu (starting with the newest one). After some hours of searching I found an EXT4 vulnerability, the only problem was that I had to compile the exploit and do “su – root” (which requires TTY shell…). GCC was easily found on the target (/usr/bin/gcc-4.4) and to get around the “su: must be run from terminal” error message I used a simple python script.

Summary and thanks

It was fun, thanks for the challenges and congratulations to the contestants. Buherátoréknak meg külön grat a sebességért!