Bypassing Authentication

Many times you find yourself banging against the wall when a door is open around the corner. This idea is similar to attacking web authentication. As we noted in the beginning of the chapter, many applications are aware of the important role that authentication plays in the security of the application, and therefore they implement very strong protocols. In these situations, directly attacking the protocol itself may not be the easiest method of hacking authentication.

Attacking other components of the application, such as hijacking or spoofing an existing authenticated session, or attacking the identity management subsystem itself, can both be used to bypass authentication altogether. In this section, we'll discuss some common attacks that bypass authentication entirely.

Token Replay

It's common to issue a security token of some sort to users who have successfully authenticated so that they do not need to retype credentials while traversing an application. An unfortunate side effect of this mechanism is that authentication can be bypassed by simply replaying maliciously captured tokens, a phenomenon sometimes called session hijacking .

Web applications typically use two types of security tokens: cookies and customized session identifiers (session ID). We'll discuss common mechanisms for guessing or obtaining cookies and session IDs briefly in this section. For more information on attacks against authorization and session state, please consult Chapter 5.

Session ID Attacks

 Attack    Two basic techniques to obtain session IDs are prediction and brute-forcing.

In the past, we have seen many web sites fall by using predictable, sometimes sequential, session identifiers. Many mathematical techniques such as statistical forecasting can be used to predict session identifiers. All of the major application servers that now use unpredictable session identifiers and applications built on top of these frameworks are unlikely to be susceptible to this attack.

Brute-forcing session IDs involves making thousands of requests using all possible session IDs, in hopes of guessing one correctly. The number of requests that need to be made depends on the key space of session ID. Thus, the probability of success of this type of attack can be calculated based on the size and key space of the session ID.

Tip 

David Endler of iDefense.com has written a detailed expos of many of the weaknesses in session ID implementations . Find a link to it in the "References and Further Reading" section at the end of this chapter.

Hacking Cookies

 Attack    Cookies commonly contain sensitive data associated with authentication. If the cookie contains passwords or session identifiers, stealing the cookie can be a very successful attack against a web site. There are several common techniques used to steal cookies, with the most popular being script injection and eavesdropping. We'll discuss script injection techniques (also referred to as cross-site scripting ) in Chapter 6.

Reverse engineering the cookie offline can also prove to be a very lucrative attack. The best approach is to gather a sample of cookies with different input to see how the cookie changes. This can be done by using different accounts to log in at different times. The idea is to see how the cookie changes based on time, username, access privileges, and so on. Bit-flipping attacks adopt the brute-force approach, methodically modifying bits to see if the cookie is still valid and whether different access is gained . We'll go into more detail on cookie attacks in Chapter 5.

Countermeasures to Token Replay Attacks

 Countermeasure    Eavesdropping is the easiest way to steal security tokens like cookies. Use SSL or other appropriate session confidentiality technology to protect against eavesdropping.

In addition to on-the wire eavesdropping, be aware that there are a slew of security issues with commonly used web clients that also may expose your security tokens to malicious client-side malware or cross-site scripting manipulation (see Chapter 10 for more on this).

In general, the best approach is to use a session identifier provided by the application server. However, if you need to build your own, you should also design a token that can't be predicted and can't be attacked using brute-force methods . For example, use a random number generator to generate session identifiers. In addition, to prevent brute-force attacks, use a session identifier with a large enough key space ( roughly 128 bits with current technology) that it can't be attacked using brute force. Keep in mind there are subtleties with pseudo-random number generators that you must consider when using them. For example, using four sequential numbers for a pseudo-random number generator that generates 32-bit samples and concatenating them to create one 128-bit session identifier is insecure . By providing four samples to prevent brute-force attacks, you actually make session ID prediction easier.

You should also implement integrity checks across security tokens like cookies and session IDs to protect against tampering in transit and offline analysis.

In general, having sensitive data in a security token is not recommended, even if you implement strong confidentiality and integrity-protection mechanisms. Remember the elegance of challenge-response authentication techniques that use a nonce modified by secrets to obtain the same results as sending the secrets themselves over the wire.

Identity Management

A functional authentication system needs to have some way of managing identitiesregistration, account management (such as password reset), and so on. These activities also need to be performed securely, since errors can impact very sensitive information like credentials. Unfortunately, identity management can be a complex task, and many web applications don't perform it very well, leaving their authentication system exposed via the back door.

In this section, we'll talk about common attacks against identity management.

Note 

Some web sites seek to avoid the headache of identity management entirely by outsourcing it to a third party. Microsoft's Passport is an example of such a service for the Websee our previous discussion of Passport for more information.

User Registration Attacks

 Attack    Sometimes, the easiest way to access a web application is to simply create a valid account on the system using the registration system. This essentially bypasses attacks against the authentication interface by focusing on the registration process. Of course, filtering account registrations for malicious intent is a challenging proposition, but web applications have developed a number of mechanisms to mitigate against such activity, including CAPTCHA (Completely Automated Public Turing Tests to Tell Computers and Humans Apart). CAPTCHAs are often used in web-based applications when the application owner wants to prevent a program, bot, or script from performing a certain action. Some examples of CAPTCHA include these:

