Difference between revisions of "Testing for User Enumeration and Guessable User Account (OWASP-AT-002)"

From OWASP
Jump to: navigation, search
m
 
(37 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v3}}
+
{{Template:OWASP Testing Guide v4}}
  
  
 
== Brief Summary ==
 
== Brief Summary ==
The scope of this test is to verify if is possible to collect a set of valid users interacting with the authentication mechanism of the application. This test will be usefull for the brute force testing in which we verify if given a valid username it is possible to find a valid password.  
+
The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password.  
Often the web applications are not properly configured, or we have an application that will reveal when a username already exists on system. In fact, sometimes when we submit wrong credentials to application, we receive a message that username is present on the system, or password is wrong. In other case we receive a defined error message that can be reveal if username is present on system or not.
+
Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong.
The information obtained can be used, by attacker, to gain a list of users on system that can be used to attack the web application, for example through a brute force or default username/password.
+
The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.
 
<br>
 
<br>
 +
 
== Description of the Issue ==  
 
== Description of the Issue ==  
The tester should interact with the authentication mechanism of the application to understand if sending particular request the application answer in a different manner. In some case we can receive a message that reveal if the wrong credential is for an invalid username or invalid password. Sometimes we can enumerate the users sending a username without send any password.  
+
The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the information released from web application or web server when we provide a valid username is different than when we use an invalid one.
<br>
+
 
 +
In some cases, we receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.
 +
 
 
== Black Box testing and example ==
 
== Black Box testing and example ==
In a black box testing we know nothing about specific application, username, application logic and error messages on login page or password recovery facilities.
+
In a black box testing, we know nothing about the specific application, username, application logic, error messages on login page, or password recovery facilities.
If the applications is vulnerable we receive a response message that reveal directly or indirectly the some information for enumerating users.  
+
If the application is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.  
<br>
+
 
 +
 
 +
===HTTP Response message===
 +
 
 
'''Testing for Valid user/right password'''  
 
'''Testing for Valid user/right password'''  
<br>
+
 
Record the server answer when you submit valid username and valid password.
+
Record the server answer when you submit a valid userID and valid password.
<br>
+
 
'''Result Expected:'''<br>
+
'''Result Expected:'''
Using WebScarab notice the information retrieved from this successful authentication (HTTP 200 Response, lenght of the response).
+
 
<br>
+
Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).
'''Testing for Valid user/wrong password''' <br>
+
 
Now, the tester should try to insert a valid username and a wrong password and record the error message server answer.
+
 
<br>
+
'''Testing for valid user/wrong password''' <br>
 +
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.
 +
 
 
'''Result Expected:'''<br>
 
'''Result Expected:'''<br>
From the browser we will expect the following messsage:<br>
+
From the browser we will expect message similar to the following one:<br>
 
[[Image:AuthenticationFailed.png]]<br>
 
[[Image:AuthenticationFailed.png]]<br>
Using WebScarab notice the information retrieved from this not successful authentication (HTTP 200 Response, lenght of the response).
 
<br>
 
'''Testing for a not existing username''' <br>
 
Now, the tester should try to insert a not valid username and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.
 
  
'''Result Expected:'''<br>
+
or something like:<br>
If we enter a Not Existing Username we can receive a message similar to:<br>
+
[[Image:NoConfFound.jpg]]<br>
 +
 
 +
against any message that reveals the existence of user, for instance, message similar to:<br>
 +
Login for User foo: invalid password
 +
 
 +
Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).
 +
 
 +
 
 +
'''Testing for a nonexistent username'''
 +
 
 +
Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.
 +
 
 +
'''Result Expected:'''
 +
 
 +
If we enter a nonexistent userID, we can receive a message similar to:<br>
 
[[Image:Userisnotactive.png]]<br>
 
[[Image:Userisnotactive.png]]<br>
or message such as : "Login failed for User foo: invalid Account"<br>
+
or message like the following one:<br>
The application should response with the same error message and lenght to the different wrong requests.
+
Login failed for User foo: invalid Account
If you notice that the answer are not the same, you should investigate and find out the key that create a difference between the 2 requests. For example:
+
 
 +
Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the two responses. For example:  
 
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
 
