by Maarten Van Horenbeeck

About a week or two ago I was talking with a friend of mine whom from now on I shall refer to as Woshy (he doesn’t like to see his name in print and this nickname reminds me of a hairy Star Wars creature, and anything that reminds me of Star Wars is good) on application level rootkits. Though I’ve heard and read about them often, I had actually never bumped into anything I would classify as such. Woshy told me he had.

I’ve never really given much thought to these types of malicious code, as they have so far been unlikely to be implemented by the average attacker. Nevertheless, in targeted attacks these are the things that keep a compromise going for several months without detection.

The general idea is simple, and was put forward by the German company Red Database Security, which specializes in Database security issues. Database packages have always contained a tremendous amount of features, and have started to emulate operating systems altogether. They contain a scripting language, various forms of access control (views) and more importantly, they actually contain plenty of useful data for an attacker. Someone who compromises a database system is generally very interested in maintaining access to this ever changing source of information.

The real question as such is the same as the one posed by someone who has just owned a prized box. How do I maintain access without triggering the interest of the administrators? The answer is simple: become invisible. Now, what can we do besides putting on our invisibility cloak? You can hide, or you can change the administrator’s view on things. Literally, by changing default database views you can prevent user accounts or other characteristics of the database from being uncovered. Most administrators never review these default views, making you practically invisible.

A second issue is keeping yourself activated whilst in hiding. An operating system rootkit generally remains resident as a kernel module, and traps certain system calls, replacing them with its own behavior. Within a database, this is a bit more difficult to do. In addition, we need to ensure that we don’t hide too well. In the early 90’s everyone was afraid of boot sector infectors; once you had your floppy infected, anyone who booted from it would get his disk infected. One can hardly imagine booting from a floppy these days, hence, no more boot sector infectors. In order to ensure you run, you could install yourself as a daily database job, or a job which is invoked when a certain trigger occurs, such as a table which is running full.

How likely you are to run into these types of tools? Good question. There’s at least one Oracle rootkit on sale commercially, but it’s unlikely to be of the quality and depth the Red Security researchers spoke about in their Black Hat 2006 paper. They have been sporadically reported over the last two years, but are not quite the major threat an operating system rootkit poses (note that such tool would also have control over what the database does and does not see).

However, if the data you are storing is important enough, and you don’t trust the host preventative and detection measures you already have in place,  you have an opportunity here to start with a reasonably trustworthy system - something we missed with OS rootkits. Having checksums available of critical system components could prove its worth if you are compromised later on, and want to review the amount of access the attacker may still have to your data. The trick in dealing with rootkits with ease and assurance is to always be one level lower than the level on which the rootkit operates. As databases run inside a contained operating system, we actually have the opportunity to do more work here than running a tool that identifies unexpected behavior from within the compromised environment. For that same reason, a good forensic audit of a copy of the database can also mitigate some concerns.