Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security //

Database Security

10/11/2012
01:38 AM
50%
50%

Dodging 5 Dangerous Database Default Settings

Out-of-the-box settings and weak configuration of databases make it easier for thieves to break into data stores and harder for IT to quickly detect breaches

Even as enterprises spend buckets of cash on data defenses at various layers of IT infrastructure, many of them sabotage their efforts by ultimately storing that information in poorly configured databases. Whether due to legacy application logistics, convenience to administrators, or lack of awareness by DBAs, databases set up with out-of-the-box settings are all-too-common within the enterprise.

These default configurations make easy pickings for the well-informed data thief. Default account credential settings are the first thing attackers try when they get any kind of access to login screens. Extraneous services and stored procedures make for a broader attack surface for hackers. And bad guys drool when they find encryption keys stored right alongside the database on the same server.

"The only place it's safe to use your default configuration is in your TIVO or television," says David Maman, CTO and founder of GreenSQL. "Anywhere in the IT world it's a crime, especially within your database. Database hardening is critical."

[ Forgetting something? Don't get caught with your patch down. See 5 Systems Your Forgetting To Patch. ]

Because database configurations can make all the difference between safeguarding data stores and leaving them dangerously vulnerable to big data breaches, security experts recommend taking a look at all of your database's default settings for weakness. But, in particular, the following defaults pose the biggest risks.

1. Default Passwords And Accounts
"Password insecurity is definitely the most pernicious configuration problem that affects database servers," says David Litchfield, Accuvant LABS principal security architect.

Configuration gaffes around authentication and account credentials are plentiful, but by far the most dangerous and the most prevalent is simply allowing default administrative usernames and passwords to remain operational.

"Attackers and malware intentionally target known credentials," says John Linkous, chief security and compliance officer for eIQnetworks. "Changing the name of common accounts, such as 'sa,' or other administrative default accounts and using complex passwords for those accounts will help to add a layer of security to the database."

Additionally, allowing default configurations that enable anonymous logins is another risky permissions setting.

"Attackers often use analysis tools to probe for databases that allow anonymous logins and then make a connection to determine the database version and other specifics," says Cal Jewell, senior technical trainer at ExtraHop Networks. "They then use this information to formulate an attack that gives them greater access."

Similarly shared service accounts can pose a big risk because they are difficult to monitor and often provide uncommonly expansive permissions within the database.

2. Allowing Direct Table Access
According to Ron Rule, vice president of e-commerce for Infusion Brands and a long-time development expert, the No. 1 database configuration problem that gets organizations into trouble is when permissions allow for direct table access.

"When your application can make its own SELECT/UPDATE/INSERT/DELETE statements and directly access the tables, your data is vulnerable," Rule says.

One of the best measures in this case is to create an access buffer through stored procedures during development.

"Code your application only to execute the stored procedures, and then give the user access to the stored procedures and DENY access to the tables," he says.

3. Keeping Default Stored Procedures
However, stored procedures are not necessarily a good thing. Out-of-the-box stored procedures that perform common tasks, such as adding users, can actually be a big vulnerability in a lot of situations, Linkous says.

Some out-of-box stored procedures can be extremely powerful in the wrong hands," he says. "Microsoft SQL Server's 'xp_cmdshell' is an example of this: a SP that allows any arbitrary command line to be executed, even if that command operates outside the scope of SQL Server."

He recommends that organizations look closely at default stored procedures and either disable them or delete them entirely.

4. Encryption Keys Stored With Database
Database encryption can add an effective layer of security if executed properly. But poor configuration can render schemes like database vendor-provided Transparent Data Encryption (TDE) effectively useless, says Todd Thiemann, senior director of product marketing for Vormetric.

"The default approach of storing the TDE key next to the database is like taping the key to the doorknob of a bolted door or putting your password on a sticky note on your monitor," he says. "Secure and protect encryption keys on a server that does not host the database."

5. Unnecessary Services and Applications
Databases come with a whole host of support services, applications, and other components enabled to offer a broad set of functionality for as many use cases as possible. But each additional component on a database adds just a little bit more attack surface area for potential attackers to take advantage of.

"Most database products provide 'add-on' components, such as reporting or analysis tools," Linkous says. "These components can introduce additional vulnerabilities to the overall database system, and should be disabled or uninstalled of not needed."

The effects of this are exacerbated by the fact that many databases today are behind on patches, Litchfield says. Fortunately, a lot of risk can be reduced by recognizing that the typical enterprise rarely needs more than a fraction of these feature sets enabled to support any one database installation scenario.

"In our security engagements, we often see every component being installed when a database server is set up just in case it might be needed," he says. "With a little bit of forward planning, this can be avoided. Application developers need to be specific about what components they need and no more."

Have a comment on this story? Please click "Add Your Comment" 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
Commentary
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
News
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
News
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-21510
PUBLISHED: 2021-03-08
Dell iDRAC8 versions prior to 2.75.100.75 contain a host header injection vulnerability. A remote unauthenticated attacker may potentially exploit this vulnerability by injecting arbitrary ‘Host’ header values to poison a web-cache or trigger redirections.
CVE-2020-27575
PUBLISHED: 2021-03-08
Maxum Rumpus 8.2.13 and 8.2.14 is affected by a command injection vulnerability. The web administration contains functionality in which administrators are able to manage users. The edit users form contains a parameter vulnerable to command injection due to insufficient validation.
CVE-2020-27576
PUBLISHED: 2021-03-08
Maxum Rumpus 8.2.13 and 8.2.14 is affected by cross-site scripting (XSS). Users are able to create folders in the web application. The folder name is insufficiently validated resulting in a stored cross-site scripting vulnerability.
CVE-2020-27838
PUBLISHED: 2021-03-08
A flaw was found in keycloak in versions prior to 13.0.0. The client registration endpoint allows fetching information about PUBLIC clients (like client secret) without authentication which could be an issue if the same PUBLIC client changed to CONFIDENTIAL later. The highest threat from this vulner...
CVE-2021-21503
PUBLISHED: 2021-03-08
PowerScale OneFS 8.1.2,8.2.2 and 9.1.0 contains an improper input sanitization issue in a command. The Compadmin user could potentially exploit this vulnerability, leading to potential privileges escalation.