Tải bản đầy đủ - 0 (trang)
8  Brute-Force Guessing Usernames and Passwords

8  Brute-Force Guessing Usernames and Passwords

Tải bản đầy đủ - 0trang

involves brute-force guessing to find a list of valid usernames and then attempting to

brute-force passwords.



Solution

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

reveals usernames:

• 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

of interest.

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

circumstances:

• 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.



Discussion

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

Problem

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.



Solution

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

values.

Example 12-15. Test input for finding PHP include file injection vulnerability

http://host:port/xyzzy_php_test



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

injection.

† http://www.census.gov/genealogy/www/

‡ One site containing detailed analysis of passwords gathered using a phishing exploit is http://www



.schneier.com/blog/archives/2006/12/realworld_passw.html.



12.9 Attempting PHP Include File Injection Interactively | 251



Discussion

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

Problem

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.



Solution

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



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

8  Brute-Force Guessing Usernames and Passwords

Tải bản đầy đủ ngay(0 tr)

×
x