HTTP Form Password Brute Forcing – The Need for Speed
HTTP Form password brute forcing is not rocket science, you try multiple username/password combinations until you get a correct answer (or non-negative answer).
Password brute forcing, especially over a network, takes time and while your software is attempting to find a correct username/password combination it is taking up your and the remote system’s resources. While the brute force is being carried out you might not want to run an automated scan, for example, as the remote server may not be able to cope with the amount of connections or the rapid succession of connections. At the same time, your network bandwidth and system memory are also limited. It makes sense that when you conduct a weak password brute force it is done as fast as possible so that your time and resources are restored for other tasks.
And of course not forgetting that you’re always going to be limited by time on a pentest/web app assessment as the client’s budget is never unlimited.
So what is the fastest way to brute force a HTTP form today? I use Burp Suite for my Web Application Security Assessments and I would normally use Burp’s Intruder, but is this the fastest tool to do it with?
Of course, there are other limiting factors when brute forcing remotely such as your Internet/Network speed, CPU speed, RAM and the remote system’s response times, as well as other factors. For this experiment we’ll only be focusing on the software used to carry out the password brute force attack. This is far from being a perfect in-depth study but it should hopefully give an idea which tool out of my small collection (Burp Intruder Spider Vs Hydra http-post-form) is fastest.
The Setup
On both tools I set one user to brute force, admin, and used the rockyou-75.txt wordlist (19963 lines), which has one addition which is the correct password which was added to the last line of the file. Both the same username and password list was used for Burp’s Intruder (Sniper) and Hydra. Each tool was run one after the other, not at the same time.
Burp Suite Professional Intruder (Sniper) Version: 1.5.11
Hydra (http-post-form) Version: 7.4.2
A “Local” test was carried out on a localhost Apache 2 web server as well as a “Remote” test against the www.ethicalhack3r.co.uk Nginx web server.
The Test Form that I created to test against (both locally and remotely) does not make a database call which is what would normally be expected on a real HTTP login form. I’d expect my test login form to reply quicker than if it had to make a database call. The ‘Local’ and ‘Remote’ columns represent the time it took the tool to find the correct password which was at the end of the wordlist.
SSH “accept : too many open files” on OS X when using Burp
EDIT 19.04.2013 10:17 —
WARNING! This did break the Tor Browser Bundle on my machine. The error was “Couldn’t set maximum number of file descriptors: Invalid argument”
—
For as long as I can remember, when using SSH as a forward proxy to proxy Burp Suite through an upstream server I have gotten a “accept : too many open files” error in my Mac OS X Terminal after a couple of hours of using Burp’s Proxy and/or Scanner.
When searching Google the first solution I came across was to set the ‘ulimit’ to something higher, as far as I can tell ‘ulimit’ sets user system limits such as how many open files a user is allowed to have open at once.
On OS X when attempting to set this limit to ‘unlimited’ I always got an error, “Neither the hard nor soft limit for “maxfiles” can be unlimited. Please use a numeric parameter for both.”, or when setting the ulimit to something higher than the default (256) the error (accept : too many open files) would still not go away or at least not for long. The only thing I found that would get rid of the error was to kill my ssh session and spawn a new one.
After further reading, some forums and blogs suggested updating openssh, I did this and the issue persisted. I thought the issue may have been openssl, so I updated that, the issue persisted.
I also tweeted about the issue where the suggestion of adjusting the ulimit resurfaced, but I just couldn’t get ulimit to fix the issue.
[Weekly Viewing] You and Your Research & Ruby 2.0
This week we have another two videos lined up for you. The first, by Haroon Meer, I was luckily enough to see in person at Brucon 2011. It is one of the best talks I have ever had the privilege to see, by anyone. If you’re ever going to watch one of these ‘Weekly Viewing’ videos of mine make it be this one.
The second video is by Matz, the creator of Ruby, where he talks about Ruby’s development and the new features of Ruby 2.0. In his talk Matz says that Ruby 1.8 will die soon. So update already! ;)
#HITB2012KUL D1T2 – Haroon Meer – You and Your Research
[Weekly Viewing] Web App Security and Zero Days
This is a first of hopefully many weekly posts in which I will share online security related videos that I’ve watched during the week and think are worth sharing. This week I’ve got two great videos lined up for your viewing pleasure.
[OWASP AppSec USA 2012] Effective Approaches to Web Application Security – Zane Lackey
In this video Zane Lackey from Etsy talks about how to make a developer’s job easier by making things safe by default, how to detect risky functionality and how to automate aspects of web application security monitoring and response.
Effective Approaches to Web Application Security – Zane Lackey from OWASP AppSec USA on Vimeo.
Sony Freedom Of Information (FOI) Request
On the 14th of January the UK Information Commissioner’s Office (ICO) sent Sony Computer Entertainment Europe Limited a monetary penalty notice of £250,000 following ‘a serious breach of the Data Protection Act’.
To be able to quantify how much the ICO was fining Sony for individual user’s data the exact number of UK PSN users would need to be known. A couple of sources put this number at 3 million but I’m not sure where the original 3 million figure came from nor how accurate it really is [0][1].
If we were to take this 3 million figure at face value, the ICO fined Sony (£250,000 / 3,000,000) £0.000083 per user’s data. According to the ICO, £250,000 is ‘reasonable and proportionate’ in this case. To get a more accurate figure I sent the ICO a FOI request to ask for the redacted figure in the monetary penalty notice document which simply states “The Network Platform was used by an estimated REDACTED million customers in Europe, the Middle East, Africa, Australia and New Zealand with REDACTED million of those customers based in the UK.”.