In our last column, we focused on privilege escalation attacks, and the impact that this category of SQL injection attacks can have on the database – particularly where specific database vulnerabilities exist, and can be exploited through the manipulation of privileges. Let’s look more deeply at how organizations struggle with the issue of extensive privileges assigned directly to users – or indirectly through user groups. We’ll address what can happen when database users are over-credentialed, and what should be done to ensure you are aware of all activity that is occurring in your environment.
Consider an employee with an inherited role that is granted a specific level of access to a database or group of database instances. Perhaps this employ is assuming the role of someone who has left the company – and now he is credentialed as if he were that former employee. This process assumes that the access credentials he is inheriting are essential for him to do his job.
But if that level of access to sensitive data is non-essential or excessive (like customer data or transaction data at a brokerage house, or electronic health records (EHR’s) at a hospital) there is a very real threat of misuse. This situation should cause elevated concern because that information is now vulnerable to compromise, especially if an organization is not auditing database activity monitoring logs on a regular basis. Do you?
We’ve found that organizations simply don’t have the time or resources to solve this challenge, or determine a comprehensive process to identify every role and privilege as it relates to database access. It is very difficult to have a good understanding of everything that is happening in an organization’s databases.
As attacks increasingly targeting the database, insider misuse poses a threat not just to the integrity of the data, but to the viability of the company.
Getting Control
There are standard practices that help guide organizations in developing a better internal control process for accessing sensitive information. These include ‘separation of duties’ controls which are designed to ensure access only to those who really need it. These controls manage conflicts of interest and implement an appropriate level of checks and balances on an individual’s activities to ensure they do not have toxic privilege combinations.
Applied to the database, segregating users based on roles and activities should be the first step in the process. But the other side to separation of duties is that many of today’s regulatory mandates require organizations to prove separation of duties in an audit.
The principle of least privilege is another practice that dictates that users have the minimum privileges necessary to perform their specific tasks – generally this means access only to the data required and nothing more. Users that have multiple job functions should also have separate and specific accounts for each of these unique roles. For example a developer that also performs DBA functions on production servers should not share all of these privileges in a single account.
There are multiple examples of database threats that exist as a result of excessive privileges. The following examples from our knowledgebase illustrate how configuration issues can result in vulnerable systems.
From the SHATTER Knowledgebase:
Windows BUILTINAdministrators member of SYSADMIN fixed server role
The SYSADMIN fixed server role grants all database privileges to assigned members. Thus, the BUILTINAdministrators group of the host server should not be granted the SYSADMIN role. Otherwise this would give all local administrators on the Windows host DBA privileges on the database server. Separation of duties is not enforced by automatically combining assignment of DBA responsibilities to the host administrator role.
Usually, security should be tightened by revoking DBA privileges from all operating system users. This is accomplished by revoking the sysadmin role from the BUILTINAdministrators group. Instead create a separate Windows group containing the appropriate DBAs and granted that group the sysadmin role in the database.
DBMS external procedure OS account privileges
External applications spawned by the DBMS process may be executed under OS accounts which are assigned unnecessary privileges, which can lead to unauthorized access to OS resources. Unauthorized access to OS resources can lead to the compromise of the OS, the DBMS, and any other service provided by the host platform.
We recommend making it a standard practice to review all OS accounts that are used to execute DBMS external procedures. Review the privileges assigned to these accounts and compare them to the set of required privileges and the function of the applications. Unnecessary privileges should always be removed.
Recommendations
Collecting and documenting a comprehensive list of all the rights a user has been granted (or has not been granted) can be a daunting task. It is a major undertaking to manually determine who has what access to which databases that contain different categories of data. In an enterprise organization where database environments are large, diverse and sophisticated, it’s not surprising that many organizations struggle with this effort.
It should be a recognized rule for the security organization that privileges should never be assigned directly to users, but only to roles/groups of which the users are members. Always make sure that users are not assigned to groups with unnecessary privileges.
Identifying those users, roles and privileges helps establish a foundation of intelligence necessary to implement an appropriate plan. The next step of that plan is to ensure that users are monitored according to the level of access that they have. The higher the privilege that a user is granted, the more scrutiny that should be applied to auditing his/her monitoring audit logs.
Monitoring user activity will also help the security organization document and map back to the user rights process. You might find that after monitoring a specific user, group or set of users that you need to make further rights adjustments according to your plan. And you might also identify those users who are abusing their privileges by way of stealing data, manipulating information or even inadvertently mishandling information.
The ability to discover, document and address the web of privileges and permissions that exist in the database environment can be done through an automated user rights solution. And a solid activity monitoring solution will alert the security professional to abusive users through tracking their activity in the database. As a result, organizations will effectively meet separation of duties requirements not just to pass audits, but to ensure continuous database protection.
Alex Rothacker is the manager of Team SHATTER at Application Security Inc.
