Feasibility of brute forcing a remote login

Previously we brute-force mined the admin password using a blind sqli, to get the result adminpass.

But Mutillidae's login mechanism doesn't have a lockout either, and the password was weak, so maybe we could have successfully brute forced this password from a wordlist, without even having a sqli.

However, even something as simple as adminpass may take a very long time to come across, and depend on the wordlist used.  On Kali, out of well  over 100 wordlists, only 4 have it.

$ find -L /usr/share/wordlists -type f | wc -l
169

$ find -L /usr/share/wordlists -type f -exec grep -H ^adminpass$ {} \;
Binary file /usr/share/wordlists/sqlmap.txt matches
/usr/share/wordlists/metasploit/ipmi_passwords.txt:adminpass
/usr/share/wordlists/metasploit/default_pass_for_services_unhash.txt:adminpass
/usr/share/wordlists/metasploit/common_roots.txt:adminpass

Collapsing all the .txt wordlists down into a single list reveals there are about 2 million entries:

$ find -L /usr/share/wordlists "*.txt" -type f -exec cat {} \; | wc -l
2632913

$ find -L /usr/share/wordlists "*.txt" -type f -exec cat {} \; | sort | uniq | wc -l
1942391

If we gave the server 100 logins/sec (across many threads), that would take about 5.5 hours to exhaust that list for one account, which might be worthwhile for an attacker in terms of a quick hit and run.  That is feasible.

But trying all combinations of characters is definitely less attractive over a network at a mere 100s of requests/second.  Even a 5 character password of all lower case letters would be 11 million guesses...

This might still suit some attackers, I'm guessing.  Maybe they could afford to drip-feed guesses in over days, weeks, or even months for the payoff.  Or maybe the organization being targeted is so big and fielding so much traffic that 100s or 1000s of extra logins/sec aren't going to negatively impact anything, and monitoring/alerting may not even pick it up (or if so, maybe not immediately).

Rational guidelines that I can think of for an attacker might be:

1. Exact account needed = massive wordlist
2. Volume/any-account-will-do: top N passwords by frequency fitting userbase profile
3. Short of time or webscale company where traffic will be lost, stealth not needed: hit as hard as possible, parallelize, smash n grab
4. Small company can't handle load, or stealth needed: drip feed
5. Probably wouldn't bother at all with brute force combinations, when there are millions of publicly released actual passwords to create wordlists from (and humans are predictable) unless totally desperate for a specific account and not under time pressure

Anyway, just for the hell of it I'll write a single threaded wordlist brute forcer and try it out on Mutillidae.

Result:

*** starting admin
100 passwords done for admin: rps=14 - 1234
200 passwords done for admin: rps=14 - 1986673
300 passwords done for admin: rps=14 - 3ware
400 passwords done for admin: rps=14 - 9ijn7ygv
500 passwords done for admin: rps=14 - CMSBATCH
600 passwords done for admin: rps=14 - HP
700 passwords done for admin: rps=13 - NAU
800 passwords done for admin: rps=14 - POSTMASTER
900 passwords done for admin: rps=14 - SESAME
1000 passwords done for admin: rps=14 - USER2
1100 passwords done for admin: rps=14 - accord
*** password for admin is adminpass (1122 requests)
*** elapsed minutes: 1.3283847778320312
*** starting bryce
...
*** password for bryce is PASSWORD (781 requests)
*** elapsed minutes: 0.9175332845052083
...
*** password for dave not found
*** elapsed minutes: 5.59463681233724
...
*** password for PPan is nottelling (3437 requests)
*** elapsed minutes: 4.195157751464844...

Well, you get the idea.