Risk

5/25/2010
02:25 PM
50%
50%

Default Database Passwords Still In Use

Researchers urge review of database accounts against list of more than 1,000 default user name and password combinations

The rampant use of default passwords within live database environments continues to plague the security of enterprise data, researchers say.

"It's a problem that has been around for a long, long time," says Alex Rothacker, manager of Team SHATTER, Application Security Inc.'s research arm. "A lot of default passwords out there get installed when you deploy a database, you install an add-on to it, or even if you install a third-party application that uses the database."

As he puts it, the problem of default passwords lingering in the wild has built up during the years as a result of cumulative errors by both vendors and database administrators. In the past, the majority of vendors had no compunction about pushing out installers that automatically created default accounts to expedite the deployment of new databases, add-ons, or applications on top of the database.

"In order to perform some of the installation functions, they need to create database accounts, and some of them simply go and create an account and put a default password on it that's well-known to the whole world," he says.

Meanwhile, users did nothing to clean up these default accounts once installation was complete. Rothacker says the situation on the vendor front has improved considerably in recent years, but default passwords continue to be a problem for a number of reasons.

To date, AppSec's team has collected more than 1,000 well-known default user name and password combinations used by different vendors within databases across the IT spectrum. Rothacker says organizations should do a thorough check of their database accounts to ensure they are not using any of the combos on the list.

Organizations that choose to skip such a review could be leaving themselves at serious risk, says Rich Mogull of Securosis. "There are worms out there that use automated scanners that are just looking for default administrative credentials on old systems," Mogull says.

Team SHATTER last week launched a series of week-long database vulnerability-a-day awareness campaigns to draw attention to a wide range of database deployment deficiencies in the enterprise. They started with the topic of organizations leaving default passwords in place on these systems.

"[Database] vendors have gotten a lot better -- the better implementations ask you to create the account so you, as the administrator who installs the system, can put in an account name and a password," Rothacker says. "But there still are a lot of databases out there that either got upgraded and the upgraded scripts don't always fix those issues, and there's also still a lot of software out there that gets installed on top of those databases."

These could be software tools, such as content management systems for a website, running on top of the database, or big packages, such as SAP or PeopleSoft, that will create default accounts in order to work with the database.

On top of this, the number of legacy systems out there that have never been checked for default accounts created when vendors weren't so savvy still remains high, according to the AppSec researchers.

Scott Laliberte can vouch for that. As managing director for Protiviti, a security consultancy, he has led countless security audits of live databases that dredge up default login credentials just waiting to be taken advantage of.

"We'll go in and do an assessment where the OS is hardened [or] the ERP has had a segregation of duties review done. All of these different security settings within the actual application are great, but [they are] all sitting on a default database install," he says. "I've actually done several reviews like that, where there were default passwords on database accounts, the database had not been hardened, and it was a complete mess."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Government Shutdown Brings Certificate Lapse Woes
Curtis Franklin Jr., Senior Editor at Dark Reading,  1/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security 2018
This Dark Reading Tech Digest explores the biggest news stories of 2018 that shaped the cybersecurity landscape.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-6443
PUBLISHED: 2019-01-16
An issue was discovered in NTPsec before 1.1.3. Because of a bug in ctl_getitem, there is a stack-based buffer over-read in read_sysvars in ntp_control.c in ntpd.
CVE-2019-6444
PUBLISHED: 2019-01-16
An issue was discovered in NTPsec before 1.1.3. process_control() in ntp_control.c has a stack-based buffer over-read because attacker-controlled data is dereferenced by ntohl() in ntpd.
CVE-2019-6445
PUBLISHED: 2019-01-16
An issue was discovered in NTPsec before 1.1.3. An authenticated attacker can cause a NULL pointer dereference and ntpd crash in ntp_control.c, related to ctl_getitem.
CVE-2019-6446
PUBLISHED: 2019-01-16
An issue was discovered in NumPy 1.16.0 and earlier. It uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object, as demonstrated by a numpy.load call.
CVE-2019-6442
PUBLISHED: 2019-01-16
An issue was discovered in NTPsec before 1.1.3. An authenticated attacker can write one byte out of bounds in ntpd via a malformed config request, related to config_remotely in ntp_config.c, yyparse in ntp_parser.tab.c, and yyerror in ntp_parser.y.