* Client request: Valid user/wrong password --> Server answer:'The password is not correct'
* Client request: Wrong user/wrong password --> Server answer:'User not regnognized'
+
* Client request: Wrong user/wrong password --> Server answer:'User not recognized'
The above answers let the client to understand that for the first request we hold a valid user name. So we can interact with the application requesting a set of possible username and observing the answer.<br>
+
The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer.
Looking at the second server answer, we understand in the same way that we don't hold a valid user name. So we can interact in the same manner and create a list of valid username looking at the server answers.
+
 
 +
Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.
 +
 
 +
===Other ways to enumerate users===
 +
 
 +
We can enumerate users in several ways, such as: <br>
 +
'''- Analyzing the error code received on login pages'''<br>
 +
Some web application release a specific error code or message that we can analyze.
 +
 
 +
'''- Analyzing URLs, and URLs redirections'''<br>
 +
For example:<br>
 +
http://www.foo.com/err.jsp?User=baduser&Error=0<br>
 +
http://www.foo.com/err.jsp?User=gooduser&Error=2
 +
 
 +
As we can see above, when we provide a userID and password to the web application, we see a message indication that an error has occurred in the URL.
 +
In the first case we has provided a bad userID and bad password. In the second, a good user and bad password, so we can identify a valid userID.
 +
 
 +
'''- URI Probing'''<br>
 +
Sometimes a web server responds differently if it receives a request for an existing directory or not. For instance in some portals every user is associated with a directory. If we try to access an existing directory we could receive a web server error.
 +
A very common error that we can receive from web server is:<br>
 +
  403 Forbidden error code
 +
and <br>
 +
  404 Not found error code
 
<br>
 
<br>
 +
Example<br>
 +
http://www.foo.com/account1 - we receive from web server: 403 Forbidden
 +
http://www.foo.com/account2 - we receive from web server: 404 file Not Found
  
'''Others user enumeration tests''' <br>
 
We can enumerate users in other several ways, such as:
 
- Analyzing the error code received on login pages, or recovery facilities
 
- Analyzing URLs, and URLs redirections
 
- Analyzing Web page Title
 
  
In some case, for example, we can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
+
In first case the user exists, but we cannot view the web page, in second case instead the user “account2” doesn’t exist.
 +
Collecting this information we can enumerate the users.
  
Pay attention
+
 
The problems with user enumerating is the risk of locking out accounts after a predefined numbers of probe (based on application policy), or sometimes our IP address can be filtered by a dynamic rules on firewall.  
+
'''- Analyzing Web page Titles'''<br>
 +
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password.
 +
For instance, if we cannot authenticate to an application and receive a web page whose title is similar to:
 +
Invalid user
 +
Invalid authentication
 +
 
 +
 
 +
'''- Analyzing message received from recovery facility'''<br>
 +
When we use a recovery facility (i.e. a Forgotten Password function) a vulnerable application might return a message that reveals if a username exists or not.
 +
 
 +
For example, message similar to the following:<br>
 +
Invalid username: e-mail address is not valid or the specified user was not found.
 +
 
 +
Valid username: Your password has been successfully sent to the email address you registered with.
 +
<br>
 +
 
 +
 
 +
'''- Friendly 404 Error Message'''<br>
 +
When we request for a user within the directory that does not exist, we don't always receive 404 error code. Instead, we may receive “200 ok” with an image, in this case we can assume that when we receive the specific image the user doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.
 +
<br>
 +
<br>
 +
===Guessing Users===
 +
In some cases the userIDs are created with specific policies of administrator or company. 
 +
For example we can view a user with a userID created in sequential order:<br>
 +
CN000100<br>
 +
CN000101<br>
 +
…. <br>
 +
Sometimes the usernames are created with a REALM alias and then a sequential numbers:<br>
 +
R1001 – user 001 for REALM1<br>
 +
R2001 – user 001 for REALM2<br>
 +
<br>
 +
In the above sample we can create simple shell scripts that compose UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs.
 +
To create a script we can also use Perl and CURL.
 +
 
 +
Other possibilities are:
 +
- userIDs associated with credit card numbers, or in general numbers with a pattern.
 +
- userIDs associated with real names, e.g. if Freddie Mercury has a userID of "fmercury", then you might guess Roger Taylor to have the userID of "rtaylor".
 +
 
 +
