Eight Ways to Hack Oracle
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 be sure.
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 here: http://www.petefinnigan.com/weblog/archives/00001115.htm
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:
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
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.
http://www.petefinnigan.com/default/default_password_list.htm
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.
Conclusion:
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
Author: Sean Hull @ www.databasejournal.com
Read more ...
![[CNW:Counter]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_tbhr_-NmOkJB0dmqTul4POdDezZVXfLOwW8DN9712iYOALC1vyfE99l6PrSKedcl7lOH-714rhpbCqi8wg5O6yOJyM836g1NYkhO91CHG7gI8KgGTGxqm6McFfTA=s0-d)
