Change default credentials

One of the most important steps in any system build or application development process is to remove default or test credentials before going live. Yet, in virtually every penetration test we carry out, at least one system has a set of usernames and passwords that can easily be guessed.

The simplest has to be a web application on the internet, particularly where the username is an email address (try "test@test.com" and "test" as the password). This account is often created during development but is not changed on going live, and sometimes even has raised privileges. I feel sorry for the people who own the test.com domain - they must get tons of junk email as a result of users trying this account name in forgotten password fields of web applications!

Everyone has tried "admin" and "password" in logins and this sometimes works, but not as often as it used to. Far more common is an application or system that has been developed by a third party. We often find administrative interfaces to these systems on the internet, protected by a nice login form, when we're asked to test a company's systems.

The trick is to find out which vendor wrote the application. Using the vendor's name in both the username and password field often works. We found a beauty a couple of weeks ago that permitted us access to administrate the client's website and customer database. What is most depressing is that it's usually possible to Google for instances of these vendor-supplied applications, allowing hackers to compromise multiple organisations with the same application.

Moving away from web applications, hardware devices such as routers and access points often have interfaces available to the internet. Again, default credentials are common, particularly among home users. Simply Google for lists of default credentials (try www.phenoelit-us.org for enormous lists of potentials).

A friend took advantage of this knowledge a few years ago at a hotel in the Middle East. They had paid for wireless internet access, only to find the subnet range of the wireless AP conflicted with the internal corporate address they planned to connect to using a VPN. The AP had its admin interface available on the customer subnet, default credentials were present, by all accounts no one else was connected to the network at the time, so they simply logged into it, changed the subnet to another, and connected happily to their office network.

FTP servers found on the internet are often interesting. Guest and anonymous accounts are generally present, and while these usually have restricted access, it's not always the case. Local authorities invariably have FTP servers for utilities and others to upload information about street work. Or utilities use them to collect telemetry information from remote monitoring stations, usually to facilitate SCADA systems. Few are sufficiently protected.

I won't dwell on systems on internal networks, other than to say that default or missing credentials on database servers are one of the most common issues we find.

What to do? First, do you really need that admin interface for your router/web application available to the public internet? Could access not be restricted to a range of source IP addresses?

Second, one of the last stages in deployment of any system or application should be an audit of the user accounts present. Have you removed development accounts? Have you renamed the administrator account to something other than "administrator"?

Lastly, ensure that default accounts configured by the manufacturer or software author have been removed. Try a few of the obvious candidates yourself, as they may not be present in brute-force dictionaries.

And a final thought; when you're next logging in to your web applications, try some default creds, maybe test/test or test@test.com/test on the login. You might be surprised to find it works.

- Ken Munro is managing director of SecureTest. He can be contacted at ken.munro@securetest.com.

Copyright © SC Magazine, US edition

changecredentialsdefaultsecurity