Review and minor corrections.
← Older revision
Revision as of 20:10, 21 March 2014
Line 7:
Line 7:
Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. <br>
Often these applications, once installed, are not properly configured and the default credentials provided for initial authentication and configuration are never changed. <br>
These default credentials are well known by penetration testers and, unfortunately, also by malicious attackers, who can use them to gain access to various types of applications. <br>
These default credentials are well known by penetration testers and, unfortunately, also by malicious attackers, who can use them to gain access to various types of applications. <br>
−
Furthermore, in many situations, when a new account is created on an application, a default password (with some standard characteristics) is generated. If this password is predictable and the user does not change it on the first access, this can lead an attacker
to gain
unauthorized access to the application.
+
Furthermore, in many situations, when a new account is created on an application, a default password (with some standard characteristics) is generated. If this password is predictable and the user does not change it on the first access, this can lead
to
an attacker
gaining
unauthorized access to the application.
<br>
<br>
== Description of the Issue ==
== Description of the Issue ==
Line 15:
Line 15:
* Programmers who leave backdoors to easily access and test their application and later forget to remove them.
* Programmers who leave backdoors to easily access and test their application and later forget to remove them.
* Applications with built-in, non-removable default accounts with a pre-set username and password.
* Applications with built-in, non-removable default accounts with a pre-set username and password.
−
* Applications that do not force the user to change the default
credential
after the first login operation.
+
* Applications that do not force the user to change the default
credentials
after the first login operation.
<br>
<br>
Line 22:
Line 22:
===Testing for default credentials of common applications===
===Testing for default credentials of common applications===
−
In Blackbox testing the tester knows nothing about the application and its underlying infrastructure. In reality this is often not true, and some information about the application is known. We suppose that you have identified, through the use of the techniques described in this Testing Guide under the chapter Information Gathering, at least one or more common applications that may contain accessible administrative interfaces.<br>
+
In Blackbox testing the tester knows nothing about the application and its underlying infrastructure. In reality this is often not true, and some information about the application is known. We suppose that you have identified, through the use of the techniques described in this Testing Guide under the chapter
[[Testing
Information Gathering
|Information Gathering]]
, at least one or more common applications that may contain accessible administrative interfaces.<br>
When you have identified an application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. To do this you can consult the manufacturer’s documentation or, in a much simpler way, you can found common credentials using a search engine or by using one of the sites or tools listed in the Reference section. <br>
When you have identified an application interface, for example a Cisco router web interface or a Weblogic administrator portal, check that the known usernames and passwords for these devices do not result in successful authentication. To do this you can consult the manufacturer’s documentation or, in a much simpler way, you can found common credentials using a search engine or by using one of the sites or tools listed in the Reference section. <br>
−
When facing applications to which we do not have a list of default and common user accounts (due to the fact
for example
that the application is not widely spread) we can attempt to guess valid default credentials.<br>
+
When facing applications to which we do not have a list of default and common user accounts (
for example
due to the fact that the application is not widely spread) we can attempt to guess valid default credentials.<br>
Note that the application being tested may have an account lockout policy enabled, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it. <br>
Note that the application being tested may have an account lockout policy enabled, and multiple password guess attempts with a known username may cause the account to be locked. If it is possible to lock the administrator account, it may be troublesome for the system administrator to reset it. <br>
Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. Such functionality can be found, for example, on the login page, password reset and forgotten password page, and sign up page. Once you have found a default username you could also start guessing passwords for this account.<br>
Many applications have verbose error messages that inform the site users as to the validity of entered usernames. This information will be helpful when testing for default or guessable user accounts. Such functionality can be found, for example, on the login page, password reset and forgotten password page, and sign up page. Once you have found a default username you could also start guessing passwords for this account.<br>
−
More information about this procedure can be found in the section [[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)|Testing for User Enumeration and Guessable User]] and in the section [[Testing for Weak password policy (OWASP-AT-008)|Testing for Weak password policy]]. <br>
+
More information about this procedure can be found in the section [[Testing for User Enumeration and Guessable User Account (OWASP-AT-002)|Testing for User Enumeration and Guessable User
Account
]] and in the section [[Testing for Weak password policy (OWASP-AT-008)|Testing for Weak password policy]]. <br>
Since these types of default credentials are often bound to administrative accounts you can proceed in this manner:
Since these types of default credentials are often bound to administrative accounts you can proceed in this manner:
−
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you
successfully
manage to identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
+
* Try the following usernames - "admin", "administrator", "root", "system", "guest", "operator", or "super". These are popular among system administrators and are often used. Additionally you could try "qa", "test", "test1", "testing" and similar names. Attempt any combination of the above in both the username and the password fields. If the application is vulnerable to username enumeration, and you manage to
successfully
identify any of the above usernames, attempt passwords in a similar manner. In addition try an empty password or one of the following "password", "pass123", "password123", "admin", or "guest" with the above accounts or any other enumerated accounts. Further permutations of the above can also be attempted. If these passwords fail, it may be worth using a common username and password list and attempting multiple requests against the application. This can, of course, be scripted to save time.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
* Application administrative users are often named after the application or organization. This means if you are testing an application named "Obscurity", try using obscurity/obscurity or any other similar combination as the username and password.
−
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords.
+
* When performing a test for a customer, attempt using names of contacts you have received as usernames with any common passwords
. Customer email addresses mail reveal the user accounts naming convention: if employee John Doe has the email address jdoe@example.com, you can try to find the names of system administrators on social media and guess their username by applying the same naming convention to their name
.
* Attempt using all the above usernames with blank passwords.
* Attempt using all the above usernames with blank passwords.
−
* Review the page source and
javascript
either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
+
* Review the page source and
JavaScript
either through a proxy or by viewing the source. Look for any references to users and passwords in the source. For example "If username='admin' then starturl=/admin.asp else /index.asp" (for a successful login vs a failed login). Also, if you have a valid account, then login and view every request and response for a valid login vs an invalid login, such as additional hidden parameters, interesting GET request (login=yes), etc.
−
* Look for account names and passwords written in comments in the source code. Also look in backup directories
, etc
for source code that may contain comments
of interest
.
+
* Look for account names and passwords written in comments in the source code. Also look in backup directories for source code
(or backups of source code)
that may contain
interesting
comments
and code
.
===Testing for default password of new accounts===
===Testing for default password of new accounts===
−
As mentioned previously, in other situations,
when a new account is created
on
an application
,
a default password
is generated
. This password could have some standard characteristics making it predictable
and if
the user does not change it on
the
first
access
(this often happens if the user is not forced to change it), this can lead an attacker to gain unauthorized access to the application.<br>
+
It can also occur that
when a new account is created
in
an application
that the account is assigned
a default password. This password could have some standard characteristics making it predictable
. If
the user does not change it on first
usage
(this often happens if the user is not forced to change it)
or if the user has not yet logged on to the application
, this can lead an attacker to gain unauthorized access to the application.<br>
−
Advice for testing default passwords on common application (
about lockout policy and verbose error messages
) still remain valid
also for
this test
.<br>
+
The advice given before
about
a possible
lockout policy and verbose error messages
are
also
applicable here when testing
for
default passwords
.<br>
−
The
Following
steps can be applied to test for these types of default credentials:
+
The
following
steps can be applied to test for these types of default credentials:
−
*
Viewing
the User Registration page may help determine the expected format and length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
+
*
Looking at
the User Registration page may help
to
determine the expected format and
minimum or maximum
length of the application usernames and passwords. If a user registration page does not exist, determine if the organization uses a standard naming convention for user names such as their email address or the name before the "@" in the email.
−
* Try to extrapolate from the application how usernames are generated. For example, can a user
create their
own username or does the system
create
an account for the user based on some personal information or a predictable sequence? If the application does
create its own accounts
in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
+
* Try to extrapolate from the application how usernames are generated. For example, can a user
choose his/her
own username or does the system
generate
an account
name
for the user based on some personal information or
by using
a predictable sequence? If the application does
generate the account names
in a predictable sequence, such as user7811, try fuzzing all possible accounts recursively. If you can identify a different response from the application when using a valid username and a wrong password, then you can try a brute force attack on the valid username (or quickly try any of the identified common passwords above or in the reference section).
−
* Try to determine if the password is predictable
by creating
many new accounts
in quick succession to
compare and determine if the passwords are predictable. If predictable,
then
try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.
+
* Try to determine if the
system generated
password is predictable
. To do this, create
many new accounts
quickly after one another so that you can
compare and determine if the passwords are predictable. If predictable, try to correlate these with the usernames, or any enumerated accounts, and use them as a basis for a brute force attack.
* If you have identified the correct naming convention for the user name, try to “brute force” passwords with some common predictable sequence like for example dates of birth.
* If you have identified the correct naming convention for the user name, try to “brute force” passwords with some common predictable sequence like for example dates of birth.
* Attempt using all the above usernames with blank passwords or using the username also as password value.
* Attempt using all the above usernames with blank passwords or using the username also as password value.
−
<br>
−
===Result Expected===
−
Successful authentication to the application or system being tested.
<br>
<br>
Line 54:
Line 51:
<br>
<br>
The following steps rely on an entirely Gray Box approach. If only some of this information is available to you, refer to black box testing to fill the gaps.
The following steps rely on an entirely Gray Box approach. If only some of this information is available to you, refer to black box testing to fill the gaps.
−
* Talk to the IT personnel to determine passwords they use for administrative access and how administration of the application is undertaken.
+
* Talk to the IT personnel to determine
which
passwords they use for administrative access and how administration of the application is undertaken
.
+
* Ask IT personnel if default passwords are changed and/or if default user accounts are disabled
.
* Examine the user database for default credentials as described in the Black Box testing section. Also check for empty password fields.
* Examine the user database for default credentials as described in the Black Box testing section. Also check for empty password fields.
* Examine the code for hard coded usernames and passwords.
* Examine the code for hard coded usernames and passwords.
* Check for configuration files that contain usernames and passwords.
* Check for configuration files that contain usernames and passwords.
−
* Examine the password policy and, if the application
creates
its own passwords for new users, check the policy in use for this procedure
.
+
* Examine the password policy and, if the application
generates
its own passwords for new users, check the policy in use for this procedure.
−
<br>
+
−
===Result Expected===
+
−
Successful authentication to the application or system being tested
.
+
<br><br>
<br><br>
== References ==
== References ==
Line 70:
Line 65:
'''Tools'''<br>
'''Tools'''<br>
−
* Burp Intruder: http://portswigger.net/
intruder
/
+
* Burp Intruder: http://portswigger.net/
burp
/
intruder.html
* THC Hydra: http://www.thc.org/thc-hydra/
* THC Hydra: http://www.thc.org/thc-hydra/
* Brutus: http://www.hoobie.net/brutus/
* Brutus: http://www.hoobie.net/brutus/
* Nikto 2: http://www.cirt.net/nikto2
* Nikto 2: http://www.cirt.net/nikto2