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.

Vulnerabilities / Threats

11/1/2010
01:23 PM
50%
50%

The 10 Most Common Database Vulnerabilities

Nearly half of weaknesses are directly or indirectly related to lax patch management practices

Slideshow: The 10 Most Common Database Vulnerabilities
The 10 Most Common Database Vulnerabilities
(view slideshow)

Protecting databases is hardly an easy task, but it is often the attacks that go after the simplest vulnerabilities that are most successful. Enterprises that stick to the basics will generate the most bang for their database security bucks. According to Alex Rothacker, manager of AppSec's Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research), his team has found that are 10 common database vulnerabilities that keep plaguing organizations over and over again.

The common thread in this list is that databases rarely ship security-ready, and their configuration is not a fire-and-forget operation for database administrators. Organizations must continually assess packages to determine if they are really necessary and disable those they don't need to reduce attack surfaces. They need to be vigilant about keeping on the lookout for default or weak log-in credentials. They have to put sound privilege and authentication practices into play. And most important, they need to patch regularly.

About half of the vulnerabilities named by Rothacker and his team are directly or indirectly related to lax patch management practices within the database environment. That's a scary thought considering only 38 percent of administrators patch their Oracle databases within the initial three-month patch cycle. And almost a third take a year or more to patch.

Take a look at the following top 10 list. And here are some illustrations of the vulnerabilities.

1. Default, blank, and weak username/password

It might be a daunting task at an organization that has to keep track of hundreds or even thousands of databases. But removing default, blank and weak log-in credentials is an important first step for filling chinks in your database armor. The bad guys are keeping track of default accounts, and they'll use them when they can.

2. SQL injections

When your database platform fails to sanitize inputs, attackers are able to execute SQL injections similar to the way they do in Web-based attacks, eventually allowing them to elevate privileges and gain access to a wide spectrum of functionality. A lot of vendors have released fixes to prevent these problems, but it won't do much good if your DBMS remains unpatched.

3. Extensive user and group privileges

Organizations need to ensure privileges are not given to users who will eventually collect them like janitors collect keys on their keychains. Instead, Rothacker recommends only making users part of groups or roles and administering the rights through those roles, which can be managed collectively more easily than if users were assigned direct rights.

4. Unnecessarily enabled database features

Every database installation comes with add-on packages of all shapes and sizes that are mostly going to go unused by any one organization. Since the name of the game in database security is to reduce attack surfaces, enterprises need to look for packages that don't use and disable or uninstall them. This not only reduces risks of zero-day attacks through these vectors, but it also simplifies patch management. When it'those packages need the patching, your organization won't need to scramble.

5. Broken configuration management

Similarly, databases have a panoply of many different configuration choices and considerations available to DBAs to fine-tune performance and enhanced functionalities. Organizations need to be on the lookout for unsafe configurations that could be enabled by default or turned on for convenience of DBAs or application developers.

6. Buffer overflows

Another hacker favorite, buffer overflow vulnerabilities, are exploited by flooding input sources with far more characters than an application was expecting--say, by adding 100 characters into an input box asking for a SSN. Database vendors have worked hard to fix the glitches that allow these attacks to occur. This is yet another reason why patching is so critical.

7. Privilege escalation

Similarly, databases frequently sport common vulnerabilities that allow attackers to escalate privileges within a little known and low privilege account and gain access to administrator rights. For example, an attacker might misuse a function that runs under a sysdba, Rothacker explains. As these vulnerabilities are uncovered, administrators need to reign them in with timely updates and patching.

8. Denial-of-service attack

SQL Slammer provided a very illuminating illustration of how attackers can use DBMS vulnerabilities to take down database servers through a flood of traffic. Even more illuminating is the fact that when Slammer went down in 2003, a patch already was out there that addressed the vulnerability it attacked. Even seven years later, SQL Slammer is still around and picking on unpatched servers.

9. Unpatched databases

This could be repetitive, but it bears repeating. So many database administrators don't patch in a timely fashion because they're afraid a patch will break their databases. But the risk of getting hacked today is way higher than the risk of applying a patch that will go haywire, Rothacker says. That might not have been true five years ago, but vendors have become much more rigorous with their testing.

10. Unencrypted sensitive data at rest and in motion

Perhaps it is a no-brainer, but organizations should never store sensitive data in clear text within a database table. And all connections to the database should always use encryption.

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
AI Is Everywhere, but Don't Ignore the Basics
Howie Xu, Vice President of AI and Machine Learning at Zscaler,  9/10/2019
Fed Kaspersky Ban Made Permanent by New Rules
Dark Reading Staff 9/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-4147
PUBLISHED: 2019-09-16
IBM Sterling File Gateway 2.2.0.0 through 6.0.1.0 is vulnerable to SQL injection. A remote attacker could send specially-crafted SQL statements, which could allow the attacker to view, add, modify or delete information in the back-end database. IBM X-Force ID: 158413.
CVE-2019-5481
PUBLISHED: 2019-09-16
Double-free vulnerability in the FTP-kerberos code in cURL 7.52.0 to 7.65.3.
CVE-2019-5482
PUBLISHED: 2019-09-16
Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3.
CVE-2019-15741
PUBLISHED: 2019-09-16
An issue was discovered in GitLab Omnibus 7.4 through 12.2.1. An unsafe interaction with logrotate could result in a privilege escalation
CVE-2019-16370
PUBLISHED: 2019-09-16
The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.