Chapter 4: Web Authentication Attacking

Authentication plays a critical role in the security of a web application since all subsequent security decisions are typically made based on the identity established by the supplied credentials. This chapter covers threats to common web authentication mechanisms, as well as threats that bypass authentication controls entirely.

Web Authentication Threats

We've organized our discussion in this section loosely around the most common types of authentication prevalent on the Web at the time of this writing:

  • Username/Password   Because of its simplicity, this is the most prevalent form of authentication on the Web today.

  • Strong(er) Authentication   Since it's widely recognized that username/ password authentication has fundamental weaknesses, many web sites are beginning to provide stronger forms of authentication to their customers, including token- and certificated-based authentication.

  • Authentication Services   Many web sites outsource their authentication to Internet services such as Microsoft's Passport, which implements a proprietary identity management and authentication protocol.

Username/Password Threats

Although there are numerous ways to implement basic username/password authentication, web implementations generally fall prey to the same types of attacks:

  • Username enumeration

  • Password guessing

  • Eavesdropping

In this section, we'll discuss each of these attack types and which common web authentication protocols are most vulnerable to them.

Note 

We haven't provided risk ratings for any of the attacks listed in this chapter, since these are really generic attack types and the risk level depends on the specific implementation of the attack.

Username Enumeration

 Attack    Username enumeration is primarily used to provide greater efficiency to a password-guessing attack. This approach avoids wasting time on failed attempts using passwords for a user that doesn't exist. For example, if you can determine there is no user named Alice, there's no point wasting time trying to guess the password of Alice. The following are some examples of functionality often used in web applications that may allow you to determine the username:

Profiling Results   In Chapter 2 we discussed a few places to identify ambient user information within a web site, such as source code comments. Smart attackers always review their profiling data since it's often a rich source of such information (textual searches across the profiled information for strings like userid , username, user, usr, name , id, and uid often turn it up).

We will also discuss in Chapter 10 common web site structures that give away usernamesthe most obvious offender here is the directory named after a user that is commonly used by service providers to host customer web content (e.g., http://www.site.com/~joel).

Error Messages in Login   A simple technique to determine if a username exists is to try to log in and look at the error message. For example, try to log in to the web application using the username 'Alice' and the password 'abc123'. You are likely to encounter one of three error messages, unless you actually successfully guessed the password:

  • You have entered a bad username.

  • You have entered a bad password.

  • You have entered a bad username/password combination.

If you received the first error message, the user does not exist on the application or you should not waste anytime trying to guess the password for Alice. However, if you received the second error message, you have identified a valid user on the system, and you can proceed to try to guess the password. Lastly, if you received the third message, it will be difficult to determine if Alice is actually a valid username (this should be a hint to application designers).

A good example of this is the login functionality implemented by the SiteMinder web authentication product from Computer Associates (CA), who acquired the technology with its acquisition of Netegrity in November 2004. With SiteMinder, you can perform username enumeration by evaluating the error page. If an incorrect username is entered, the site attempts to load nouser.html. If a valid username is entered with an incorrect password, the site attempts to load failedlogin.html.

Registration   Many web applications allow users to select their own usernames in the registration process. This presents another vector to determine the username. During the registration process, if you select a username of another user that already exists, you are likely to be presented with an error " please choose another username". As long as the username you have chosen follows the applications guidelines, it is likely you have found another username. When given a choice, people often choose usernames based on their names. For example, Joel Scambray may choose usernames such as: Joel, JoelS, JScambray, etc. Using a list of popular baby names and or a phone book, you can generate a list of common usernames.

Error Message in Password Change   Many web applications also have a password-change functionality that allows users to choose their own password. A separate page is often created for this functionality. Sometimes, the username can be entered, but oftentimes the username is stored in a hidden tag that is used by the POST method. A proxy is often needed to perform this attack, but by evaluating the error message from the password change, you may be able to determine the username.

Account Lockout   To mitigate the risk of a password-guessing attack, many applications lock out accounts after a certain number of failed login attempts. Depending on the security of the application, common account lockout limits are 3, 5, and 10. Also, it is common for applications to automatically unlock accounts after a period of 30 minutes, an hour , or 24 hours. This is done to reduce the number of calls made to call centers to reset accounts. This effectively slows down a password-guessing attack, and given a good password policy, is considered a good balance of security and usability.

However, account lockout only makes sense for valid usernames. How do you lock an account that doesn't exist? These are subtleties that many applications implement incorrectly. For example, if the account lockout is set at 3, will an account be locked out if it doesn't exist? If not, you may have stumbled upon a way to determine invalid accounts. If you lock out an account, the next time you log in, you should receive an error message. However, most applications don't track this for invalid accounts. Lastly, the best way to prevent username enumeration from account lockout is to not tell the user he was locked out at all. However, this will almost surely result in a frustrated and angry user.

Sometimes account lockout is implemented using client-side functionality like JavaScript or hidden tags. For example, there may be a variable or field that represents login attempts. It is trivial to bypass client-side account lockout by writing a script that does not change the number of attempts in the POST login process.

Timing Attacks   If all else fails, a timing attack may be your last resort. If you can't enumerate usernames from error messages, registration, or password changes, try calculating the time it takes for an error message to come up for a bad password versus a bad username. Depending on how the matching algorithm is implemented and types of technologies that are used, there may be a significant difference in the time for the two responses. However, the difference needs to be large enough to overshadow fluctuations due to network latency and load for it to be effective. Keep in mind that this technique has a high risk of false positives. On the other hand, it's just guessing usernames, so even if you have a 25 percent false positive rate, you still are effectively increasing your chances of guessing a valid username.

Before we move into the next section on guessing a password once the username is known, it should be noted that allowing attackers to determine the username is often a risk many online businesses have accepted. Many security professionals know about this risk. It's not that they can't fix this problem, but the businesses have chosen to accept this risk.

Password Guessing

 Attack    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 technique.

Password guessing can usually be implemented 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 manually or via automated means. Manual password guessing is tedious , but we find human intuition infrequently beats 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.

Table 4-1: Common Usernames and Passwords Used in Guessing Attacks (Not Case-sensitive)

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]

