Security Advisory: Microsoft SQL Server Audit Bug

Abstract

On November 30, 2005, Microsoft released an advisory regarding vulnerability in the auditing tools for MS-SQL Server 2000 - the company’s most deployed database server. (see: http://support.microsoft.com/default.aspx?scid=kb;en-us;910741) Although not considered a major vulnerability, this event highlights serious concerns regarding the use of native database auditing mechanisms.

The Vulnerabilities

In September of 2005, Imperva’s security research group discovered a flaw in the auditing tools supplied with MS SQL Server 2000. By preceding the client login message with NULL characters, a user can avoid server audit mechanisms. Since the authentication mechanism disregards NULL characters, the user is logged in normally. However, the built-in trace mechanism is not oblivious to NULL characters. Thus any trace filter specifying the original username is not matched. Moreover, any other trace records generated during an attack shows an empty username field.

The above flaw is not considered a major security breach. However, it illustrates a paradox and a serious logical flaw that exists within many existing enterprise security architectures: reliance upon a database server to monitor itself. This practice assumes that the only non-vulnerable element of a database is the audit mechanism. As shown by the recent Microsoft publication and similar advisories (e.g. http://seclists.org/lists/bugtraq/2005/May/0043.html), this is a flawed assumption. Even more flawed is a second assumption that the attacker will not turn off auditing or tamper with audit records once a server is compromised.

To further illustrate the point, consider a video monitoring security system. To identify a thief (in the event that the door locks fail) does it make sense to install a security camera and tape system inside a car? If installed inside the car, the tape is stolen along with the car! Perhaps the thief will leave the camera on and mail the tape to the police after the theft. This is of course an absurd system, but it’s directly analogous and it illustrates the folly of self-monitoring security systems.

A More Logical Approach

A more logical approach separates the audit function from the database itself. For example, an independent network device can inspect and extract detailed audit information from network traffic traveling to and from the database. Such a device can operate in stealth mode (no IP address, etc.) and remain completely invisible to attackers. All activity is tracked and audit records cannot be tampered with before, during or after an attack. In addition, since network devices can be deployed by independent security/audit personnel, this approach enables the separation of audit and database administration (DBA) job functions when desired. As database attacks take center stage, the use of independent, network-based auditing will become critical.

For comments and suggestions please contact adc@imperva.com

Disclaimer

The information within this advisory is subject to change without notice. Use of this information constitutes acceptance for use in an AS IS condition. Any use of this information is at the user’s own risk. There are no warranties, implied or expressed, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information.

Redistribution of this alert electronically is allowed as long as it is not edited in any way. To reprint this alert, in whole or in part, in any medium other than electronic medium, adc@imperva.com for permission.