How many DBAs, I wonder, really know how to go about detecting potential rootkits in their SQL Servers? To install a simple database rootkit is an easier task than you might imagine, and once it’s there it can be very difficult to uncover, as it goes about capturing passwords, stealing data, tampering with user accounts, or performing similar nefarious activities.

The term rootkit emerged from the UNIX world, where the ROOT privilege was top of the tree. A database rootkit is essentially an application or procedure that it used to covertly maintain unauthorized administration-level access to that database, as opposed to the underlying operating system that is the prey of traditional rootkits.

A SQL Server rootkit can take many guises, but in its simplest form it can be a function whose logic has been subtly altered to return different results, or a stored procedure slipped quietly into a system database and executed by unsuspecting users, in place of the legitimate target procedure. System views, the results from which seem genuine to the untrained eye, have been tweaked to mask the changes, and hide the existence of the rogue database login.

What may be surprising to some is just how easy it is to install this type of rootkit on a SQL Server, once an intruder has obtained administration-level access. Kevvie Fowler’s excellent book, SQL Server Forensic Analysis, explains in step-by-step detail how this might be done on SQL Server 2000 and 2005. Certain entry points have been closed in SQL 2008 but it’s still entirely possible, for example, to exploit the way in which SQL Server searches the Master database for a referenced object, if it cannot be found locally.

The relative ease of introducing such rootkits stands in stark contrast to the task of detecting them, and the damage that they have potentially inflicted. It involves identifying and collecting the various data fragments (artifacts) that are the ‘fingerprints’ left by the nefarious hacker, developing incident response scripts, installing “Windows Forensic Toolchests”, collecting, collating and analysing all of this data in order to painstakingly reconstruct the activity of the intruder.

It’s a fascinating journey but one feels exhausted almost before one begins, and I wonder how many DBAs have the processes in place to detect this sort of activity or, indeed, the sort of layered security measures that can help prevent such intrusions in the first place, as described in John Magnabosco’s new book, Protecting SQL Server Data.

How real is the threat of SQL Server Rootkits? Are they a serious danger, or just another security issue that is being conjured up to instil unjustified fear and dread in the DBA? As always, it is your comments that will lead opinion.

Cheers,

Tony.