As you can see, this is a rather limited list. 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.

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 is likely to trigger account lockout very quickly. Breadth-first algorithms try the combination of different usernames for the same password. This is less likely to trigger account lockout. Let's look at some of the automated web password-guessing tools available today.

Caution 

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. However, if you are a tester, you should determine if there is account lockout.

Tip 

If there is a password policy and it is enforced, you can effectively reduce the character space. For example, if you know that the password policy only allows for alphanumeric characters and requires a combination of capital and lowercase characters , there's no point wasting 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 it is by no means elegant, but it gets the job done. Basic authentication has its fair share of security problems and the problems are well documented (the primary issues are that it sends the username/password in a trivially decode-able 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 successfully guess an HTTP Basic password. 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 a script kiddie , or when you just want a quick check. Figure 4-1 shows WebCracker successfully guessing some accounts on a target URL.


Figure 4-1: WebCracker successfully guesses basic authentication credentials.

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). Figure 4-2 shows the main Brutus interface after performing a Basic authentication password-guessing attack.


Figure 4-2: The Brutus password-guessing tool guesses 4,908 HTTP Basic authentication passwords in 19 seconds.

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 Microsoft's proprietary 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 their 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 OSX, and other UNIX-like systems implement SPNEGO).

Many web security assessment tools do not support NTLM or SPNEGO. In order to assess web applications that use NTLM, you need to use a utility like the NTLM Authorization Proxy Server (APS) by Dmitry Rozmanov, which enables you to use standard HTTP analysis tools to examine applications protected by NTLM-authenticated web applications.

Tip 

A detailed description of how to implement APS is available on the Hacking Exposed Web Applications web site at http://www.webhackingexposed.com under "Contents."

Countermeasures for Password Guessing

 Countermeasure    The most effective countermeasure against password guessing is a combination of a strong password policy and a strong account lockout policy. After a small number of unsuccessful login attempts, the application should lock the account to limit the exposure from this type of attack. However, be careful of denial-of-service attacks against an application with an excessively paranoid account lockout policy. A malicious attacker could try to lock out all of the accounts on the system. A good compromise that many application developers choose is to only temporarily lock out the account for a small period of time, say ten minutes. This effectively slows down the rate of password guessing. With the use of a strong password policy, no account password will be guessable. An effectively large key space for passwords, greater than eight alphanumeric characters, in combination with a strong account policy mitigates the exposure against password brute-forcing.

Note 

Most web authentication schemes have no integrated account lockout featureyou'll have to implement your own logic here. Even IIS, which uses Windows accounts for Basic authentication, does not link the Windows account lockout threshold with HTTP authentication (e.g., locked-out accounts can still successfully authenticate using Basic).

Also, as we've noted already, one issue that can frustrate script kiddies is to use custom response pages for Forms-based authentication. This prevents attackers from using generic tools to guess passwords.

One variation on this is to use Completely Automated Public Turing Test to Tell Computers and Humans Apart (CAPTCHAs ) to fool automated password-guessing routines (see the upcoming section on CAPTCHAs in this chapter for more information).

Finally, it always pays to know what it looks like when you've been attacked. Here is a sample log snippet in an abbreviated W3C format taken from a server that was attacked with a Basic authentication password-guessing tool. Can you guess what tool was used?

 #Fields: c-ip cs-username cs-method cs-uri-query sc-status cs(User-Agent) 192.168.234.32 admin HEAD /test/basic - 401 Mozilla/3.0+(Compatible);Brutus/AET 192.168.234.32 test HEAD /test/basic - 401 Mozilla/3.0+(Compatible);Brutus/AET 192.168.234.32 root HEAD /test/basic - 401 Mozilla/3.0+(Compatible);Brutus/AET 

Of note, on Windows IIS, Basic authentication failures are also written to the System Event Log. This is in contrast to Windows network logon failures, which are not logged by default and are written to the Security Log with a different event ID. Figure 4-3 shows what a typical log event looks like following a Basic password-guessing attack.


Figure 4-3: Password-guessing attempts against Windows IIS result in these events written to the System Log.

Eavesdropping and Replay Attacks

 Attack    Any authentication protocol that exposes credentials while in transit over the network is potentially vulnerable to eavesdropping attacks, which are also called sniffing attacks after the colloquial term for network protocol analyzers.

A replay attack usually is built upon eavesdropping and involves the use of captured credentials by an attacker to spoof the identity of a valid user.

Unfortunately, some of the most popular web authentication protocols do expose credentials on the wire. We'll talk about common attacks against two popular web authentication protocols in the following sections.

Basic   We've already seen how HTTP Basic authentication can be vulnerable to password guessing. Now we'll talk about another weakness of the protocol. In order to illustrate our points, we'll first describe a bit of background on how Basic works.

