Tải bản đầy đủ - 0trang
8 Brute-Force Guessing Usernames and Passwords
involves brute-force guessing to find a list of valid usernames and then attempting to
The goal is to test whether an attacker can obtain some valid usernames in the application and whether he can continually guess passwords until he gets one right. Attempt
the following to determine whether the application intentionally or unintentionally
• Attempt to log in with a username that does not exist. Then, attempt to log in with
a username that does exist, but enter an incorrect password. If the application’s
response in the two cases is different, then the attacker can enumerate usernames
in the system.
• If the application implements password reset functionality for users that forget
their passwords, determine how the password reset functionality works. Does it
require the user to enter a username? If so, determine whether the application
responds differently depending on whether a valid or invalid username is entered.
• Some applications contain functionality to allow users to sign up for accounts
themselves. Since usernames need to be unique, the application will indicate to the
end user whether the username that she is trying to sign up for already exists. This
functionality could be exploited by an attacker to enumerate usernames. Determine whether the application contains such functionality.
If in any of these tests the application allows the attacker to determine valid usernames,
the application fails this part of the test. This may or may not be of interest in your
particular application. However, if the next test fails, then the failure will definitely be
The next step is determining whether the application allows brute-forcing passwords.
Even if the attacker cannot conclusively get a valid list of usernames, he could still
attempt to brute-force passwords for common usernames that may or may not be valid
in the application (e.g., jsmith). Attempt one of the following depending on your
• If there is a requirement concerning account lockout functionality, test it by entering an incorrect password for a valid username several times (as dictated by the
requirement) and determine whether the account is locked out by entering the
same username with the corresponding valid password. Also, if the account is
locked out, determine whether the application provides the same response regardless of whether the entered password is correct. If after account lockout it provides
different responses depending on whether the password is correct or not, the attacker can still brute-force the password. However, he will not be able to actually
log in until the account is unlocked.
12.8 Brute-Force Guessing Usernames and Passwords | 249
• If there is no requirement concerning account lockout functionality, determine
whether account lockouts are enforced by entering an incorrect password for a
valid user account a number of times (10 to 15 times should be sufficient). Then,
enter the valid password and see if the account is locked out. As in the previous
test, even if the account is locked out, determine whether the application’s response
is different depending on whether the entered password is correct or not.
The application fails this test if it either does not enforce account lockout functionality,
or locks out accounts and then provides different responses depending on whether the
entered password is correct or not.
Usernames and passwords are frequently brute-forceable even in the presence of account lockout functionality or other mitigating measures. Applications often try to be
helpful and provide different error messages to users depending on whether the supplied username is incorrect or the supplied password is incorrect. This is often true
even after an account gets locked out. The authors have seen an application that displayed error messages similar to the following. If the username was incorrect, the application stated that “The username or password is incorrect”; if the password was
incorrect, the user would get the message “The user could not be authenticated”; if the
account was locked out and the password was correct, the user would get a message
stating “Your account has been locked out.” This provides an easy way to brute-force
usernames and passwords.
In the earlier example, an attacker could enumerate usernames by entering different
values and recording whether the application stated that “The username or password
is incorrect” or “The user could not be authenticated.” The attacker could then bruteforce the password by waiting to either get logged in or get the message “Your account
has been locked out.” Even if the attacker locks out an account while brute-forcing, he
will just need to wait until the account is unlocked before accessing it. Many applications unlock accounts automatically after a predetermined amount of time.
Note that it is typically easy for attackers to guess at least a small number of usernames
and passwords in most systems. This is because usernames tend to be predictable, and
many users tend to choose very weak passwords.
Guessing Usernames and Passwords
There are several ways in which an attacker could get valid usernames depending on
the application. Many systems contain usernames that are essentially public or that can
be easily obtained (e.g., performing a Google search for “gmail.com” reveals a large
number of valid Google user accounts). In other cases, the application may leak information during log in, password reset, or account signup.
An attacker can guess usernames by getting a list of common names and then generating
usernames from them. In the United States, the Census Bureau publishes lists of the
250 | Chapter 12: Multifaceted Tests
most common first and last names. According to the results from the 1990 Census,
jsmith and msmith are probably the most common usernames since Smith was the most
popular last name, James and John were the most popular first names for males, and
Mary was the most popular first name for females.†
Additionally, studies have shown that a significant number of users choose common
weak passwords such as “123,” “password,” “qwerty,” “letmein,” “monkey,” and their
own first names.‡ This chapter’s author worked for a large company where the IT staff
discovered that a significant percentage of users chose “1234” as their Windows domain password. In fact, it was the most popular password being used.
12.9 Attempting PHP Include File Injection Interactively
When PHP Hypertext Processor is used as a server-side scripting engine, an attacker
can carry out several types of attacks if the application developer is not careful. One
particularly dangerous attack is PHP Include file injection where the attacker can cause
the web server to download and run arbitrary code. This test will try to determine
whether your application written in PHP will download arbitrary code specified by the
attacker and execute it.
First, determine whether PHP is being used by the application. One indicator is URLs
that reference resources with the extensions php, php3, and php4, for example: http://
www.example.com/home.php?display=5. If it is not clear whether PHP is being used by
the application, you will need to ask the development team.
Set up a web server somewhere as described in Recipe 2.14. Then, inject the code shown
in Example 12-15 as GET and POST parameter values, as well as for HTTP cookie
Example 12-15. Test input for finding PHP include file injection vulnerability
Of course, host is the hostname or IP address of the web server you set up and port is
the port number on which the web server is listening. Then, search the access logs and
error logs at host for the string xyzzy_php_test. If the string is in the logs, then the page
being tested is trying to retrieve the file from your web server and is vulnerable to PHP
‡ One site containing detailed analysis of passwords gathered using a phishing exploit is http://www
12.9 Attempting PHP Include File Injection Interactively | 251
This attack works because the PHP include() and require() functions can read files
from the local filesystem as well as from a remote location. If some PHP code in the
application takes a variable input by the user and then passes it to include() or
require() functions as in the following code, then the user can manipulate the variable
in ways that the developer did not intend. Example 12-16 shows a line of PHP that
would be vulnerable to this attack if the $userInput variable is not carefully sanitized
before the require() function is called.
Example 12-16. Sample line of code vulnerable to PHP include file injection
require($userInput . '.php')
The developer may have tried to restrict $userInput by using radio buttons in an HTTP
page, for example, but you can of course bypass client-side controls and provide any
value you like. Thus, if the attacker provides the string in the section called “Solution” as the variable $userInput, then the code will attempt to fetch the file http://
host:port/xyzzy_php_test.php and will execute the PHP code in the retrieved file.
Note that PHP code may retrieve values of GET or POST variables or even HTTP cookie
values and use them in the manner discussed earlier. Modifying GET values can be
accomplished simply by modifying the URL. Modifying POST variables is discussed in
Recipe 3.4. Modifying HTTP cookie values is discussed in Recipe 5.6.
There are many other types of PHP injection attacks, but they are less common, and
are not discussed here. A Google search for “PHP injection” will reveal the other types
of PHP injection attacks.
12.10 Creating Decompression Bombs
A decompression bomb is a compressed file that is very small but expands to a disproportionately large amount of data. An example was discussed in Recipe 5.12. This
recipe will discuss how such decompression bombs can be created. If your application
processes compressed files (.zip, .jar, .tar.gz, .tar.bz2, etc.), you can use this recipe
to generate pathological compressed files that can be used to ensure that your application handles such malicious input gracefully.
The program in Example 12-17 will generate a zip of death similar to the one discussed
in Recipe 5.12. You can substitute other compression utilities instead of zip to create
other types of decompression bombs (e.g., bzip2).
252 | Chapter 12: Multifaceted Tests