Most users are aware of the risks connected to the default, blank and weak username/password combinations associated with most applications. Yet it amazes the research community that many companies still don’t heed the following simple advice:
1) Don’t use easily guessed passwords. 2) Change the default credentials that ship with your apps, and 3) Please do not just leave the passwords blank!
When it comes to passwords and user names, the database is just like every other application. In fact, given the amount of sensitive and proprietary information stored in databases, it can be argued that protecting this information is even more important.
It’s a common practice in the software industry to create default accounts during the installation of applications. This is often necessary to properly install the software. Default accounts and passwords also exist to provide users with a convenient method of testing the software. Sometimes these defaults are implemented as part of a demo package.
Others times they are created during the installation of third-party software. As part of the standard, out-of-the-box installation procedure, the software might create several accounts in the backend database associated with install, administrative and typical user privileges.
Some of the prime examples in the DBMS world are as follows. Oracle created the username/password of ‘SCOTT’/’TIGER’. SQLServer had ‘sa’ with a blank password. DB2 came with ‘db2admin’/’db2admin’ as a default. The list continues. Other default accounts are installed by third party products like SAP, where default database users are enabled at the time of installation.
This problem is not limited to simple user names and passwords, but extends to access rights to confidential databases. Once attackers are successful at password guessing, a cumulative effect can take place. A good attacker can breach an initial database, and if that server does not yield information, use that database as a jumping off point to other servers within the enterprise.
The increased prevalence of insider attacks mandates that you pay attention to access rights and privileges. When roles are granted to database users, they typically are able to execute a set group of commands.
Or, they might be granted a role, or inherit a role that enables them to execute commands beyond what is required to perform their job. Ensuring that databases are locked down with at unique passwords in combination with regular user entitlement reviews is critical to ensuring appropriate database rights and privileges.
Attackers are constantly looking for easy way to steal sensitive data. Ignoring or improperly implementing passwords and user names enables thieves to easily compromise your systems. Through the simple task of creating customized username/password combinations and ensuring EVERY DBMS on your network has eliminated default, blank, and weak username/passwords, you can significantly reduce internal and external threats to your sensitive data.
Although things have recently improved and most DBMS’s now ask for custom usernames and/or passwords in the installer screens, the risk has not been eliminated. Just Google ‘Oracle default users’ and you will be pointed to 4.5 million pages, with more than 1,000 default username/password combinations.
Don’t leave yourself vulnerable to these attacks. Do yourself a favor and take the small amount of time required to implement strong passwords.
* Alex Rothacker is the manager of the SHATTER Research Team at Application Security, Inc. SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research researches database vulnerabilities to provide vulnerabilities, risk and remediation information to customers and the global database community.
