Testing for Default or Guessable User Account (OWASP-AT-003)

Brief Summary
Today's web application scenario is often populated by common software (begin OpenSource or Commercial) that is installed on web servers and configured or customized. In addition to this most of today's hardware appliance offer web-based configurations or administrative interfaces. Often in this pre-configured application and appliance scenario it's easy to encounter administrative software, interfaces and/or websites who use the default credentials for logging in. This default username/password are wildly known by pentesters and malicious users that can use them as a powerful mean to gain access to internal infrastructure and/or to gain privileges and steal data. The same problem applies to software and/or appliances that spot built-in non-removable accounts and, in fewer cases, uses blank passwords as default credentials.

Description of the Issue
The source for this problem is often inexperienced IT personnel, unaware of the importance of changing default passwords on installed infrastructure components, programmers, leaving backdoors so they can easily access and test the application, later forgetting to remove them, application administrators and users that chose an easy username and password for themselves, and application with built in, non-removable default accounts with a pre-set username and password. Another problem is blank passwords, which are simply a result of security unawareness and willingness to simplify things.

Black Box testing and example
In blackbox testing we know nothing about the application, its underlying infrastructure, and any username and/or password policies. Often this is not the case and some information about the application is provided – simply skip the steps that refer to obtaining information you already have.

When testing a known application interface, such as a Cisco router web interface, or Weblogic admin access, check the known usernames and passwords for these devices. This can be done either by Google, or using one of the references in the Further Reading section.

When facing a home-grown application, to which we do not have a list of default and common user accounts, we need to test it manually, following these guidelines:
 * Try the following usernames - "admin", "administrator", "root", "system", 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 managed to identify any of the above usernames, attempt passwords in a similar manner.
 * Application administrative users are often named after the application. This means if you are testing an application named "Obscurity", try using obscurity/obscurity as the username and password.
 * When performing a test for a customer, attempt using names of contacts you have received as usernames.
 * Attempt using all the above usernames with blank passwords.

Result Expected: ...

Gray Box testing and example
The steps described next rely on an entirely White Box approach. If only some of the information is available to you, refer to black box testing to fill the gaps.

Talk to the IT personnel to determine which passwords they use for administrative access.

Check whether these usernames and passwords are complex, difficult to guess, and not related to the application name, person name, or administrative names ("system"). Note blank passwords. Check in the user database for default names, application names, and easily guessed names as described in the Black Box testing section. Check for empty password fields.

Examine the code for hard coded usernames and passwords. Result Expected: ...