Slideshow: The 10 Most Common Database Vulnerabilities

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.