Again, we can guess a username from the information received from an LDAP query or from Google information gathering, for example, from a specific domain.
 +
Google can help to find domain users through specific queries or through a simple shell script or tool.
 +
 
 +
 
 +
 
 +
<br><br>
 +
'''Attention:''' by enumerating user accounts, you risk locking out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, your IP address can be banned by dynamic rules on the application firewall or Intrusion Prevention System.
  
 
== Gray Box testing and example ==  
 
== Gray Box testing and example ==  
 
'''Testing for Authentication error messages'''<br>
 
'''Testing for Authentication error messages'''<br>
Verify that the application answer in the same manner for every client request of authentication that produce a fail authentication. For this issue the Black Box testing and  Gray Box testing are the same concept based on analisys of message or error code received from web application.<br>
+
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and  Gray Box testing have the same concept based on the analysis of messages or error codes received from web application.<br>
 
'''Result Expected:'''<br>
 
'''Result Expected:'''<br>
The application should anwser in the same manner for every failed attempt of authentication.<br>
+
The application should answer in the same manner for every failed attempt of authentication.<br>
 
For Example: <br>
 
For Example: <br>
'Credentials submitted are not valid'
+
Credentials submitted are not valid
 
<br><br>
 
<br><br>
 +
 
== References ==
 
== References ==
'''Whitepapers'''<br>
+
* Marco Mella, ''Sun Java Access & Identity Manager Users enumeration: http://www.aboutsecurity.net<br>''
...<br>
+
* ''Username Enumeration Vulnerabilities: http://www.gnucitizen.org/blog/username-enumeration-vulnerabilities<br>''
 +
 
 
'''Tools'''<br>
 
'''Tools'''<br>
 
* WebScarab: [[OWASP_WebScarab_Project]]
 
* WebScarab: [[OWASP_WebScarab_Project]]
 +
* CURL: http://curl.haxx.se/
 +
* PERL: http://www.perl.org
 +
* Sun Java Access & Identity Manager users enumeration tool: http://www.aboutsecurity.net

Latest revision as of 23:27, 25 October 2012

This article is part of the new OWASP Testing Guide v4. 
At the moment the project is in the REVIEW phase.

Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: http://www.owasp.org/index.php/OWASP_Testing_Project

Contents


Brief Summary

The scope of this test is to verify if it is possible to collect a set of valid usernames by interacting with the authentication mechanism of the application. This test will be useful for the brute force testing, in which we verify if, given a valid username, it is possible to find the corresponding password. Often, web applications reveal when a username exists on system, either as a consequence of a misconfiguration or as a design decision. For example, sometimes, when we submit wrong credentials, we receive a message that states that either the username is present on the system or the provided password is wrong. The information obtained can be used by an attacker to gain a list of users on system. This information can be used to attack the web application, for example, through a brute force or default username/password attack.

Description of the Issue

The tester should interact with the authentication mechanism of the application to understand if sending particular requests causes the application to answer in different manners. This issue exists because the information released from web application or web server when we provide a valid username is different than when we use an invalid one.

In some cases, we receive a message that reveals if the provided credentials are wrong because an invalid username or an invalid password was used. Sometimes, we can enumerate the existing users by sending a username and an empty password.

Black Box testing and example

In a black box testing, we know nothing about the specific application, username, application logic, error messages on login page, or password recovery facilities. If the application is vulnerable, we receive a response message that reveals, directly or indirectly, some information useful for enumerating users.


HTTP Response message

Testing for Valid user/right password

Record the server answer when you submit a valid userID and valid password.

Result Expected:

Using WebScarab, notice the information retrieved from this successful authentication (HTTP 200 Response, length of the response).


Testing for valid user/wrong password
Now, the tester should try to insert a valid userID and a wrong password and record the error message generated by the application.

Result Expected:
From the browser we will expect message similar to the following one:
AuthenticationFailed.png

or something like:
NoConfFound.jpg

against any message that reveals the existence of user, for instance, message similar to:

Login for User foo: invalid password

Using WebScarab, notice the information retrieved from this unsuccessful authentication attempt (HTTP 200 Response, length of the response).


Testing for a nonexistent username

Now, the tester should try to insert an invalid userID and a wrong password and record the server answer (you should be confident that the username is not valid in the application). Record the error message and the server answer.