Basic authentication begins with a client making a request to the web server for a protected resource, without any authentication credentials. The server will reply with an access denied message containing a WWW-Authenticate header requesting Basic authentication credentials. Most web browsers contain routines to deal with such requests automatically by prompting the user for a username and a password, as shown in Figure 4-4. Note that this is a separate operating system window instantiated by the browser, and not an HTML form.


Figure 4-4: A web browser prompts a user for Basic authentication.

Once the user types in his or her password, the browser reissues the requests, this time with the authentication credentials. Here is what a typical Basic authentication exchange looks like in raw HTTP (edited for brevity). First, the initial request for a resource secured using Basic authentication:

 GET /test/secure HTTP/1.0 

The server responds with an HTTP 401 Unauthorized (authentication required) message containing the WWW-Authenticate: Basic header:

 HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="luxor" 

This pops up a window in the client browser that resembles Figure 4-4. The user types his or her username and password into this window and clicks OK to send it via HTTP:

 GET /test/secure HTTP/1.0 Authorization: Basic dGVzdDp0ZXN0 

Note that the client has essentially just resent the same request, this time with an Authorization header. The server then responds with another "unauthorized" message if the credentials are incorrect, a redirect to the resource requested , or the resource itself, depending on the server implementation.

Wait a secondwhere are the username and password? Per the Basic authentication spec, the authentication credentials are sent in the Authorization header in the response, but they are encoded using the Base 64 algorithm, making them appear to have been encrypted or hashed , leading some people to a false sense of security. In reality, Base 64 encoding is trivially reversible using any popular Base 64 decoder. Here is a sample Perl script that will do the job of decoding Base 64 strings:

 #!/usr/bin/perl # bd64.pl # decode from base 64 use MIME::Base64; print decode_base64($ARGV[0]); 

Let's run this bd64.pl decoder on the value we saw in our previous example of Basic authentication in action:

 C:\  bd64.pl dGVzdDp0ZXN0  test:test 

As you can see, Basic authentication is wide open to eavesdropping attacks, despite the inscrutable nature of the value it sends in the Authorization header. This is the most severe limitation of the protocol. When used with HTTPS, the limitation is mitigated. However, client-side risks associated with Basic authentication remain because there is no inactivity timeout or logout without closing the browser.

Digest   Digest authentication was designed to provide a higher level of security than Basic authentication. It is described in RFC 2617. Digest authentication is based on a challenge-response authentication model. This is a common technique used to prove that someone knows a secret, without requiring the person to send the secret in cleartext that would be subject to eavesdropping.

Digest authentication works similarly to Basic authentication. The user makes a request without authentication credentials, and the web server replies with a WWW-Authenticate header indicating credentials are required to access the requested resource. But instead of sending the username and password in Base 64 encoding as with Basic, the server challenges the client with a random value called a nonce . The browser then uses a one-way cryptographic function to create a message digest of the username, the password, the given nonce value, the HTTP method, and the requested URI. A message digest function, also known as a hashing algorithm , is a cryptographic function that is easily computed in one direction, and computationally infeasible to reverse. Compare this with Basic authentication, where reversing Base 64 encoding is trivial. Any hashing algorithm can be specified within the server challenge; RFC 2617 describes the use of the MD5 hash function as the default.

Why the nonce? Why not just hash the user's password directly? Although they have different uses in other cryptographic protocols, the use of a nonce in Digest authentication is similar to the use of salts in other password schemes. It is used to create a larger key space to make it more difficult for someone to perform a database attack against common passwords. Consider a large database that can store the MD5 hash of all words in the dictionary and all permutation of characters with less than ten alphanumeric characters. The attacker would just have to compute the MD5 hash once and subsequently make one query on the database to find the password associated with the MD5 hash. The use of the nonce effectively increases the key space and makes the database attack infeasible by requiring a database that is much larger.

Digest authentication is a significant improvement over Basic authentication, primarily because the user's cleartext password is not passed over the wire. This makes it much more resistant to eavesdropping attacks than Basic authentication. However, Digest authentication is still vulnerable to replay attacks, since the message digest in the response will grant access to the requested resource even in the absence of the user's actual password. But, because the original resource request is included in the message digest, a replay attack should only permit access to the specific resource ( assuming Digest auth has been implemented properly).

Other possible attacks against Digest authentication are outlined in RFC 2617.

Note 

Microsoft's implementation of Digest authentication requires that the server have access to the cleartext version of the user's password so that digests can be calculated. Thus, implementing Digest authentication on Windows requires that user passwords be stored using reversible encryption, rather than using the standard one-way MD4 algorithm.

For those of you who like to tinker, here's a short Perl script that uses the Digest::MD5 Perl module from Neil Winton to generate MD5 hashes:

 #!/usr/bin/perl # md5-encode.pl # encode using MD5 use Digest::MD5 qw(md5_hex); print md5_hex($ARGV[0]); 

This script outputs the MD5 hash in hexadecimal format, but you could output binary or Base 64 by substituting qw(md5) or qw(md5_base64) at the appropriate spot in line 4. This script could provide a rudimentary tool for comparing Digest authentication strings to known values (such as cracking), but unless the username, nonce, HTTP method, and the requested URI are known, this is probably a fruitless endeavor.

An interesting tool for cracking MD5 hashes called MDcrack is available from Gregory Duchemin (see the "References and Further Reading" section at the end of this chapter for a link).

NTLM   Older versions of the NTLM algorithm are vulnerable to eavesdropping attacks ( specifically , the LM algorithm). Although these versions are not used in HTTP-based authentication, it's a good idea to specify that Windows systems use the newer versions, according to Microsoft Knowledge Base Article Q147706.

