Last Saturday, May 8th, I participated in Offensive Security’s How Strong is your FU? hacking tournament. Now I am going to post the results of how I went about hacking the n00b filter.
The first obstacle of actually hacking the n00b filter was actually getting into the game. Many people that signed up for this tournament did not get the emails with their password to enter the tournament until an hour or so later than the competition started. If you had no life and had time to social engineer, instead of waiting you could have joined the #offsec channel on freenode.net and they would have pointed you to the #hsiyf channel for the competitions. There the admins could have manually set you up to enter the tournament. This is actually how I entered the tournament.
When I finally got the instructions on what servers to attack (there were only two and they were identical), I did what most people do: nmap it and see what operating system it is and what services it has running. The results looked like this:
1/tcp open tcpmux?
3/tcp open compressnet?
4/tcp open unknown
6/tcp open tcpwrapped
7/tcp open tcpwrapped
9/tcp open tcpwrapped
13/tcp open tcpwrapped
17/tcp open tcpwrapped
19/tcp open tcpwrapped
20/tcp open tcpwrapped
21/tcp open tcpwrapped
22/tcp open tcpwrapped
23/tcp open tcpwrapped
24/tcp open tcpwrapped
25/tcp open tcpwrapped
26/tcp open tcpwrapped
30/tcp open tcpwrapped
32/tcp open tcpwrapped
33/tcp open tcpwrapped
37/tcp open tcpwrapped
42/tcp open tcpwrapped
43/tcp open tcpwrapped
49/tcp open tcpwrapped
…
Etc. etc. of tcpwrapped ports. When I chopped up this output and grepped for open ports I got:
1/tcp open tcpmux?
3/tcp open compressnet?
4/tcp open unknown
80/tcp open http?
110/tcp open pop3
1723/tcp open pptp?
2701/tcp open sms-rcinfo?
2702/tcp open sms-xfer?
5666/tcp open nrpe?
6788/tcp open unknown
7921/tcp open unknown
7938/tcp open lgtomapper?
8021/tcp open ftp-proxy?
9100/tcp open jetdirect?
9101/tcp open jetdirect?
9102/tcp open jetdirect?
9103/tcp open jetdirect?
They obviously had some kind of tarpit running that was spoofing a whole bunch of fake services, because if I tried to connect to fingerprint any of these with netcat they would not respond and time out.
They also spoofed all the operating system signatures and it looked ugly:
Running (JUST GUESSING) : 3Com embedded (86%), Dell embedded (86%), Samsung embedded (86%), Xerox embedded (86%), Bay Networks embedded (85%)
Aggressive OS guesses: 3Com SuperStack 3 Switch 4300, Dell PowerEdge 2650 remote access controller, Samsung ML-2571N or 6555N printer, or Xerox Phaser 3125N printer (86%), Dell 1815dn printer (86%), Bay Networks BayStack 450 switch (software version 3.1.0.22) (85%), Bay Networks BayStack 450 switch (software version 4.2.0.16) (85%)
No exact OS matches for host (test conditions non-ideal).
Service Info: OS: Windows
The only port that appeared to be open was port 80. When I visited it I arrived at this puzzle:

When I clicked the submit button, I was given this message:

Pretty humorous. When I tried entering in a single quotation to the user field I received the message “HAHAHA!” on a blank white page. There was a few hours where I was wondering around in the dark trying various things like making shell scripts to automatidly fingerprint ports I found on the machine and see if any other ports would respond, using p0f to try to passively fingerprint the operating system to see if I could find a vulnerability, trying XSS injects, and manually fuzzing the variables of the web application to see if I could make it overflow. P0f actually said the OS was Tru64. Apache error messages said the OS was fedora (which I think it was most likely a fedora box). After hitting a bunch of dead ends, I decided to revisit the “HAHAHA!” message and check the source code. I noticed an advertisement in the source for applicure. Turns out applicure makes a product called dotDefender, which was running on the server we had to attack and preventing the SQL injection. I spent a while over-thinking how to hack dotDefender and even debated downloading it, setting it up in a virtual machine, and fuzzing it for buffer overflows. Then a google search revealed the missing piece to the puzzle: the dotDefender exploit.
With this exploit I tried to log into the /dotDefender/index.cgi script. It was on a password protected .htaccess directory so I tried looking through the manuals on applicure’s website and it said the password was the same as the username. The .htaccess script told me the username was admin, so I assumed the password was admin. For a long time there was a lot of confusion because there was talk in the #hsiyf channel that people kept changing the passwords on the .htaccess file somehow. I knew we weren’t supposed to run automated tools, but I had heard of people using hydra, so I just hurled a dictionary attack at the dotDefender password prompt. In social engineering with some of the other contestants who were fed up with the lag problems with the dotDefender application, someone told me the login was admin/password . When I tried to log into the application it would lag like hell. I waited literally 10 minutes for a response from the http server, and at the same time the admins were reverting to snapshots on their VMs constantly. One time I did actually make it through and I was very close to getting to the n00bSecret.txt file that was needed to move on to phase 2. Here is a screen shot of me using the dotDefender exploit:

I was so close to getting to phase 2. All I had to do was sucessfully execute a few commands like find / -name n00bSecret.txt . But every single time I actually got onto the application I received a message like this:

Someone later told me (that went through the pain of waiting for 10 minutes for each http response) that they successfully managed to find n00bSecret.txt in /opt/<some random directory string>/n00bSecret.txt . With that they printed it out to the webapp using “cat /opt/<some random directory string>/n00bSecret.txt” as I suggested to them. I decided not to continue the tournament anymore because of the lag.
I talked with the admin known as muts about the lag on the dotDefender application. He claims (in a private message) that there was an Intrusion Prevention System (IPS), and that I was tripping it (which was causing my lag issues). No other person I talked to that entered phase 2 found a way to not trip this IPS (if there even was one that people were tripping in this way). They all seemed to use burpsuite to modify the post data for the dotDefender exploit I posted earlier in this blog entry. Afterall, it couldn’t possibly be that 100′s of people trying to log on to a remote management application (that wasn’t intended to be used by multiple users) and executing shell commands on the box could cause the lag I was experiencing right (*sarcasm*)? We will see what Offensive Security has to say if they ever post the solutions to their vulnerabilites like they said they would:
Dialogue from #hsiyf (May 8th):
07:32 < Abo3abd> @muts, can you please share ths solutions after end the tournament?
07:32 <@ryujin> we will Abo3abd
07:33 < Abo3abd> Thanks a lot
Critique:
I’d like to thank the folks at Offensive Security for hosting this tournament. It was a lot of fun. They did a great job at designing a neat little game for us all to play. The two biggest suggestions that I have been hearing for next time though are (1) please let us start at the same time instead of relying on SMTP to email people their passwords and (2) don’t use vulnerable software that is too laggy for people to exploit.