Oracle is touted as being unbreakable, if talk weren't so
cheap. Well as with any computing system, there are ways to hack it, and Oracle
is no exception. In this piece, we'll talk about some of the ways
that you can get at data you're not supposed to. We'll start by taking the perspective of the hacker, and we hope as a
manager of databases yourself this will illustrate areas where your
infrastructure may be vulnerable. We'll then follow that by
discussing ways to protect against the vulnerability.
1. SQL Injection
With many Oracle databases these days, they are the
backend datastore for a web application of one sort or another. The
thing about web applications which makes them vulnerable and
relatively easy targets for us are threefold. One, they are complex,
composed of many components making them difficult to test
thoroughly. Two, the barrier to entry for programmers is
lower. You don't have to be a C programming guru to hack together
some webpages. We'll show why that matters to us shortly. The
third reason is urgency. Web apps are always in development mode, so they're
constantly changing, rolling out new features. So, security is
necessarily a lower priority. Ok on to the good stuff.
SQL Injection is simply entering information in a web form,
and secretly adding some unexpected code, tricking the application
to execute that on the database, and return results the programmer
had not foreseen. For example, you have a user login form which
requests username and password. In the username field, you enter:
sean'); select username, password from all_users;--
Now if the programmer was not smart enough to
"sanitize" our input, i.e. check for things like this, then this
will execute on the remote db and this sensitive data will be dumped back
to our browser. Wow!
Here's a great comic which illustrates this quite well: http://xkcd.com/327/
You may think this is scary, but there's more. David
Litchfield in his book "Oracle Hacker's Handbook"
calls one particular pl/sql injection the "holy grail" because
it is vulnerable in Oracle 8 all the way through the current 10g release
2. If it's not obvious, that means you can use it on almost *any*
Oracle database out there.
How's it work you ask? You make use of a package
called DBMS_EXPORT_EXTENSION, use injection to get our code to execute
an exception handler that grants some user or for that matter all
users, DBA privileges!
This was what the famous Alert 68 was all about, and
according to Litchfield was never really properly patched.
Defending Against This Attack
In a word, diligence. There is no bulletproof
solution, as it involves all the subtleties of applications that face the
internet. There are various SQL Injection Testing
techniques available. There is an excellent 3-part article at
Security Focus called "Penetration Testing for Web Applications"
It is also possible to *detect* SQL Injection to some degree
with various intrusion detection tools. Learn more over at Pete Finnigan's
security site (search the page for "detecting sql injection") http://www.petefinnigan.com/orasec.htm
For developers there are packages that help you *sanitize*
your inputs. If you call the various clean and sanitize routine on
every value you receive from a form, you are much more protected than
otherwise. But of course be sure to test and verify by hitting the
application with SQL Injection tools. That's really the only way to
Pete Finnigan has reported that Steven Feurstein is working
on SQL Guard,
a pl/sql package to provide this type of library to developers. Read more
2. Default Passwords
Oracle is such a huge product and there are schemas created
for everything. Most of these logins have default passwords.
Is the database administrator diligent? One way to find out.
Take a gander at some of the more common ones:
What's more even if these are changed, sometimes they are
quite easy to guess, give "oracle", "oracl3",
"oracle8", "oracle9", "oracle8i" and
"oracle9i" a try as well.
Pete Finnigan has a very comprehensive and up to date list
of default users and passwords for you to try out. This list also
includes hashed passwords, so if you've queried all_users, you can
compare against this list.
Defending Against the Attack
As a Database Administrator, you should audit all your
database passwords regularly. If there is business resistance to changing
easily guessable passwords, explain calmly, but with a clear and visual
illustration of what could happen, and what the risks are.
Oracle also provides password profile security. You
can enable profiles that enforce a certain level of complexity in your
database passwords. You can also enable regular password
expiration. Beware enabling this for logins that only happen through a webserver,
or middle tier application server, as the application may suddenly break,
if no one directly sees the warnings and notifications.
3. Brute Force
Brute force, as the name implies, is the method for banging
away at the lock, or keyhole until it breaks. In the case of Oracle
it means trying every username and password by automating the process with
a little bit of code to help you.
For years now, a piece of software called John the Ripper
has been available to unix administrators for exactly this task. Now
there is a patch available for you so you can use this handy software
for banging away at Oracle passwords. Want to speed this process up
even more? Prepare in advance a table of all password hashes.
Such a table is called a Rainbow table. You will have a different
one for each username because the password hashing algorithm uses
the username as the salt to the function. We won't get into that in
too much detail, but here's a resource for further study: http://www.antsight.com/zsl/rainbowcrack/
Oracle servers default to automatically lockout a particular
account after ten failed logins. Normally though "sys as sysdba"
does not have this restriction. The thinking I guess is if you
lockout the administrator, then everyone is locked out! Fortunately,
for us this means programs like OraBrute make our lives much easier!
Author Paul Wright has put together a great program for banging on the
front door of your fortress all day and all night until it opens.
Head on over to Paul's blog and download a copy for yourself! http://www.oracleforensics.com/wordpress/index.php/2007/03/04/oracle-passwords-and-orabrute-paper-update/
Defending Against the Attack
Defending against this type of attack can be done with the
methods describe above for default passwords. A curious and proactive DBA
might also go the extra step to download these tools, and attempt to hack
into his own system. This will help illustrate your real risks,
and better educate how safe you really are.
4. Sneaking Data Out The Back Door
(I was going to have a section called Auditing, but that
makes more sense for the article on prevention).
In the security world, this concept is known as data
exfiltration. It comes from the military term, opposite of
infiltration, it means getting out without being noticed. In the
context of getting data from a target database, it could be as simple as
picking up some tape backups and restoring the database, or getting a copy
from a retired crashed disk. However, it can also involve snooping
network traffic for relevant packets of data.
Oracle has a package called UTL_TCP, which can make
outside connections to other servers. It could be used with a
little programming magic, to sending a low bandwidth stream of data from
the database to some remote host. Oracle also comes with some
useful packages to hide what might be inside your secret stream of data,
so make ample use of those if you think an intrusion detection
system might be monitoring your activities. They
include DBMS_OBFUSCATION_TOOLKIT and DBMS_CRYPTO.
Defending Against the Attack
The best way to defend against these types of attacks is to
setup an intrusion detection system. These can watch incoming and
outgoing packets on the network. Some provide "deep packet
inspection" which actually tests for certain SQL, and based on a set of
rules, triggers alarms in certain circumstances. These tools can
look for telltale signs like added UNIONs, various types of short- circuiting,
truncating with a comment "--" and so on.
So, as you can see there are a lot of ways to plan your
attack, and get into a target Oracle database. DBAs should keep in
mind that for each vulnerability, there is a way to defend against it, so vigilance
is key. In Part II of this series, we will cover the insecurities of 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.
See All Articles by Columnist Sean Hull