• Free E-mail Services Many free e-mail services use CAPTCHA to prevent programs from creating fake accounts, generally to minimize spam.

• Prevent Password-guessing Attacks CAPTCHA has been used in login pages to prevent tools and programs to perform the password-guessing attacks.

• Prevent Search Engine Bots CAPTCHA are sometimes used to prevent search engine bots from indexing pages.

• Online Polls CAPTCHA can be an effective way to prevent people to skew results of online polls by ensuring that a program is not responding to the polls.

CAPTCHA is a type of HIP (Human Interactive Proof) that is used to determine if the entity on the other side is a human or a computer. This is formally referred to as a Reverse Turing Test (RTT). The difference with CAPTCHA is that it is "completely automated," which makes it suitable for use in web applications.

Common types of CAPTCHA are often based on text recognition or image recognition. The following images illustrate common implementations of CAPTHCAs.

The following shows the gimpy-r CAPTCHA, which is considered ineffective since automated routines can beat it regularly:

Next shown is a CAPTCHA used to challenge Hotmail.com registrations. Note the audio CAPTCHA option button in the upper right:

Next is a graphical CAPTCHA from CAPTCHA.net:

Recent advances and research in computer vision and image recognition has provided the groundwork for breaking CAPTCHA. Simple CAPTCHAs like the EZ-Gimpy technology using text recognition has been broken by Greg Mori and Jitendra Malik, researchers at the University of California at Berkeley. Gabriel Moy, Nathan Jones, Curt Harkless, and Randy Potter of Aret Associates have created a program that has broken the more complex Gimpy-r algorithm 78 percent of the time.

As of this writing, the PWNtcha is the most successful of the CAPTCHA decoders. It has over an 80 percent success rate at breaking well-known CAPTCHAs used by popular web sites such as PayPal and Slashdot. Although the code is not released, you can upload a CAPTCHA to the web site for decoding. Figure 4-8 shows an example of using PWNtcha. Although it is not generally available as a binary, you can upload images to their web site.

Figure 4-8: PWNtcha successfully identifying the type of CAPTCHA and the text in the image

Although most researchers have not released programs that break CAPTCHA, the hackers are not far behind the researchers. The authors have worked with several companies that have been victims of hackers creating bots that automatically register accounts. Their response was to use a CAPTCHA. However, within a week, the hackers were able break the CAPTCHA, probably adapting a program they already had in their arsenal. The advances in computer vision and processing power has required more complex CAPTCHAs to be developed to be effective.

Credential Management Attacks

 Attack    Another way to bypass authentication is to attack credential management subsystems. For example, most web sites implement common mechanisms for password recovery, such as self-help applications that e-mail new passwords to a fixed e-mail address, or if a "secret question" can be answered (for example, "What is your favorite pet's name ?" or "What high school did you attend ?").

We've found in our consulting that many of these so-called "secret questions" are easily guessable and often not considered a "secret". For example, we once stumbled on a secret question designed to elicit the user's customer ID and ZIP code in order to recover a password, where the customer ID was sequential and the ZIP code was easily guessed using a dictionary of common ZIP codes or via brute-force mechanisms.

Another classic attack against password reset mechanisms is getting self-help password reset applications to e-mail password reset information to inappropriate e-mail addresses. Even the big guys fall to this one, as the incident in May of 2003 with Microsoft's Passport Internet authentication services showed (we discussed this briefly earlier in this chapter in the section on Passport). Passport's self-help password reset application involved a multistep process to e-mail the user a URL that permitted them to change their password. The URL in the e-mail looked something like the following (manual line breaks have been added due to page width constraints):

 https://register.passport.net/emailpwdreset.srf?em=[e-mail]& prefem=[e-mail]&rst=1 

Although the query string variables here are a bit cryptic, the "emailpwdreset" application in this example will send a password reset URL for the "[e-mail]" account to the e-mail address [e-mail]. Subsequently, "attacker" will be able to reset the password for "victim," thus compromising the account.

Client-Side Piggybacking

We've spent most of our effort in this chapter describing ways to steal or otherwise guess user credentials to be used by the attacker. What if the attacker simply lets the user do all of the heavy lifting by piggybacking on a legitimately authenticated session? This is perhaps the easiest way to bypass nearly all of the authentication mechanisms we've described so far, and it takes surprisingly little effort. Earlier in this chapter we cited an essay by Bruce Schneier on this very point, in which he notes that man-in-the-middle attacks and malicious software installed on end-user machines can effectively bypass almost any form of remote network authentication (you can find a link to his essay in the "References and Further Reading" section in this chapter). We'll describe some of these methods in detail in Chapter 11, but we thought it important to make this point before we closed out this chapter.