Result Expected:

If we enter a nonexistent userID, we can receive a message similar to:
Userisnotactive.png
or message like the following one:

Login failed for User foo: invalid Account

Generally the application should respond with the same error message and length to the different wrong requests. If you notice that the responses are not the same, you should investigate and find out the key that creates a difference between the two responses. For example:

  • Client request: Valid user/wrong password --> Server answer:'The password is not correct'
  • Client request: Wrong user/wrong password --> Server answer:'User not recognized'

The above responses let the client understand that for the first request we have a valid user name. So we can interact with the application requesting a set of possible userIDs and observing the answer.

Looking at the second server response, we understand in the same way that we don't hold a valid username. So we can interact in the same manner and create a list of valid userID looking at the server answers.

Other ways to enumerate users

We can enumerate users in several ways, such as:
- Analyzing the error code received on login pages
Some web application release a specific error code or message that we can analyze.

- Analyzing URLs, and URLs redirections
For example:

http://www.foo.com/err.jsp?User=baduser&Error=0
http://www.foo.com/err.jsp?User=gooduser&Error=2

As we can see above, when we provide a userID and password to the web application, we see a message indication that an error has occurred in the URL. In the first case we has provided a bad userID and bad password. In the second, a good user and bad password, so we can identify a valid userID.

- URI Probing
Sometimes a web server responds differently if it receives a request for an existing directory or not. For instance in some portals every user is associated with a directory. If we try to access an existing directory we could receive a web server error. A very common error that we can receive from web server is:

  403 Forbidden error code 

and

  404 Not found error code


Example

http://www.foo.com/account1 - we receive from web server: 403 Forbidden 
http://www.foo.com/account2 - we receive from web server: 404 file Not Found


In first case the user exists, but we cannot view the web page, in second case instead the user “account2” doesn’t exist. Collecting this information we can enumerate the users.


- Analyzing Web page Titles
We can receive useful information on Title of web page, where we can obtain a specific error code or messages that reveal if the problems are on username or password. For instance, if we cannot authenticate to an application and receive a web page whose title is similar to:

Invalid user
Invalid authentication


- Analyzing message received from recovery facility
When we use a recovery facility (i.e. a Forgotten Password function) a vulnerable application might return a message that reveals if a username exists or not.

For example, message similar to the following:

Invalid username: e-mail address is not valid or the specified user was not found.
Valid username: Your password has been successfully sent to the email address you registered with.



- Friendly 404 Error Message
When we request for a user within the directory that does not exist, we don't always receive 404 error code. Instead, we may receive “200 ok” with an image, in this case we can assume that when we receive the specific image the user doesn’t exist. This logic can be applied to other web server response; the trick is a good analysis of web server and web application messages.

Guessing Users

In some cases the userIDs are created with specific policies of administrator or company. For example we can view a user with a userID created in sequential order:
CN000100
CN000101
….
Sometimes the usernames are created with a REALM alias and then a sequential numbers:
R1001 – user 001 for REALM1
R2001 – user 001 for REALM2

In the above sample we can create simple shell scripts that compose UserIDs and submit a request with tool like wget to automate a web query to discern valid userIDs. To create a script we can also use Perl and CURL.

Other possibilities are: - userIDs associated with credit card numbers, or in general numbers with a pattern. - userIDs associated with real names, e.g. if Freddie Mercury has a userID of "fmercury", then you might guess Roger Taylor to have the userID of "rtaylor".

Again, we can guess a username from the information received from an LDAP query or from Google information gathering, for example, from a specific domain. Google can help to find domain users through specific queries or through a simple shell script or tool.




Attention: by enumerating user accounts, you risk locking out accounts after a predefined number of failed probes (based on application policy). Also, sometimes, your IP address can be banned by dynamic rules on the application firewall or Intrusion Prevention System.

Gray Box testing and example

Testing for Authentication error messages
Verify that the application answers in the same manner for every client request that produces a failed authentication. For this issue the Black Box testing and Gray Box testing have the same concept based on the analysis of messages or error codes received from web application.
Result Expected:
The application should answer in the same manner for every failed attempt of authentication.
For Example:

Credentials submitted are not valid



References

Tools