Eavesdropping Countermeasures

 Countermeasure    The use of 128-bit SSL encryption can thwart these attacks and is strongly recommended for all web sites that use Basic and Digest authentication.

To protect against replay attacks, the Digest nonce could be built from information that is difficult to spoof, such as a digest of the client IP address and a timestamp.

Forms-based Authentication Attacks

 Attack    In contrast to the mechanisms we've discussed to this point, Forms-based authentication does not rely on features supported by the basic web protocols like HTTP (such as Basic or Digest authentication). It is a highly customizable authentication mechanism that uses a form, usually composed of HTML with FORM and INPUT tags delineating fields for users to input their username/password information. After the data is input via HTTP (or HTTPS), it is evaluated by some server-side logic and, if the credentials are valid, some sort of token is given to the client browser to be reused on subsequent requests. Because of its highly customizable and flexible nature, Forms-based authentication is probably the most popular authentication technique deployed on the Internet. However, since it doesn't rely on any features of standardized web protocols, there is no standardized way to perform Forms-based authentication.

Let's present a simple example of Forms-based authentication to illustrate the basic principles on which it is based. This example will be based on Microsoft ASP.NET Forms Authentication because of its simplicity, but we'll note key points that are generic to Forms authentication. Here's the scenario: you have a single directory on a web server with a file, default.aspx, that should require Forms authentication to read. In order to implement ASP.NET Forms authentication, two other files are needed: a web.config file in this directory (or at the application root), and a login form to take username/password input (call it login.aspx). The web.config file specifies which resources will be protected by Forms authentication, and it contains a list of usernames and passwords that can be queried to validate credentials entered by users in login.aspx. Of course, any source of username/password information could be usedfor example, a SQL database. It is recommended that the hash of the password is stored instead of the original password to mitigate the risk of exposing the passwords. Here's what happens when someone requests default.aspx:

 GET /default.aspx HTTP/1.0 

Since the web.config file specifies that all resources in this directory require Forms authentication, the server responds with an HTTP 302 redirect to the login page, login.aspx:

 HTTP/1.1 302 Found Location: /login.aspx?ReturnUrl=%2fdefault.aspx 

The client is now presented with the login.aspx form, shown in Figure 4-5. This form contains a hidden field called "state," and two visible fields called "txtUser" that takes the username input and "txtPassword" that takes the password input. These are all implemented using HTML INPUT tags. The user diligently enters his or her username and password and clicks the Login button, which POSTs the form data (including hidden fields) back to the server:


Figure 4-5: A standard login form implemented in ASP.NET
 POST /login.aspx?ReturnUrl=%2fDefault.aspx HTTP/1.0 STATE=gibberish&txtUser=test&txtPassword=test 

The POST method should always be used instead of the GET verb for sending the username and password, although both verbs accomplish the same thing. Using GET has a number of security issues. Since web servers, Internet browsers, and proxy servers often cache and log data in the GET header, using GET in a login page can inadvertently expose the username and password.

Note that unless SSL is implemented, the credentials traverse the wire in cleartext, as shown here. The server receives the credential data and validates them against the username/password list in web.config (again, this could be any custom datastore). If the credentials match, then the server returns an "HTTP 302 Found with a Location" header redirecting the client back to the originally requested resource (default.aspx) with a Set-Cookie header containing the authentication token:

 HTTP/1.1 302 Found Location: /Default.aspx Set-Cookie: AuthCookie=45F68E1F33159A9158etc.; path=/ htmlheadtitleObject moved/title/headbody 

Note that the cookie here is encrypted using 3DES, which is optionally specified in ASP.NET's web.config file. Now the client re-requests the original resource, default.aspx, but this time it presents the authentication token (the cookie):

 GET /Default.aspx HTTP/1.0 Cookie: AuthCookie=45F68E1F33159A9158etc. 

