In our last blog series we explored horizontal password guessing attacks. Check out Horizontal Password Guessing Attacks Part I and Part II in case you missed them. This time we'll test our web application with vertical password guessing attacks. Whereas horizontal password guessing attacks entail trying only a few common passwords against a long list of usernames, vertical password guessing attacks entail trying a long list of passwords against a single username. But where do you get a long list of passwords? Wordlists are readily available on the internet. For example, CrackStation offers a ridiculous 15 GB wordlist containing 1,493,677,782 words. CrackStation also offers a more practical 684 MB wordlist containing approximately 64 million common passwords. However, before getting our hands dirty let's consider several important factors:
- Does the web application allow valid account determination? For example, does login functionality return deterministic error message such as "Invalid Username" or "Invalid Password"? If login functionality does not allow valid account determination, "Create Account" or "Forgot Password" functionality might. If the application does not allow valid account determination, you'll need to somehow identify a target username or resort to username guessing. Refer to Horizontal Password Guessing Attacks Part II for more information regarding username guessing.
- Does the web application enforce account lockout? If so, vertical password guessing attacks must be sufficiently throttled in order to avoid account lockout. Depending on the application password policy and account lockout settings, vertical password guessing attacks might be largely ineffective. •Does the web application implement CAPTCHA? If so, automating password guessing attacks might not be possible. However, you should verify that the CAPTCHA implementation works properly, and does not fail open or otherwise allow attackers to bypass manual verification.
- Does the application enforce a password policy including password length and complexity requirements? If so, the wordlist should be optimized for the application. However, it is important to verify that the web application actually enforces the advertised password policy. If the password policy is not enforced by the application, some users will likely not comply with the policy. In addition, if the password policy is only enforced by the browser, users with JavaScript disabled might unknowingly not comply with the policy. Furthermore, it is important to verify that the application did not enforce a more lenient password policy in the past. If so, and passwords are not required to be changed on a periodic basis, users that last changed passwords before the updated password policy might not comply with the policy.
Let's take our discussion of wordlist optimization to the next level. As previously stated, the wordlist should be optimized according to the password policy enforced by the application. Let's brainstorm regular expressions that can be used to prune our wordlist accordingly:
- .{N,} – At least N characters in length.
- .{N,M} – Between N and M characters in length.
- [[:alpha:]] – Contains a letter.
- [[:lower:]] – Contains a lowercase letter.
- [[:upper:]] – Contains an uppercase letter
- [[:digit:]] – Contains a number.
- [[:punct:]] – Contains a special character.
For example, consider this simple wordlist that contains a dozen words:
$ cat wordlist Foo foobar FooBar FOOBAR foobar12 FooBar34 FOOBAR56 foobar7! FooBar8@ FOOBAR9$ 12345678 Supercalifragilisticexpialidocious9%
That's right, somewhere right now Mary Poppins is guessing passwords! Mary Poppins is totally 31337! In any case, if the web application enforces a password length requirement of six characters, the following command will optimize the wordlist accordingly:
$ grep -E ".{6,}" wordlist
foobar
FooBar
FOOBAR
foobar12
FooBar34
FOOBAR56
foobar7!
FooBar8@
FOOBAR9$
12345678
Supercalifragilisticexpialidocious9%If the web application also enforces password complexity requirements that passwords must contain at least one letter and one number, the following command will optimize the wordlist accordingly:
$ grep -E ".{6,}" wordlist | grep -E "[[:alpha:]]" | grep -E "[[:digit:]]"
foobar12
FooBar34
FOOBAR56
foobar7!
FooBar8@
FOOBAR9$
Supercalifragilisticexpialidocious9%Notice that the applicable grep commands are chained together. While it is certainly possible to construct a monster regular expression in order to get the job done with a single grep command, that would introduce needless complexity. Keep it simple. Finally, consider a web application with a strong password policy that enforces a password length requirement of six characters and password complexity requirements that passwords must contain at least one lowercase letter, uppercase letter, number, and special character:
$ grep -E ".{8,}" wordlist | grep -E "[[:upper:]]" | grep -E "[[:lower:]]" |
grep -E "[[:digit:]]" | grep -E "[[:punct:]]"
FooBar8@
Supercalifragilisticexpialidocious9%Just chain together the magic combination of grep commands that matches the password policy, redirect the output to a new file, and say "Abracadabra" in a dramatic voice. Poof! Your wordlist has been optimized! Piece of cake, eh? In the next installment we'll leverage our customized wordlist in order to launch a vertical password guessing attack.