Eight Ways to Hack Oracle - Part 2

Thursday Dec 13th 2007 by Sean Hull

Part II of this series covers four vulnerable areas, 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.


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.  


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.

» See All Articles by Columnist Sean Hull

Mobile Site | Full Site