Privilege Abuse comes in two flavors: Abuse of excessive privileges and abuse of legitimate privileges. In this article, I am going to attempt covering both.
In most database installations, the Least Privilege Principle is not adhered to. There are many reasons why more privileges than necessary were granted to a person or an application login. For example, the development staff might not know any better; or they do know better but think they do not have the time to implement this correctly. There are also occasions in which implementation of the least privilege principle is anything but trivial. Think about an application that needs to be able to create and alter SQL Agent Jobs. Even an extensive internet search might leave you with the false impression that adding the application account to the sysadmin fixed server role is your only option to make that particular requirement work.
Granting excessive permissions is problematic for two reasons. About 80% of the attacks on company data are actually executed by employees or ex-employees. Granting too many privileges or not revoking those privileges in time makes it unnecessarily simple for them to execute their wrongdoing. Some of these actions might even be executed inadvertently or without the perception of those actions being illegal. For example, medical records of prominent people are exposed by employees all the time. (That is just one of the reasons why you should encrypt HIPAA-related data.)
The second reason is connected to another vulnerability: SQL Injection. If an adversary gains access to your data using SQL injection, you are already in trouble. If they then can do additional harm, because of excessive privileges being granted to the application account, the damage might be substantially bigger.
It is a totally different ballgame if someone abuses privileges they have legitimately. Abuse of legitimate privileges can be considered a database vulnerability, if the malicious user misuses their database access privileges. An example for that would be a database administrator sticking his nose into data that he has no business of knowing, e.g. the contents of the CreditCard table. However, privilege abuse like this could also be an application problem, if for example the application allows an account specialist to access accounts not assigned to her.
Abuse of excessive privileges is easy to deal with. Just do not grant unnecessary privileges and always follow the Least Privilege Principle. While this sounds trivial, it requires planning early on during the development process. For example, it might make sense to use different database accounts for different application functions. That however is significantly more difficult to add after the fact, so make sure the security architecture is part of the overall application architecture from the get-go. Also, in the case of application-based privilege abuse, additional checks have to be implemented inside of the application.
Abuse of legitimate privileges is a lot harder to protect from than abuse of excessive privileges, as you cannot really prevent it. The first question to ask is, if you have segregated the roles in your organization enough. For example, does the person responsible for the backups really need to have sysadmin privileges? However, if you have been following the Least Privilege Principle, the only course of action left is to have a good auditing trail in place. While you might not be able to prevent someone misusing legitimate privileges, you can catch them in the act or at least after the fact if you have a good audit trail. Just make sure that the audit trail contains account information (this might again require application changes) and review the audit log regularly.
Privilege Abuse is one of the most commonly encountered database vulnerabilities. In this series of posts I discuss 10 of them. Below are the ones that are published so far: