This is the first of 3 official result posts we will be writing for the HSIYF tournament.
Introduction
A couple of weeks ago, we decided to create a unique Hacking Tournament under the name “How Strong is your Fu” (HSIYF). We decided to use new vulnerable images we created for our PWB online course labs, and have the hacking community play with them. After a quick brainstorming session, we took a week to (re)discover our dark side and created the HSIYF challenge machines, noob-filter, ghost and killthen00b. This document will provide an overview of the challenge and describe possible attack vectors for each of the challenges presented.
Pre-challenge Preparations
Registration to the challenge was opened a couple of weeks before the challenge and the amount of sign-ups was overwhelming – way more than we expected. We didn’t want to disappoint the masses, and decided to design our challenges in a way that everyone would be able to participate – and so was born – “noob-filter.com”. The main concept behind the “noob filter” machine was to thin out all the registrations – only people whom could hack this challenge machine would be admitted into our VPN labs. Obviously, we immediately saw the flaw in this design – having over 1000 hackers run their favorite vulnerability scanner on this machine would spell doom to the initial challenge. We decided to deal with this in a nasty way – we installed a sensitive IPS, which would be triggered by such scanners. The IPS was configured for a 5-minute ban on the offending IP. This phase of the challenge was dubbed “Phase 1”.
HSIYF Event Overview
As the event started, we quickly realized we hadn’t taken into account several details:
- Sending over 1000 emails using a Google Premium account:
Our initial mail blast took over 3 hours to send – many people got their mails late. We attempted to help those who contacted us by providing them the information via IRC.
- Expecting 1000 hackers to read the instructions from beginning to end:
In hindsight – an unrealistic expectation. Some participants were not native English speakers, while others simply didn’t RTFM.
- Expecting 1000 hackers to abide by our rules:
Our “please do not damage the challenge machines” plea fell on deaf ears. We believe there was a general sense of “lack of accountability” – meaning that many participants did not care about leaving challenge machines in tact for others to enjoy.
- Ignoring Mother’s day:
Some participants’ efforts were hampered by “Mothers day”…
Thankfully, each of these oversights was managed in real time, with minimal impact to the tournament. No mothers were harmed during this tournament.
Main difficulties encountered by contestants
The most overwhelming initial difficulty encountered by participants was the n00b filter IPS. The IPS threw almost everyone off, bringing up claims that “the servers were down” or that “the servers were real slow”. Neither of these observations was true. Eventually, people caught on, and started being more careful with traffic sent to the n00b filter machines. Generally speaking, we noticed a “sheep herd effect”, where a single wrong observation was reported in the IRC channel, and then repeated by others continuously, misleading the main mass of the contenders.
Challenge Solutions
The part you’ve all been waiting for – solutions to our challenge boxes.
Noob filter
Our noob filter box was running Fedora 12, fully patched. Although the index page contained a login form, the machine itself was not running MySQL or PHP. The server was also running a vulnerable version of DotDefender – a WAF which contained an unpatched remote command execution vulnerability, described here: http://www.exploit-db.com/exploits/10261
The described vulnerability is a POST authentication vulnerability, leading many to believe they needed to administrative password in order to exploit it. Our configured password was “password”, which we expected to be cracked and changed relatively quickly. In accordance to our expectations, this happened very fast, leaving other contestants “stranded”, complaining that “the password was changed” and therefore the vulnerability was “unavailable for them to exploit”.
A quick examination of the DotDefender software (in a local lab…. did anyone download the software locally and try it out? Tsk Tsk …) should have revealed a 0day XSS vulnerability in the “Host Header” field of the HTTP request, allowing to create a “one two punch combination” resulting in unauthenticated remote command execution. Check out sample code here. We will post part 2 and three in the next few days.
Waiting Video Too From The Begin How He Hack This Machine :D
I posted my versions of the solutions on my blog for anyone that wants to check them out. Can’t thank offsec enough for this great challenge and congrats to everyone that played along at home.
I have a few questions about the n00b filter. I also wrote in detail about my experiences in trying to hack the n00b filter in my blog. You can read about my difficulties with the dotDefender application to get a better idea of what I’m talking about if you would like.
You say:
“The most overwhelming initial difficulty encountered by participants was the n00b filter IPS. The IPS threw almost everyone off, bringing up claims that “the servers were down” or that “the servers were real slow”. Neither of these observations was true. Eventually, people caught on, and started being more careful with traffic sent to the n00b filter machines.”
1. Was it your intention for you IPS to prevent users from logging into the remote Site Management dotDefender application to use the exploit (http://www.exploit-db.com/exploits/10261) ?
2. Once users actually logged onto the Site Management for dotDefender are you claiming that it was supposed to trip the IPS if they used tools like burpsuite to craft the POST request to send to your server?
3. If so was there a way to use this exploit and not trip the IPS and what was that method?
4. Otherwise are you claiming the only way to avoid your IPS was to use the 0day or deal with the pain of the slowness from going down the route of the exploit found on exploitdb?
I believe this is the alleged lag issue everyone was experiencing that I wrote about in my blog. I would really appreciate it if you could answer these questions and clarify for us what the intentions of your IPS were. I know several people told me they went down the pain route and fought using the exploit on exploitdb. I am wondering if everyone experienced this same delay.
Thank you!
Dantevios
I think the problem was actually with the dotDefender application itself and the “server” per se. Once it became common knowledge that this particular exploit existed it seems as though the WAF became overwhelmed with attempts.
It took me almost 2.5 hours to finally get my commands to run even though I had the solution in hand the entire time. Between the IPS, congestion and lamers changing the password. Still, hats off to the crew for a great event, we appreciate the hard work.
@Dantevios some answers to your questions:
1) POST requests to admin.cgi were blocked by the IDS.
2) Why were people compelled to log into the WAF admin interface? Again, not required for the exploit.
3) Yes, using a POST request to index.cgi, or using the XSS + auth reflection described in our solution.
4) Answered by 1) 2) and 3).
Thank you!
[...] 05/12/10: The Offsec guys have just posted a response to some of the issues I raised here on their blog. The password was apparently not necessary, as [...]
1) POST requests to admin.cgi were blocked by the IDS. <– funny i did my code injects via just manupulating the POST-requests via tamper-data ^^ well okay it took a while but it worked. :D *now i know why it was so slow, thx!*
*sorry for the doublepost* but if somebody wants to download the dotdefender-waf he should not go for the vendors homepage since you get only a v4-trial there but you can find a copy of the vuln software as an rpm e.g. there -> http://www.download3k.com/Install-dotDefender-Monitor.html
I would have to agree with dr_ide. At one point, I got the n00bSecret.txt contents and submitted it within 30 seconds but the system told me it was invalid. I simply had to rerun my requests but just rerunning the requests took about 2 hours because of the slowness being experienced.
I do find it interesting that you think using the XSS was the best option for executing the deletesite function. Personally, I found the easiest way was just guessing passwords to get access to the interface.
But then… I’m lazy. :-)
@5M7X – yeps…their site updated a couple of days after the tournament…