Operating system rootkits are nothing new. They've been used by intruders for years to cover up their tracks. However, it is not common knowledge that rootkits can also be implemented, and are being implemented by intruders in databases, often containing critical company data. Let's have a look at rootkits in Oracle databases and let's see how we can avoid them.

Oracle is a market leader in the area of relational databases and Oracle databases are used in almost every larger enterprise. Enterprise-critical or important data is often saved in Oracle databases. It is no wonder Oracle is becoming a more frequent target for attacks.

Oracle database rootkits are a relatively new security trend. They are installed after a successful break-in into an Oracle database, and serve to cover up any traces of the break-in and provide a continuous cloak, masking the presence of an attacker in the database. Let's then have a look at concepts of Oracle rootkits and their different implementation possibilities as well as countermeasures.

Oracle rootkits - introduction

Oracle databases and operating systems are quite similar in their architecture. Both databases and operating systems have users, processes, jobs, executables and symbolic links. Table 1 shows an ecample of mapping between *NIX operating system commands and Oracle commands. An attacker can take advantage of this similarity to migrate the concept of rootkits, but also other malware like viruses, from the operating system world to the Oracle database world.

Table 1. Example mapping between Oracle and operating system commands and objects

It is/was a common trick of operating system rootkits (first generation) to create hidden users which are not visible for the administrator. To do this, *NIX commands like ps, who and top were replaced by trojanized versions, which show everything except the user account created by the intruder. This approach can also be applied to Oracle. It is just necessary to know, how Oracle represents, stores and uses database users.

Oracle users are stored in the database table SYS.USER$ together with database roles. Users have the flag TYPE#=1 and roles have the flag TYPE#=0. To make access easier, and for up- and backward-compatibility, Oracle provides two views called dba_users and all_users via a public synonym (table structure changes from version to version). Most DBAs and tools are using these views to access the table SYS.USER$. If these views are now modified in a way that a special user, e.g. HACKER, is no longer shown, we created a hidden user (in most cases).

Listing 1. Create database user

 
 
-- Create user and 
-- grant DBA permission
SQL> CREATE USER HACKER
SQL> IDENTIFIED BY HACKER;
SQL> GRANT DBA TO HACKER;
-- Show users
SQL> SELECT USERNAME
SQL> FROM DBA_USERS;
    USERNAME
    -----------------
    SYS
    SYSTEM
    DBSNMP
    SYSMAN
    MGMT_VIEW
    HACKER

First, let's have a look at Listing 1. Let's start by creating the user and checking, whether the user is visible. Now, let's modify the view DBA_USERS and and an additional line to the view:

AND U.NAME != 'HACKER'

We can perform this change using a GUI tool (e.g. Quest TOAD, see Figure 1) or using an SQL statement (CREATE VIEW DBA_USERS AS ...). We must keep in mind, that changes on views belonging to SYS require the role SYSDBA.

Figure 1. Modification of the view DBA_USERS using a DBA tool (Quest TOAD)