This chapter is from the book
This chapter is from the book
This chapter is from the book
Authentication
The Authentication section covers attacks that target a web site’s method of validating the identity of a user, service, or application. Authentication is performed using at least one of three mechanisms: "something you have," "something you know," or "something you are." This section will discuss the attacks used to circumvent or exploit the authentication process of a web site.
Brute Force
A Brute Force attack is an automated process of trial and error used to guess a person’s username, password, credit-card number, or cryptographic key.
Many systems will allow the use of weak passwords or cryptographic keys, and users will often choose easy-to-guess passwords, possibly found in a dictionary. Given this scenario, an attacker would cycle though the dictionary word by word, generating thousands or potentially millions of incorrect guesses searching for the valid password. When a guessed password allows access to the system, the Brute Force attack has been successful and the attacker is able access the account.
The same trial-and-error technique is also applicable to guessing encryption keys. When a web site uses a weak or small key size, it’s possible for an attacker to guess a correct key by testing all possible keys.
Essentially, there are two types of Brute Force attacks: normal Brute Force and reverse Brute Force. A normal Brute Force attack uses a single username against many passwords. A reverse Brute Force attack uses many usernames against one password. In systems with millions of user accounts, the odds of multiple users having the same password dramatically increase. While Brute Force techniques are highly popular and often successful, they can take hours, weeks, or years to complete.
Brute Force Example
Username = Jon
Passwords = smith, michael-jordan, [pet names], [birthdays], [car names],
Usernames = Jon, Dan, Ed, Sara, Barbara, .....
Password = 12345678
Apache Countermeasures for Brute Force Attacks
There are a few different approaches that we can take to mitigate the effectiveness of Brute Force attacks against authentication used by our Apache server. We need to break down the different factors that influence the effectiveness of a Brute Force attack.
Weak Passwords
The bane of most every multi-user system’s security is the fact that users will invariably choose weak passwords, as they are easier to remember. In order to help prevent a successful Brute Force attack, you must enforce a strong password policy. All passwords should have the following characteristics:
- At least six characters in length.
- Do not contain the username string.
- Contain at least one numeric digit (0–9).
- Contain at least one special character.
- Forced to change every 90–120 days.
- Forced not to repeat a previous password.
Unfortunately, Apache does not have a direct means to enforce this type of password complexity with its default password management tools: htpasswd and htdigest. In order to gain more robust password security capabilities, you should implement one of the many third-party authentication modules available for Apache at the Apache Module Registry site: http://modules.apache.org/search. A module such as Mod_SecurID (http://www.denyall.com/mod_securid/) can implement a strong two-factor authentication component to help thwart Brute Force attacks. With two-factor authentication, the user supplies something they know (such as a password or PIN) and then they utilize something they have (in this case, a hardware device that generates a new random number string every 60 seconds). In order to gain access to a two-factor authentication system, the attacker would need to have physical access to the RSA SecurID FOB hardware token.
Suppress Verbose Error Messages
When an invalid username/password combination is submitted, do not inform the user which piece of information (either the username or password) was invalid. This may lend an attacker the ability to determine which accounts on the system exist. We will discuss this concept further in Chapter 8 when we are securing the Buggy Bank application, as it has this same vulnerability. We can leverage the output filtering capabilities of Apache 2.0 to alter/remove this type of information from web pages that are generated by an authentication program.
Creating Authentication Failure Awareness
When Apache is being used as a reverse proxy front-end for an application that is authenticating users, it is difficult for Apache to be "aware" that an authentication failure has actually taken place. This is a result of the nature of the different authentication transactions. The easiest authentication mechanisms for Apache to recognize are when Basic or Digest Authentication is being utilized. With these two mechanisms, the client submits an additional Authorization client header containing their credentials. If the credentials are incorrect, a 401 Unauthorized status code is generated. If you configured Apache to utilize CGI script for this status code, then you can potentially be alerted when a client fails authentication. We will discuss the concepts and techniques of using custom 401 and 403 CGI error scripts to monitor and track failed requests in a later chapter.
When a form-based authentication mechanism is used, it becomes a bit trickier to identify login failures, as the HTTP response status code is no longer an indicator of the success or failure of the login attempt. As long as Apache is able to successfully serve the desired page, it will generate a 200 OK status code. The authentication failure information will therefore have to be identified by different means. Here are two possibilities:
- Error message in html. As mentioned in the previous section on suppressing specific error messages, attackers will try and inspect the returned error messages, looking for any signs of information disclosure. You should work with your web developers to make sure that they update their error messages to contain benign information that will not be useful to the attacker. Although this information may not be leveraged by the attacker, it will be useful to Apache for identifying authentication failures. Let's say, for instance, that your authentication failure web page contains the following text: "Sorry, you did not supply the correct username or password." With this information, we can create a Mod_Security filter to identify this data in the output stream returned to the client. Here is an example filter:
<;Location /path/to/login> SecFilterSelective OUTPUT "you did not supply the correct username or password" status:401 </Location>
This new filter will identify the failure message being served to the client and trigger a 401 status code.
SecFilterSelective THE_REQUEST "/path/to/failure_webpage" status:401
Anti-Brute Force Code
Apache doesn’t natively have any capability to track failed login attempts for specific user accounts. The best way to track that, outside of updating the application’s code, is to use the 401 CGI scripts to send emails to security personnel. In this scenario, the recipient of the email will have to apply some analysis to identify Brute Force attacks against specific accounts. The best way to identify and react to an automated Brute Force attack against your site is to use Mod_Dosevasive. We touched on the high-level concepts of the module in Chapter 5, "Essential Security Modules for Apache;" however, now it is time to get into more detail and practical tips.
Mod_Dosevasive works equally well whether it is facing an application layer DoS attack or a brute force attack against one or more accounts. This is due to the similarity of request characteristics from the web server’s perspective when these two attacks are executed. They both have a mapping of a remote IP address connecting to a certain URL. In the case of a brute force attack, the URL just happens to have access controls implemented that require authentication. Mod_Dosevasive is not aware of this authentication, but is still effective in identifying this as an automated attack due to the velocity of requests received in the time interval observed.
When Mod_Dosevasive identifies an attack, it will deny (blackhole) the offending IP address for the time period specified in the DOSBlockingPeriod directive. This method has its uses; however, IP address restrictions must also be used with caution. Blocking a NATed proxy IP Address may prevent a large portion of legitimate user traffic as well. The main problem here is that only using the client IP address and URI as associations causes false positives. In order to better identify unique clients who may be connecting behind a proxy server, we can include the "User-Agent" information to the hash token. This creates a hash token of – Remote IP_User-Agent->URI. This extra variable will help us to avoid denying innocent clients. Here is a small snippet of the source code from before the update:
/* Has URI been hit too much? */
snprintf(hash_key, 2048, "%s_%s", r->connection->remote_ip, r->uri);
n = ntt_find(hit_list, hash_key);
if (n != NULL) {
Here is the updated code:
/* Has URI been hit too much? */ snprintf(hash_key, 2048, " %s_%s", apr_pstrcat(r->pool, r->connection->remote_ip, "_",
apr_table_get(r->headers_in, "user-agent"), NULL), r->uri); n = ntt_find(hit_list, hash_key); if (n != NULL) {
While this concept does provide some level of protection from denying legitimate clients who happen to be behind a proxy, it does open up one more issue. What if an attacker were to update their DoS attack script to use rotating User-Agent fields? Sound too far fetched? Well, it isn’t. In Chapter 10, "Open Web Proxy Honeypot," I present concrete evidence of an attacker using this same strategy when using my Apache Open Proxy Honeypot. So, how do we combat this? I spoke with the Mod_Dosevasive creator, and the consensus was to implement code that will set a threshold on the total number of different User-Agent fields allowed per IP Address in the timeframe specified. This will catch attackers who are using rotating/spoofed User-Agent fields. By the time this book comes out, the updated code we have discussed here should be available either from the Mod_Dosevasive web site or from my personnel site: http://honeypots.sf.net.
References
"Brute Force Attack," Imperva Glossary http://www.imperva.com/application_defense_center/glossary/brute_force.html
"iDefense: Brute-Force Exploitation of Web Application Session ID’s" By David Endler—iDEFENSE Labs http://www.cgisecurity.com/lib/SessionIDs.pdf
Insufficient Authentication
Insufficient Authentication occurs when a web site permits an attacker to access sensitive content or functionality without having to properly authenticate. Web-based administration tools are a good example of web sites providing access to sensitive functionality. Depending on the specific online resource, these web applications should not be directly accessible without having the user required to properly verify their identity.
To get around setting up authentication, some resources are protected by "hiding" the specific location and not linking the location into the main web site or other public places. However, this approach is nothing more than "Security Through Obscurity." It’s important to understand that simply because a resource is unknown to an attacker, it still remains accessible directly through a specific URL. The specific URL could be discovered through a Brute Force probing for common file and directory locations (/admin, for example), error messages, referrer logs, or perhaps documented in help files. These resources, whether they are content or functionality driven, should be adequately protected.
Insufficient Authentication Example
Many web applications have been designed with administrative functionality location directory off the root directory (/admin/). This directory is usually never linked to anywhere on the web site, but can still be accessed using a standard web browser. Because the user or developer never expected anyone to view this page since it’s not linked, adding authentication is often overlooked. If an attacker were to simply visit this page, he would obtain complete administrative access to the web site.
Apache Countermeasures for Insufficient Authentication
Relying on "Security by Obscurity" is a recipe for disaster. I much prefer "Security with Obscurity." This means that it is a reasonable step to not publicly link to these administration functions of your web site; however, this should not be the only means of security that you apply. As discussed in Chapter 4, "Configuring the httpd.conf File," we can implement both host-based and user-based access control to these URLs. Using the (/admin/) directory from the example, we can implement appropriate access control with the following directives in the httpd.conf file:
<LocationMatch "^/admin/"> SSLRequireSSL AuthType Digest AuthName "Admin Area" AuthDigestfile /usr/local/apache/conf/passwd_digest Require user admin </LocationMatch>
This directive container for the "/admin/" location will force the following:
- The connection must be over SSL.
- Uses Digest Authentication.
- The username "admin" and the correct password must be supplied.
Weak Password Recovery Validation
Weak Password Recovery Validation is when a web site permits an attacker to illegally obtain, change, or recover another user’s password. Conventional web site authentication methods require users to select and remember a password or passphrase. The user should be the only person who knows the password, and it must be remembered precisely. As time passes, a user’s ability to remember a password fades. The matter is further complicated when the average user visits 20 sites requiring them to supply a password (RSA Survey: http://news.bbc.co.uk/1/hi/technology/3639679.stm). Thus, Password Recovery is an important part in servicing online users.
Examples of automated password recovery processes include requiring the user to answer a "secret question" defined as part of the user registration process. This question can either be selected from a list of canned questions or supplied by the user. Another mechanism in use is having the user provide a "hint" during registration that will help the user remember his password. Other mechanisms require the user to provide several pieces of personal data such as his social security number, home address, zip code, and so on. to validate their identity. After the user has proven who they are, the recovery system will display or email them a new password.
A web site is considered to have Weak Password Recovery Validation when an attacker is able to foil the recovery mechanism being used. This happens when the information required to validate a user’s identity for recovery is either easily guessed or can be circumvented. Password recovery systems may be compromised through the use of Brute Force attacks, inherent system weaknesses, or easily guessed secret questions.
Weak Password Recovery Validation Examples
Information Verification
Many web sites only require the user to provide their email address in combination with their home address and telephone number. This information can be easily obtained from any number of online white pages. As a result, the verification information is not very secret. Further, the information can be compromised via other methods such as cross-site scripting and phishing scams.
Password Hints
A web site using hints to help remind the user of their password can be attacked because the hint aids Brute Force attacks. A user may have fairly good password of "122277King" with a corresponding password hint of "bday+fav author". An attacker can glean from this hint that the user’s password is a combination of the user’s birthday and the user’s favorite author. This helps narrow the dictionary Brute Force attack against the password significantly.
Secret Question and Answer
A user’s password could be "Richmond" with a secret question of "Where were you born." An attacker could then limit a secret answer Brute Force attack to city names. Furthermore, if the attacker knows a little about the target user, learning their birthplace is also an easy task.
Apache Countermeasures for Weak Password Recovery Validation
Solving Weak Password Recovery is not as simple as it would seem. Apache has a tough time handling this type of issue as it is more related to the application logic rather than HTTP transactions. Even though Apache would have a difficult time with this, it is still capable of detecting certain brute force attack characteristics associated with circumventing the secret question and answer restrictions listed in the following sections.
Secret Question and Answer
Some web sites have limited access to a user’s personal data for verification. These sites should implement a set of recovery functions at registration, such as having the user correctly answer several secret questions. The secret questions themselves should be subjective in nature. Having a relatively large list of potential questions increases the protection against Brute Force attack and lucky guessing. Choosing good questions is difficult, but is probably the most important part of the system described previously. It is possible to generate questions that should apply to nearly everyone. For example:
- First company I worked for and the position I held.
- First car I owned (make and model).
- My favorite college professor.
- First city I flew to.
It is also possible for users to generate questions or prompts personally tailored, although this procedure can add complexity to the system as it must now remember both the question and the corresponding answer. Further, users may find it hard to come up with several personal unique questions to ask themselves. Taking this difficulty aside, having the option for custom questions enhances the security of the system by further impeding the attacker.
If an attacker were to launch a Brute Force attack against this type of interface, Apache could be configured as described in the previous Brute Force section, which triggered on specific text in the returned html page and/or the client being sent to a certain URL upon failure. In these cases, an administrator should be altered to this activity.
References
"Protecting Secret Keys with Personal Entropy" By Carl Ellison, C. Hall, R. Milbert, and B. Schneier http://www.schneier.com/paper-personal-entropy.html
"Emergency Key Recovery Without Third Parties" By Carl Ellison http://theworld.com/~cme/html/rump96.html