Introduction
In Part
I of this series we talked about some of the vulnerabilities present in the
Oracle core database product. We took the perspective of the hacker,
explaining how your database can be attacked with SQL Injection, weak default
passwords, brute force attacks against the login authentication process, and
lastly sneaking data out the back door.
In Part
II of this series, we will cover four other vulnerable areas: namely the Oracle
Listener, privilege escalation to get more access from a less privileged login
we already have, executing operating system commands, which can be very
powerful, and under appreciated, and lastly filesystem security. If you
can read the raw data out of the binary data files making up your database, you
can completely circumvent any security measures put in place by Oracle.
5. Listener
I think
one of the things that is truly amazing about computing, is how extremely
difficult it is to tame it. Over and over again we see, particularly in
the area of security, how simple some vulnerabilities are, and how they arose
simply because the user (in our case the hacker) did not behave or think the
way the designer (programmer or software developer) had intended or expected.
Oracle’s
listener is setup out of the box so that one can remotely administer it.
What if the attacker sets the logfile of the listener to be the Unix .rhosts file?
Well the attacker can effectively WRITE to the .rhosts file. This file on
Unix configures who is allowed to login without a password using the rsh,
rlogin, and rcp commands. You can imagine what happens next!
This is
really the tip of the iceberg in terms of security surrounding Oracle’s
listener. There are also buffer overflows and a lot more to look
at. In fact, Litchfield’s Oracle Hacker’s handbook has a whole chapter on
the topic!
From the
prevention side of the house, Oracle has made some strides to allow better
security if only you put it in place. For starters, set a password for
administrating the listener. Burdened by an ever-growing set of passwords
to manage, this might seem like too much, but consider the threat before you
look the other way. Oracle has also added ADMIN_RESTRICTIONS, which
prevent certain things from being done remotely. For instance, you would
then have to be local to set the location of logfiles.
6. Privilege Escalation
In a nutshell
"privilege escalation" involves using your existing usually
underprivileged account in tricky, sneaky or nefarious ways to gain greater
privileges or even DBA privileges!
Here’s
an example, using one of the CREATE ANY grants. I have access to the
database via a user SEAN who has CREATE ANY TRIGGER, so we can create a trigger
in any schema. If you can track down a table which any user can write to,
create a trigger in SYSTEM which executes when you the unprivileged user, INSERT
or UPDATE that publicly writeable table. The trigger you write calls a
stored procedure you also write, which, and here’s the rub, executes with
AUTHID CURRENT_USER. That means it’ll have the privileges of the SYSTEM
user when it executes *YOUR* procedure. Now inside your nefarious stored
procedure you include "EXECUTE IMMEDIATE ‘GRANT DBA TO SEAN’";
Voila!
Now I
can:
1. Insert
into my public table (the trigger fires)
2. The
trigger is owned by SYSTEM
3.
SYSTEM calls my change_privileges stored procedure, which is AUTHID
CURRENT_USER
So
although *I* could not have executed to change my own privileges I managed to
get SYSTEM to execute it, and that user *DOES* have the privileges, so I am now
granted DBA!!
What’s a
Database Administrator to do? Well for starters, you should audit your
database for CREATE ANY privileges and remove the ones that aren’t
required. Secondly, you should scan the forums such as www.securityfocus.com for the latest
vulnerabilities surrounding privilege escalation. Lastly, it might not
hurt to enable auditing of certain types of activities so the database will
help you help yourself. While it audits things like GRANT DBA you can
monitor that audit log for malicious or unexpected activity.
7. Operating System Commands & Security
Hackers aren’t
always logged into your system at a shell prompt. In fact, we hope they
never are! Nevertheless, that doesn’t mean they can’t pretend. By
coaxing the Oracle database to run commands at the Operating System level
though, we’re effectively giving the hacker a way to have just that, a method
for running commands. Those commands could delete or corrupt files,
overwrite logs (to hide their tracks), create accounts, or anything else that
one could potentially do at the command line. So, how do they do it?
Although
there are a number of ways, the easiest is through languages like Java or
PL/SQL. Often the ability to create external stored procedures is
available. By default, it is anyway. This can allow a stored procedure,
which performs a system call to execute. This system call then can
execute with the privileges of the "oracle" account by which Oracle
was installed in the first place. So from there you can see where it
goes.
Although
Oracle has made some strides to protect against these types of things, your
best bet in terms of prevention is monitoring. By keeping an eye on the
activities inside your system, you’re better able to be proactive if an
attacker tries something malicious like this.
8. Filesystem Security
Access
to the filesystem is one area that is a tricky one to get your head
around. The "oracle" OS user owns all of the Oracle software, and
datafiles of your database, so if or when a user inside the database accesses
files on the filesystem using the UTL_FILE package, they have access to many
things they wouldn’t have access to inside the database, because their GRANTs
and ROLEs constrain them. If they create read datafiles, they can
affectively gain access to the raw binary data that make up your tables and indexes,
and with some work can deduce the content therein. They may also be able
to write to those files and affectively corrupt them. Dangerous indeed.
Oracle
has made some strides to prevent this by introducing the DIRECTORY
object. One must have a DIRECTORY object defined to do certain types of
reading and writing now in 10g. That means a user must have CREATE
DIRECTORY privilege, which we’ve seen previously can be attained by various
methods of privilege escalation. Even given all of this, there are still
ways to gain access to the filesystem and read and write files via PL/SQL or
Java.
Conclusion:
As you
can see there are certainly many vulnerabilities present in the Oracle database
product. At times, it might seem like a giant house of cards built by
very smart engineers who were more honest than the hackers that prey upon
it. As such, they did not envision or entertain the numerous ways that
someone might try to chip away at, or pull out cards and weaken the foundation.
To be
completely fair, many of these can be addressed by adamant DBAs who spend time
and energy to address them. Oracle has patches for many of the issues
inside the database, and intrusion detection systems can provide an additional
layer of security. We hope that our notes to managers and DBAs in each of
these sections will point you in the right direction on research into the issues,
and execution of your own security plan.
