Centrify DirectAudit 2.0.2-184 (Centrify Server Suite 2012) and higher on all platformsBackground:
DirectAudit databases use two types of accounts; a Service account
and an Outgoing account
. All DirectAudit Stored Procedures that encapsulate back-end logic run under the Service account
. This includes all Stored Procedures deployed with the Management database and the Audit Store databases. This account has sysadmin rights over the SQL Server Instance.
The Outgoing account
is used by the Management database to pull data from one or more Audit Store databases. The managed database executes Stored Procedures from Audit Store database using the credentials of the outgoing account
In some Stored Procedures deployed with the Management Database and the Audit Store databases a hacker can use SQL injection to gain access to or alter/delete sensitive information (https://en.wikipedia.org/wiki/SQL_injection)
What can be attacked with this vulnerability?
- Using Service account’s credentials, a hacker can gain access to other databases that share the same SQL Server instance as the Management database. To exploit this vulnerability, a hacker must be either a DirectAudit Auditor or have some administrative privileges over the DirectAudit installation.
- Using outgoing account’s credentials, a hacker can gain access to other databases that share the same SQL Server instance as the Audit Store database if the outgoing account has admin rights on the target SQL Server instance. To exploit this vulnerability, a hacker must be either a DirectAudit Auditor or have some administrative privileges over the DirectAudit installation.
- Chances of causing damage are higher if multiple SQL Server instances are running on the same server and they’re all running under a high privilege Local System account (which is not a recommended practice).
What cannot be attacked with this vulnerability?
- A hacker cannot use any of the Centrify provided interfaces (such as PS cmdlets or FindSessions tool or consoles) to exploit this vulnerability.
- Other SQL Server instances that do not host any DirectAudit Audit Store databases or SQL Servers that do not have a login for outgoing account cannot be attacked.
- If standard security practices were followed during deployment and unnecessary admin privileges were not assigned to the outgoing account, the damage could be limited.
This issue has been resolved in a patch for both Server Suite 2015.1 (3.2.3) and Server Suite 2016.1 (3.3.1).
The patches can be found at the following locations:
Note: Applying this security patch does not introduce any new functionality neither does it fix any other bugs. With any security fix, it's up to the customer to determine the severity of security vulnerability that is being addressed by this patch and make a decision on whether to apply it or not.How to apply the security patch:
There are multiple scenarios that need to be taken into consideration when applying the patch.
1) New deployment of a new DirectAudit installation
Download and install the latest Centrify Server Suite ISO (Suite 2016.1) and then upgrade the Audit Manager Console, Audit Module for PowerShell and DirectAudit SDK using the installers bundled with this security patch. There is no need to use the PatchDatabase or PatchDatabase64 standalone utility in this case. Once all components are upgraded, you can proceed with creating your DirectAudit installation.
2) Existing DirectAudit installation already deployed (Suite 2015.1 or Suite 2016.1)
There are two steps to apply the security patch in this scenario:
Step 1 - Patch existing databases that are attached to the DirectAudit installation (applies to both Management database and Audit Store database(s)).
To patch existing databases, simply copy the PatchDatabase64.zip (if you are using 64 bit Audit Manager console) or PatchDatabase.zip (if you are using 32 bit Audit Manager console) to your database server, extract the zip file and run the PatchDatabase.exe in context of a user who is member of sysadmin fixed server role on the database server; run the utility without specifying any parameters to display the usage and various options available.
Please note that the database patching utility performs an in-place upgrade of the DLLs deployed with the Centrify database and it must be run from the database server itself; running this utility from a remote system will result in failure.
Step 2 - Upgrade existing components
A new DirectAudit Audit Store database can be created using three separate ways and by three separate components e.g. using Audit Manager console or by using the SDK or by using the PowerShell cmdlet. If the security patch is applied for all existing databases (using Step 1) but the component that is typically used for periodic database rotation is not upgraded, all new Audit Store databases created later will continue to have the security vulnerability present in their Stored Procedures. To avoid this, upgrade all existing instances of Audit Manager console, Audit Module for PowerShell and DirectAudit SDK after patching all existing databases.
3) Existing DirectAudit installation already deployed (All other versions of Suite)
It is required to first upgrade to either Suite 2016.1 (recommended) or Suite 2015.1 and then proceed with applying the security patch as described in Scenario #2
(Centrify Corporation does not take any responsibility for the content or availability of external links and are provided as a courtesy. Customers should contact the vendor if there are any further questions)