Protecting a database instance can be very difficult, even simple mistakes can lead to a compromise that allows the attacker to gain access to very sensitive company data. As an administrator, you should start with the basic configuration settings, and work toward the more complicated setting to create a secure and stable database platform. There have been several research teams look at the most common vulnerabilities, and they have found that are 10 common database vulnerabilities that keep appearing in organizations that don’t pay attention to the basics.
The first thing to remember is that the default installation settings are rarely the most secure settings. After to install the instance onto your server, there are some basic settings to change right away, but security is something you need to think about all the time. You should review the setting at least once a year, because what was secure before may now be an issue. You need to be vigilant about watching for default or weak log-in credentials, changes to the configuration that opens attack avenues, or weaknesses in the product that must be addressed through reconfiguring the product to reduce the attack profile. The most important thing you can do is regularly apply vendor patches.
TeamSHATTER has done some good work in creating the basic “Top 10” list.
1. Password Issues
You need to remove any default accounts, enforce a standard and strong password requirement, and not allow any blank passwords. Anyone who would attack your database already knows about default accounts, so those are the first accounts that will be attacked.
2. SQL Injection
If your database fails to sanitize inputs, any attacker will use SQL injection, similar to the way they do in Web-based attacks, to attack your database. The idea is to eventually gain access and then elevate their privileges to allow control of the server and even full control of your server. Vendors have released patches to address this concern, but it only works if you have installed the patches.
3. User and Group Privileges
Always verify users and groups receive the minimal privileges required for their duties, and nothing more. You are required, by most audits and compliance standards, to make sure users and groups have just the privileges they need to perform their normal responsibilities, and absolutely nothing more. This is something that is evolving, as people are hires, promoted, transferred or terminated, and should be reviewed at least annually.
4. Unnecessarily Database Features
Every database installation comes with add-on packages of all types that are mostly unused by typical organizations. This list highlights various optional components and features that should be removed or disabled – unless there is a valid business reason to make them available.
- Microsoft SQL Server Permission Granted on xp_cmdshell
- Microsoft SQL Server xp_cmdshell Not Removed or Not Disabled
- Microsoft SQL Server OLEDB Ad Hoc Query Allowed
5. Configuration Management
There are several options available to allow the Database Administrator to enhanced functionality or improve performance. You should not enable anything until you understand how it works and have researched how it should be properly configured. Just because you can get it working doesn’t mean you are doing it correctly or securely.
6. Buffer Overflows
Buffer overflow vulnerabilities are exploited by flooding input sources with far more characters than an application was expecting, usually found by adding extra characters into an input box and seeing if the buffer overflowed and the system is compromised. In most cases, this will be more or less random and can lead to unpredictable behavior, like crashing the server. Vendors have worked hard to fix the issues that allow these attacks to succeed, but your system is only protected if the patches are installed.
7. Privilege Escalation
Databases frequently have common vulnerabilities that allow attackers to escalate privileges within a little known and low privilege account and gain access to administrator rights. As these vulnerabilities are uncovered, database administrators need to control them by applying vendor updates and patches.
8. Denial-of-Service Attack
Usually every common attack is executed after a vendor patch is already available, but there are so many systems that aren’t patches correctly it still make a major impact. The SQL Slammer attack provided an effective example of how someone can use a known vulnerability to cripple a database server with a simple traffic flood. You need to understand DoS attack methods and understand the risk to your environment. To mitigate risk and ensure critical databases stay up and running, be sure to patch all database servers with the latest vendor patches.
9. Unpatched Databases
Many database administrators don’t install patches in a timely fashion because they’re afraid a vendor patch will break their database server. You need a test server that you can use as a guinea pig to test all changes before they are applied to production, including vendor patches. You should test and apply all vendor patches within 30 days of availability. Want to see existing known vulnerabilities for SQL Server?
10. Unencrypted Sensitive Data
Your organization should never store sensitive data in clear text in your database. Use encryption when you store sensitive data, and all connections to the database should also use encryption. This includes sensitive employee and customer data like personal information, credit card, or health-related data.
You can get more information from here.