ORACLE HACKING

Hack Oracle - Part 2

Continued from the last post, let's look at some more ways of hacking Oracle.

5.Privilege Escalation

In a nutshell "privilege escalation" involves using the existing usually underprivileged account in tricky, sneaky or nefarious ways to gain greater privileges or even the DBA privileges!
Here's an example, using one of the CREATE ANY grants. The 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 :
1. Insert into the public table (the trigger fires)
2. The trigger is owned by SYSTEM
3. SYSTEM calls the 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 http://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.

6.Listener

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.

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.

ORACLE HACKING

Different Ways to Hack Oracle

Oracle is said to be very safe,but still there are ways to hack the Oracle.Some of the techniques used to hack the Oracle are discussed here.

1. SQL Injection
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;--

for more on sql injection

2. Default Passwords
Most of the Oracle logins have default passwords.

Username        Password

applsys         apps

ctxsys          change_on_install

dbsnmp          dbsnmp

outln           outln

owa             owa

perfstat        perfstat

scott           tiger

system          change_on_install

system          manager

sys             change_on_install

sys             manager

3. Brute Force
Brute force, is the method for banging away at the lock, or keyhole until it breaks,forcibly. 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.

4. Sneaking Data Out The Back Door
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.