The server verifies the cookie is valid and then serves up the resource with an HTTP 200 OK message. All of the 301 and 302 redirects occur silently with nothing visible in the browser. End result: user requests resource, is challenged for username/password, and receives resource if he or she enters the correct credentials (or a custom error page if he or she doesn't). The application may optionally provide a "Sign Out" button that deletes the cookie when the user clicks on it. Or the cookie can be set to expire in a certain timeframe when it will no longer be considered valid by the server (such as inactivity or maximum session length timeouts).

Again, this example uses a specific end-to-end technology, ASP.NET FormsAuthentication, to demonstrate the basics of Forms authentication. Any other similar technology or set of technologies could be employed here to achieve the same result.

From this example, Forms-based authentication is clearly subject to password-guessing attacks. We like to use Brutus (introduced earlier in this chapter) for attacking Forms-based authentication, primarily because of its Modify Sequence Learn Form Settings feature. This allows you to simply specify a URL to a login form and Brutus automatically parses out the fields for username, password, and any other fields supported by the form (including hidden). Figure 4-6 shows the HTML form interpreter.


Figure 4-6: Brutus' HTML form interpreter parses a login form, highlighting fields for subsequent attack.

Brutus also allows you to specify what responses you expect from the login form if a successful event occurs. This is important; because of the highly customizable nature of Forms authentication, it is common for sites to implement unique response pages to successful or unsuccessful logins. This is one of the primary impediments to successful password guessing against Forms-based authentication. With the Brutus tool, you can customize password guessing to whatever responses the particular target site uses.

Forms-based authentication is also clearly vulnerable to eavesdropping and replay attacks if the authentication channel is not protected in some manner, such as with HTTPS.

Forms-based authentication often uses session cookies to temporarily store an authentication token so a user accessing a web site does not have to constantly input the information over and over again. A session cookie is stored only in memory, as opposed to a persistent cookie that is stored on the disk and persists across sessions. Cookies can sometimes be manipulated or stolen outright , and may disclose inappropriate information if they are not encrypted (note that ASP.NET was configured to 3DES-encrypt the cookie in our example). See Chapters 7 and 12 for more on attacking cookies.

Hidden tags are another technique used to store transient information about a user (we saw the hidden field "state" was passed with authentication credentials in our previous example). Authentication credentials themselves can also be stored within hidden tags, making them "hidden" from the user. However, as we've seen, hidden tags can be modified by attackers before they are POSTed to the server at login time.

Bypassing SQL- backed Login Forms   On web sites that perform Forms-based authentication with a SQL backend, SQL injection can be used to Bypass authentication (see Chapter 8 for more specific details on the technique of SQL injection). Many web sites use databases to store passwords and use SQL to query the database to validate authentication credentials. A typical SQL statement will look something like the following (this example has been wrapped across two lines due to page-width constraints):

 SELECT * from AUTHENTICATIONTABLE WHERE Username = 'username input'          AND Password = 'password input' 

If input validation is not performed properly, injecting

 Username' -- 

in the username field would change the SQL statement to this:

 SELECT * from AUTHENTICATIONTABLE WHERE Username = 'Username'          AND Password = 'password input' 

The dashes at the end of the SQL statement specify that the remainder of the SQL statement is comments and should be ignored. The statement is equivalent to this:

 SELECT * from AUTHENTICATIONTABLE WHERE Username = 'Username' 

And voil ! The check for passwords is magically removed!

This is a generic attack that does not require much customization based on the web site, as do many of the other attacks for Forms-based authentication. We've seen tools in the underground hacker community that automate this attack.

To take the attack one level higher, SQL injection can be performed on the password field as well. Assuming the same SQL statement is used, using a password of

 DUMMYPASSWORD' OR 1 = 1 - 

would have a SQL statement of the following (this example has been wrapped across two lines due to page-width constraints):

 SELECT * from AUTHENTICATIONTABLE WHERE Username = 'Username'        AND Password = 'DUMMYPASSWORD' OR 1 = 1 - ' 

The addition of OR 1 = 1 at the end of the SQL statement would always evaluate as true, and authentication can once again be bypassed.

Many web authentication packages were found to be vulnerable to similar issues in mid-2001. The Apache mod_auth_mysql, oracle, pgsql, and pgsql_sys built SQL queries and did not check for single quotes (these vulnerabilities were described in a CERT advisory from the University of Stuttgart, Germany; see the "References and Further Reading" section at the end of this chapter for a link).

Countermeasure

 Countermeasure  The same countermeasures we discussed previously for password guessing, eavesdropping, and replay attacks are advised for Forms-based authentication as well.

The best way to prevent SQL injection is to perform input validation (see Chapter 8). For authentication, input validation becomes a little tricky. Input validation on the username field is trivial; most usernames are well defined. They are alphanumeric and are usually 610 characters in length. However, strong password policies encourage long passwords that contain special characters; this makes input validation much more difficult. A compromise needs to be made with characters that are potentially dangerous that cannot be used in passwords, such as single quotes.

We'll also throw in the standard admonition here to ensure that all software packages used by your web application are up-to-date. It's one thing to have a Forms bypass attack performed against your own custom code, but something else entirely when your free or commercial authentication package turns up vulnerable to similar issues.

Strong(Er) Web Authentication

Clearly, the username/password-based authentication mechanisms that predominate on the Web today have their faults. What alternatives exist? Are there weaknesses with them as well?

Passwords are only single-factorsomething the user knows. Passwords are also typically very low-entropy credentials, which makes password guessing feasible . Thus, the primary mitigation for password-based authentication risks is to move to multifactor authentication, preferably using higher-entropy credentials. We'll discuss some classic and new approaches making their way into the market currently. These new approaches mark the evolution of authentication on the Web to functionality that is more resistant to the rising risk of online fraud, such as from phishing (see Chapter 10 for more information on phishing).

Digital Certificates

Certificate authentication is stronger than any of the authentication methods we have discussed so far. Certificated authentication uses public key cryptography and a digital certificate to authenticate a user. Certificate authentication can be used in addition to other password-based authenticated schemes to provide stronger security. The use of certificates is considered an implementation of two-factor authentication. In addition to something you know (your password), you must authenticate with something you have (your certificate). Certificates can be stored in hardware (e.g., smart cards) to provide an even higher level of securitypossession of a physical token and availability of an appropriate smart card reader would be required to access a site protected in such a manner.

Client certificates provide stronger security, however, at a cost. The difficulty of obtaining certificates, distributing certificates, and managing certificates for the client base makes this authentication method prohibitively expensive for large sites. However, sites that have very sensitive data or a limited user base, as is common with business-to-business (B2B) applications, would benefit greatly from the use of certificates.

There are no current known attacks against certificate-based authentication given the private certificate remains protected. Most certificate-based systems by default don't check certificate revocation lists (CRLs) and a stolen and revoked certificate may still be used. There is the obvious attack against the PKI infrastructure or attacks against authorization (see Chapter 6), but that is not restricted to certificate-based authentication itself.

As we saw in Chapter 1, many web hacking tools support certificate-based authentication. For example, IE extensions like TamperIE make it easy to manipulate forms protected by SSL right within the browser. HTTp proxy tools like Paros Proxy also support SSL.

PassMark/SiteKey

 Attack    PassMark Security, Inc. was founded in 2004 to focus on strong authentication in the financial services market, and by year-end 2005, they claimed nearly 15 million customers were protected by their PassMark technology. This is likely due almost entirely to Bank of America's implementation of PassMark technology in mid-2005 for their 13 million online banking customers. BofA branded their implementation "SiteKey."

PassMark/SiteKey is based on two-factor, "two-way," authentication. It uses two-factor authentication comprised of a user password and information about the device from which they are authenticating (multiple devices can be registered). To achieve twoway authentication, the user is provided secret information during the login process so that they can authenticate the site.

Here's how this works in practice: at login, the user's device is authenticated passively using a special device ID created at account registration, providing for server-to-client authentication. The user types in their username and is then challenged to identify an image and associated phrase before they type in their password. The image/phrase is designed to provide simple, visual/textual authentication of the site, to mitigate against malicious sites masquerading or spoofing the legitimate one (as in the case with phishing). After entering the correct password, the user is authenticated as normal. See the "References and Further Reading" section at the end of this chapter for links to further demonstrations of PassMark/SiteKey.

PassMark/SiteKey provides for better security than simple username/password-based systems, but how much better? We've tested some PassMark-protected applications in our consulting work, and here are some of our findings, integrated with criticisms from the Internet community at large.

One of the early assertions that PassMark is vulnerable to man-in-the-middle (MITM) attack appears unfounded. PassMark uses secure cookies, which are only sent on SSL connections. Unless the user accepts the failed SSL handshake, the secure cookie isn't sent across. So, PassMark appears no more vulnerable than SSL itself to MITM attacks.

However, when Bank of America's SiteKey implementation can't identify the device from which you are authenticating (because it hasn't been registered), it will ask you to answer a secret question. This is susceptible to a MITM attack since the attacker can just proxy the question/answer between the user/web site.

Additionally, PassMark's design of presenting a unique image/phrase to valid users creates a username enumeration vulnerability by allowing an attacker to easily determine if an account is valid or not. As we noted at the outset of this chapter in our discussion of username enumeration, this is not generally a severe vulnerability, since the attacker would still have to guess the password associated with the account.

Some of the broader community's criticisms of PassMark and SiteKey have included assertions that PassMark is only encumbering existing username/password systems with the addition of a device ID, raising usability issues as users are prompted for numerous secret questions when they inevitably attempt to authenticate from various devices (other computers, kiosks , phones, PDAs, etc.).

Perhaps most seriously, some critics have raised the issue of PassMark creating universal reliance on the ongoing confidentiality of consumer device ID information (which must be stored by the authenticating businesses). If one implementer suffers a security breach of device ID information, all implementers of PassMark potentially lose the benefit of two-factor authentication that it provides. See the "References and Further Reading" section at the end of this chapter for links to more analyses of PassMark and SiteKey.

One-time Passwords (OTP)

One-time passwords (OTPs) have been around for many years . As you might guess from the name, OTP protocols involve a server and client pre-establishing a collection of secrets (say, a list of passwords) that are used only once per authentication transaction. So, continuing with our example of password lists, at the first authentication, the client provides the first password on the list, and both the server and the client then delete that password from the list, making it useless for future authentications. The primary idea behind OTP is to reduce much of the sensitivity of the password itself, so users don't have to be exposed to the complexities of keeping them secure. Links to more information about OTP can be found in the "References and Further Reading" section at the end of this chapter.

The most popular commercial OTP implementation at the time of this writing is RSA Security's SecureID system. Rather than shared lists of passwords, SecureID implements a synchronization protocol between the client and server, such that passwords (actually numeric sequences or PIN codes) are only usable within a small window of time (say, 30 seconds). This clever variation on OTP provides for high security since the password is only valuable to the attacker within the 30-second window (for example). After each time window expires , the client generates a new password in synchronization with the server. The client is typically a small hardware device (sometimes called a dongle or fob ) that performs the OTP protocol and generates new passwords at each time interval.

OTP systems have historically proven resistant to attack (at least, the well-implemented ones like SecureID) and remain popular for limited scale, higher-security applications such as remote access to corporate networks. The main drawback to larger-scale, consumer-oriented deployments remains the cost of the client devices, distribution, and management, which can run as much as $100 per customer per device. Business and consumer attitudes towards these costs have started to change with the recent increased attention to online fraud, and businesses are starting to turn to OTP to address customer concerns in this area.

The most visible evidence for this is online financial institution E*Trade's implementation of SecureID for select customers, announced in March 2005 (see the "References and Further Reading" section at the end of this chapter for links). E*Trade calls it the "Complete Security System with optional Digital Security ID," and they provide it free of charge to premium customers, or to customers maintaining certain minimum balance and transaction volumes in a given period (as of this writing, a balance of $50,000 or more in combined accounts or at least 30 stock or option trades per quarter). E*Trade hedges its bets somewhat by noting in their terms of use that a $25 charge may be imposed for each additional or replacement SecureID fob, and that they may impose a fee or may discontinue the service in the future.

Like any security measure, OTP is not perfect. Cryptography expert Bruce Schneier published a paper identifying how phishing can still bypass OTP by setting up a fraudulent site that simply proxies the OTP exchange with the legitimate site, or by simply installing malicious software on the user's computer that hijacks a previously authenticated session. And of course, there is always the potential for replay if the window for password re-use is set too wide. Nevertheless, OTP clearly raises the bar for security, and the attacks proposed by Schneier are generic to any authentication system and will need to be addressed separately to some extent. It will be interesting to see if E*Trade can demonstrate success with OTP, and if this drives wider adoption in the marketplace .

Web Authentication Services

Many web site operators simply want to outsource the complexities of security, especially authentication. The market quickly recognized this phenomenon in the late 1990s, as Microsoft acquired Firefly Network and adapted its technologies to become one of the Internet's first authentication services, Microsoft Passport, that could be used by other sites to manage customer identities and authenticate them as well. Aside from the pseudopublic key infrastructure (PKI) that has developed to support the global use of SSL on the Web, Passport is arguably the only large-scale implementation of such a service, so we'll spend most of our time in this section discussing it.

Note 

The Liberty Alliance Project is often cited as a competitive effort to Passport, but to date, it remains focused on developing specifications for authentication services rather than actually implementing one.

Microsoft Passport

 Attack    Passport is Microsoft Corporation's universal single sign-on (SSO) platform for the Internet. It enables the use of one set of credentials to access any Passport-enabled site, such as MSN, Hotmail Messenger. Although Microsoft once encouraged third-party companies to use Passport as a universal authentication platform, they appear to have abandoned this business strategy and now focus Passport solely on supporting Microsoft-hosted applications.

Passport works essentially as follows. A user browses to the Passport Registration site and creates a user profile, including a username and password. The user is now considered a Passport member , and his or her credentials are stored on the Passport servers. Meanwhile, abc.com decides to become a Passport Partner, downloads the Passport SDK, and signs an agreement with Microsoft. abc.com then receives a cryptographic key via express mail and installs it on their web server(s), along with the Passport Manager tool from the SDK. Passport's login servers retain a copy of this cryptographic key.

Now, when a Passport member peruses secured content on abc.com's site, they are redirected to Passport's login servers. They are then challenged with a login page that takes their Passport credentials as input. After successfully authenticating, the Passport's login servers set an authentication cookie in the client browser (other data may be sent as well, but it's the authentication cookie we're interested in for this discussion). This authentication cookie contains data indicating that the user has successfully authenticated to the Passport service, encrypted using the cryptographic key shared by both Passport and the Partner. The client is then redirected back to abc.com's server, and now supplies the authentication cookie. The Passport Manager on abc.com's server validates the authentication cookie using the shared cryptographic key installed previously and passes the client to the secured content. Overall, Passport is much like Forms-based authentication, with the key difference being that instead of consulting a local list of username/passwords, it asks the Passport service if the credentials are valid.

There are a number of variations on the basic mechanism of Passport authentication that we will not cover here; they involve login forms resident on Partner sites, and alternative mechanisms for authenticating to Passport, such as via Outlook Express authenticating to Hotmail.com servers. For more information on these, see the Passport link in the "References and Further Reading" section at the end of this chapter. A diagram of the basic Passport authentication system is shown in Figure 4-7.


Figure 4-7: An overview of the Microsoft Passport single sign-on (SSO) protocol

Here are the relevant details of each step in Figure 4-7. In step 1, the client requests the secure content on the Partner site (in this case, my.msn.com):

 GET /my.ashx HTTP/1.0 Host: my.msn.com 

In step 2, the client is then redirected to the login form at http://login.passport.com/login.asp. The query string in the Location header contains information to identify which Partner site originated the request (id=) and the URL to return to once authentication is successful (return URL, or ru=). Also, the WWW-Authenticate header reads Passport version 1.4:

 HTTP/1.1 302 Object Moved Location: http://login.passport.com/login.asp?id=6528&ru=http://my.msn.com/etc. WWW-Authenticate: Passport1.4 id=6528,ru= http://my.msn.com/etc. 

The client now requests the login page from login.passport.com in step 3:

 GET /login.asp?id=6528&ru=http://my.msn.com/etc. HTTP/1.0 Referer: http://www.msn.com/ Host: login.passport.com 

The user then enters his or her Passport password into login.asp and POSTs the data; note that the credentials are sent via SSL but appear as cleartext in our trace, which was performed on the machine performing the login. Partners are not required to use SSL between the client and the Partner site, which could potentially expose Passport tokens to eavesdroppers.

 POST /ppsecure/post.srf?lc=1033&id=6528&ru=http://my.msn.com/etc. HTTP/1.0 Referer: http://login.passport.com/login.asp?id=6528&ru= http://my.msn.com/etc. Host: loginnet.passport.com     login=johndoe&domain=msn.com&passwd=guessme=&mspp_shared= 

In step 4, following successful login, Passport's login servers set a series of cookies on the client. The important cookie here is the MSPAuth cookie, which is the Passport authentication ticket.

 HTTP/1.1 200 OK Set-Cookie: MSPAuth=4Z9iuseblah;domain=.passport.com;path=/ Set-Cookie: MSPProf=4Z9iuseblah;domain=.passport.com;path=/ etc. 

Finally, in step 5, the client then gets sent back to the original resource on the Partner site (which Passport's login servers remember from the ru value in the original query string), this time with the MSPAuth ticket in hand:

 GET /my.ashx HTTP/1.0 Host: my.msn.com Cookie: MSPAuth=2Z9iuseblah; MSPProf=2Z9iuseblah 

Since the Passport architecture is essentially shared key, as we discussed earlier, the Partner site can now decrypt the cookie, extract the relevant information, and set its own cookie within the client browser (Passport cannot set an authentication cookie directly since it is not allowed to set a cookie within another domain by most modern browser security features).

Now that the client presents the appropriate authorization ticket, it gets access to the resource. Although this seems like a few round-trips, it all happens rather quickly and transparently to the user, depending on the speed of the Internet connection.

The single-sign-on effect is achieved by retaining the original Passport cookies. This allows the client to transparently "authenticate' to any subsequent Passport site by repeating step 5 of our sequence with the new Partner site. Like any cookie, the Passport cookies can be stored in volatile memory and expire when the browser is closed, or they can be saved to disk if the "Save my e-mail address and password" option is selected at logon. The Partner site can also specify an expiration time for the cookie in order to limit the window for replay attacks.

To sign out, the user clicks the Passport Sign Out icon and is again redirected to login.passport.com, which then deletes the Passport cookies (sets them to NULL) and returns the client to the Partner site:

 HTTP/1.1 200 OK Host: login.passport.com Authentication-Info: Passport1.4 da-status=logout Set-Cookie: MSPAuth= ; expires=Thu, 30-Oct-1980 16:00:00     GMT;domain=.passport.com;path=/;version=1 Set-Cookie: MSPProf= ; expires=Thu, 30-Oct-1980 16:00:00     GMT;domain=.passport.com;path=/;version=1 etc. 

This has been a fairly simple overview of the Passport system. It is much more complex in its total feature set and operation, but we've avoided a lot of the complexity in our description here to present the fundamental mechanism in easily understandable terms.

There have been a few attacks against Passport proposed since its introduction in 1999. In 2000, David P. Kormann and Aviel D. Rubin published a paper entitled "Risks of the Passport Single Signon Protocol" that described a series of attacks more germane to basic web features like SSL, Netscape browser bugs , cookies, JavaScript, and DNS spoofing. They also pointed out that anyone can spoof a Passport login page and harvest member credentials (the so-called " bogus Partner" attack), and speculated that Partner site keys were transmitted over the Internet in a vulnerable fashion. The entire paper reiterates known issues with Internet authentication services, and demonstrates no real research into specific problems with the Passport platform.

In August 2001, Chris Shiflett published a paper based on a vulnerability in Internet Explorer browsers prior to version 5.5 that allowed malicious sites or e-mail messages to read cookies on client machines. He also noted that if a Passport member opted to save his or her Passport cookies locally, an attack that leveraged this vulnerability could be used to steal Passport cookies and masquerade as the victimized member. The IE hole has subsequently been fixed, and Chris rightly recommends that users do not select the "Sign me in automatically" option when using Passport (which sets a persistent cookie on the user's machine).

Later in 2001, security researcher Marc Slemko posted an analysis called "Microsoft Passport to Trouble," in which he describes an exploit he devised that would allow him to steal Passport authentication cookies using script injection on Hotmail servers that use Passport authentication. Microsoft has since fixed the problem, but this attack is an excellent example of how to steal authentication cookies.

In 2002, the United States Federal Trade Commission (FTC) announced the result of an investigation into Passport's security, and that it had reached a Consent Decree with Microsoft concerning prior marketing representations of Passport's security capabilities. Microsoft was ordered to not "misrepresent in any manner its information practices" surrounding a "covered online service," and to "establish and maintain a comprehensive information security program in writing that is reasonably designed to protect the security, confidentiality, and integrity of personal information collected from or about consumers" by such services. The agreement carried a twenty-year term, with biannual audit requirements, and a potential penalty of $11,000 per violation per day.

In May of 2003, Muhammad Faisal Rauf Danka posted information to the Full Disclosure mailing list describing a Passport vulnerability that permitted a malicious user to reset the password of another Passport user. The attacker had to know the name of the account he wished to reset (for example, someone@hotmail.com). Nevertheless, this was a serious attack that basically left all Passport accounts vulnerable to hijack . Microsoft announced a fix for this issue within 24 hours, and did not report any account compromises. The FTC apparently deemed this issue did not qualify as a violation of the 2002 agreement, as no fines were announced. We'll discuss the details of this attack later in this chapter when we cover identity management attacks.

A common theme across many of these analyses suggests that one of the biggest dangers in using Passport authentication is replay attacks using Passport authentication cookies stolen from unsuspecting users' computers. Of course, assuming an attacker could steal authentication tickets would probably defeat most authentication systems out of the gate, as we noted in our earlier discussion of security token replay attacks in this chapter.

Like any other authentication system, Passport is also potentially vulnerable to password guessing attacks (the minimum Passport password length is six characters, with no requirements for different case, numbers, or special characters). Although there is no permanent account lockout feature, after a certain number of failed login attempts, an account will be temporarily prevented from logging in (this lasts a "few moments" according to the error message). This is designed to add significant time to online password guessing attacks. Attackers may attempt to reset their passwords during a block, but must answer a "secret question" preset by the valid Passport account owner during registration.

Despite these issues, we feel Passport is a strong option for web sites that don't mind if someone else owns their customers' authentication credentials. However, as of this writing, it doesn't appear as though Microsoft is going support Passport use at non-Microsoft hosted sites any longer.



Hacking Exposed Web Applications
HACKING EXPOSED WEB APPLICATIONS, 3rd Edition
ISBN: 0071740643
EAN: 2147483647
Year: 2006
Pages: 127

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net