Not surprisingly, password guessing is the bane of username/password authentication schemes. Unfortunately, such schemes are common on the Web today and thus fall prey to this most basic attack techniques.
Password-guessing attacks can usually be executed regardless of the actual authentication protocol in place. Manual guessing is always possible, of course, and automated client software exists to perform password guessing against the most commonly used protocols. We’ll discuss some common password-guessing tools and techniques next.
Manual Password Guessing Password-guessing attacks can be carried out via both manual and automated means. Manual password guessing is tedious, but we find human intuition frequently bests automated tools, especially when customized error pages are used in response to failed forms-based login attempts. When performing password guessing, our favorite choices are shown in Table 4-1.
While the list in Table 4-1 is limited, it serves as a good illustration of the type of weak passwords commonly used in applications. With an automated tool, an entire dictionary of username/password guesses can be thrown at an application much more quickly than human hands can type them. A basic search engine query will reveal that several of these dictionaries are widely available online, including tailored dictionaries that focus on certain types of applications, hardware, or devices.
Automated Password Guessing There are two basic approaches to automated password guessing: depth first and breadth first. Depth-first algorithms try all the password combinations for a username before trying the next username. This approach is likely to trigger account lockout very quickly because hundreds of authentication attempts will be made against the same account in a short amount of time. Breadth-first algorithms try the combination of different usernames for the same password. Because the authentication attempts are not made consecutively against the same account, the breadth-first method is less likely to trigger an application’s account lockout mechanism. Let’s look at some of the automated web password-guessing tools available today.
Automatic password guessing can perform a denial-of-service attack against the application. There is always an increased load on the server and the risk of locking accounts. If you are an attacker, this may be intentional. If you are a tester, however, you should determine if there is an account lockout and proceed accordingly.
Username Guesses Password Guesses
[NULL] [NULL]
root, administrator, admin [NULL], root, administrator, admin, password, [company_name]
operator, webmaster, backup [NULL], operator, webmaster, backup guest, demo, test, trial [NULL], guest, demo, test, trial
member, private [NULL], member, private
[company_name] [NULL], [company_name], password
[known_username] [NULL], [known_username]
If a password policy is in place and enforced, you can reduce the set of possible passwords to just those permitted by the password policy. For example, if you know that the password policy only allows for alphanumeric characters and requires a combination of capital and lowercase characters, you don’t need to waste time on dictionary words that don’t include numbers. On the other hand, if you are looking at a banking application that uses a four-digit ATM PIN as the password, you know you’ve got a pretty good chance of guessing the PIN/password in around 5,000 guesses.
One of the most common authentication protocols used on the Internet today is HTTP Basic. It was first defined in the HTTP specification itself, and while it is by no means elegant, it does get the job done. Basic authentication has its fair share of security problems, and those problems are well documented (the primary issues are that it sends the username/password in a trivially decodeable fashion and that it eagerly sends these credentials with each request).
When we encounter a page protected by Basic authentication in our consulting work, we generally turn to Hydra to test account-credential strength. Hydra is a simple tool that takes text lists of usernames and passwords (or combinations of both) and uses them as dictionaries to implement Basic authentication password guessing. It keys on “HTTP 302 Object Moved” responses to indicate a successful guess, and it will find all successful guesses in a given username/password file (that is, it won’t stop guessing once it finds the first valid account). The following example shows Hydra being used on Windows (via the Cygwin library) to guess an HTTP Basic password successfully. We’ve used Hydra’s –C option to specify a single username/password file as input and we are attacking the /secure directory (which must be specified following the http-get
parameter):
D:\Toolbox>hydra -C list.txt victim.com http-get /secure
Hydra v5.0 (c) 2005 by van Hauser / THC - use allowed only for legal purposes. Hydra (http://www.thc.org) starting at 2005-11-08 21:21:56
[DATA] 6 tasks, 1 servers, 6 login tries, ~1 tries per task [DATA] attacking service http-get on port 80
[STATUS] attack finished for victim.com (waiting for childs to finish) [80][www] host: 192.168.224.40 login: user password: guessme
Hydra (http://www.thc.org) finished at 2005-11-08 21:22:01
Hydra supports http-head,http-get,https-head,https-get, and http-proxy
for attacking web applications.
WebCracker is an older, Windows-based GUI application that is similar to Hydra but is not as customizable in our experience. It is an excellent tool for a novice, or for performing a quick assessment of account password strength. Figure 4-1 shows WebCracker successfully guessing some accounts on a target URL.
Brutus is a generic password-guessing tool that comes with built-in routines for attacking HTTP Basic and Forms-based authentication, among other protocols like SMTP and POP3. Brutus can perform both dictionary attacks (based on precomputed wordlists like dictionaries) and brute-force attacks, where passwords are randomly generated from
a given character set (say, lowercase alphanumeric characters). Figure 4-2 shows the main Brutus interface after performing a Basic authentication password-guessing attack.
Brutus also performs Forms-based authentication attacks (which we will discuss in an upcoming section). The one thing that annoys us about Brutus is that it does not display guessed passwords when performing Forms-based attacks. We have also occasionally found that it issues false positive results, claiming to have guessed an account password when it actually had not. Overall, however, it’s tough to beat the flexibility of Brutus when it comes to password guessing.
NTLM Authorization Proxy Server Integrated Windows authentication (formerly known as NTLM authentication and Windows NT challenge/response authentication) uses the
proprietary Microsoft NT LAN Manager (NTLM) authentication algorithm over HTTP. It is implemented primarily by Microsoft’s Internet Explorer browser and IIS web servers, but is also available in other popular software like Mozilla’s Firefox browser through its support of the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Internet standard (RFC 2478) to negotiate Kerberos, NTLM, or other authentication protocols supported by the operating system (for example, SSPI on Microsoft Windows, GSS-API on Linux, Mac OS X, and other UNIX-like systems implement SPNEGO).
Support for NTLM authentication in security assessment tools has greatly improved over the years, and this support is available in both the Paros and Burp client-side proxies. If your tool of choice does not support NTLM, that support can be obtained through the NTLM Authorization Proxy Server (APS) utility created by Dmitry Rozmanov.
A detailed description of how to implement APS is available on the Hacking Exposed Web Applications
web site at http://www.webhackingexposed.com/ntlm-aps.html.